perfSONAR User Q&A and Other Discussion

[SCHAER Frederic <>]

Hi Eli,

 

Oh… if you’re right then I’m wondering (also) if that behaviour is to be expexted or not…

 

De : Eli Dart [mailto:]
Envoyé : mercredi 7 janvier 2015 17:57
À : SCHAER Frederic
Cc :
Objet : Re: [perfsonar-user] owamp/traceroute results on ps-PS 3.4.1 ?

 

Hi Frederic,

 

I see the duplicate ping replies from CERN as well (using two different hosts on two different networks).

 

Given that www.cern.ch is an alias for webrlb02.cern.ch, I'm guessing that CERN is using a load balancer appliance (I expect that the lb02 in the hostname means Load Balancer Number Two).  I've seen this behavior in some load balancers before.

 

This doesn't answer your perfSONAR question, of course...

 

Eli

 

 

On Wed, Jan 7, 2015 at 8:49 AM, SCHAER Frederic <> wrote:

Hi,

 

I found an issue which I’d like to see if it’s been found by perfsonar owamp tools.. and I’d like to know when it started. But I can’t find any data result despite we have regional/intersites meshes setup.

The tool named traceroute graphs/“psTracerouteViewer v2” attempts to query the perfsonar host on http://localhost/esmond/perfsonar/archive/ and finds nothing.

Attemting to use the fulle hostname instead of localhost does not help, but going to http://full.hostname/esmond/perfsonar/archive/?format=json displays stuff…

 

Any idea how I could see owamp/traceroute results ?

 

For information, the issue I found at random is that I see duplicate ping packets to cern :

 

[fschaer@node02 irfu]$ ping www.cern.ch

PING webrlb02.cern.ch (188.184.9.235) 56(84) bytes of data.

64 bytes from webrlb02.cern.ch (188.184.9.235): icmp_seq=1 ttl=117 time=9.55 ms

64 bytes from webrlb02.cern.ch (188.184.9.235): icmp_seq=1 ttl=117 time=9.58 ms (DUP!)

64 bytes from webrlb02.cern.ch (188.184.9.235): icmp_seq=1 ttl=117 time=9.58 ms (DUP!)

64 bytes from webrlb02.cern.ch (188.184.9.235): icmp_seq=2 ttl=117 time=8.91 ms

64 bytes from webrlb02.cern.ch (188.184.9.235): icmp_seq=2 ttl=117 time=8.93 ms (DUP!)

64 bytes from webrlb02.cern.ch (188.184.9.235): icmp_seq=2 ttl=117 time=8.94 ms (DUP!)

64 bytes from webrlb02.cern.ch (188.184.9.235): icmp_seq=3 ttl=117 time=9.01 ms

64 bytes from webrlb02.cern.ch (188.184.9.235): icmp_seq=3 ttl=117 time=9.03 ms (DUP!)

64 bytes from webrlb02.cern.ch (188.184.9.235): icmp_seq=3 ttl=117 time=9.04 ms (DUP!)

64 bytes from webrlb02.cern.ch (188.184.9.235): icmp_seq=4 ttl=117 time=8.89 ms

64 bytes from webrlb02.cern.ch (188.184.9.235): icmp_seq=4 ttl=117 time=8.90 ms (DUP!)

64 bytes from webrlb02.cern.ch (188.184.9.235): icmp_seq=4 ttl=117 time=8.90 ms (DUP!)

64 bytes from webrlb02.cern.ch (188.184.9.235): icmp_seq=5 ttl=117 time=9.00 ms

64 bytes from webrlb02.cern.ch (188.184.9.235): icmp_seq=5 ttl=117 time=9.04 ms (DUP!)

64 bytes from webrlb02.cern.ch (188.184.9.235): icmp_seq=5 ttl=117 time=9.04 ms (DUP!)

^C

--- webrlb02.cern.ch ping statistics ---

5 packets transmitted, 5 received, +10 duplicates, 0% packet loss, time 4420ms

 

Note : I don’t think cern is part of the tests/meshes, but question remains : maybe cern isn’t the only route affected with this issue on our side.

 

Thanks

 

--

Eli Dart, Network Engineer                          NOC: (510) 486-7600

ESnet Office of the CTO (AS293)                          (800) 333-7638

Lawrence Berkeley National Laboratory 

PGP Key fingerprint = C970 F8D3 CFDD 8FFF 5486 343A 2D31 4478 5F82 B2B3