Skip to Content.
Sympa Menu

perfsonar-user - Re: [perfsonar-user] owamp/traceroute results on ps-PS 3.4.1 ?

Subject: perfSONAR User Q&A and Other Discussion

List archive

Re: [perfsonar-user] owamp/traceroute results on ps-PS 3.4.1 ?


Chronological Thread 
  • From: Daniel Doyle <>
  • To: SCHAER Frederic <>
  • Cc: "" <>, Eli Dart <>
  • Subject: Re: [perfsonar-user] owamp/traceroute results on ps-PS 3.4.1 ?
  • Date: Wed, 7 Jan 2015 12:41:30 -0500

Curse you Mail.app for putting the wrong person! 

That should have been directed towards Frederic, not Eli. Sorry. :)

-Dan

On Jan 7, 2015, at 12:39 PM, Daniel Doyle <> wrote:

Eli,

OWAMP data should be visualized on the charts under the "Throughput / Latency Graphs" section of the UI as "Latency" or "Reverse Latency" in the graphs.

When you say it "displays stuff" when using the format=json argument, are you seeing things in there with an event-type of "packet-trace"? This is what the UI is keying off of to show trace data via Esmond. You may need a JSON prettifier plugin in your browser to make this output at all readable, or else put the URL here and I can check it out.

Thanks,
-Dan


On Jan 7, 2015, at 12:18 PM, Eli Dart <> wrote:

Hi Frederic,

I don't know if this is expected behavior or not - I'm not a load balancer expert.  It is possible that I'm wrong about this too - we'd have to ask someone at CERN to be sure.

Still, I would say that this behavior is less than optimal.  It may be something that is easy to fix, or it may be a known consequence of engineering decisions made to achieve the best aggregate outcome.  Hard to say for sure from my current perspective.

Eli


On Wed, Jan 7, 2015 at 9:01 AM, SCHAER Frederic <> wrote:

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




--
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

Dan Doyle
GlobalNOC Software Developer
1-812-856-3892




Dan Doyle
GlobalNOC Software Developer
1-812-856-3892



Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail




Archive powered by MHonArc 2.6.16.

Top of Page