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: Alan Whinery <>
  • To:
  • Subject: Re: [perfsonar-user] owamp/traceroute results on ps-PS 3.4.1 ?
  • Date: Wed, 07 Jan 2015 07:56:59 -1000

I would say that there are fewer dups in the world than there used to
be. I once found the root cause as a bug in a Proteon FDDI driver, which
was causing its router to both forward and issue a spurious ICMP
redirect. Mayhem ensued.

Maybe Les's data has the reach to comment on my "fewer dups than there
used to be" assertion. Of course, maybe I just don't ping as much as I
once did. Duplicates have always been a bit of a "mystic lore" sort of
topic, probably because there aren't enough of them to become a
priority, or the bugs get found and fixed without any fanfare.

On 1/7/2015 7:38 AM, Cottrell, Les wrote:
> This has been going on for web.cern.ch for years. It does not happen for
> other CERN nodes such as pinger.cern.ch. The earliest reference I can find
> is 12/30/20006. It was reported to CERN network folks at the time. I have
> used it as an example in some courses I have given. Several possibilities
> have been proposed and some shot down, however, I never heard a definite
> reason given.
>
> -----Original Message-----
> From:
>
>
> [mailto:]
> On Behalf Of Eli Dart
> Sent: Wednesday, January 07, 2015 9:18 AM
> To: SCHAER Frederic
> Cc:
>
> Subject: Re: [perfsonar-user] owamp/traceroute results on ps-PS 3.4.1 ?
>
> 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 <http://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
> <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 <http://www.cern.ch>
>
> PING webrlb02.cern.ch (188.184.9.235) 56(84) bytes of data.
>
> 64 bytes from webrlb02.cern.ch <http://webrlb02.cern.ch>
> (188.184.9.235): icmp_seq=1 ttl=117 time=9.55 ms
>
> 64 bytes from webrlb02.cern.ch <http://webrlb02.cern.ch>
> (188.184.9.235): icmp_seq=1 ttl=117 time=9.58 ms (DUP!)
>
> 64 bytes from webrlb02.cern.ch <http://webrlb02.cern.ch>
> (188.184.9.235): icmp_seq=1 ttl=117 time=9.58 ms (DUP!)
>
> 64 bytes from webrlb02.cern.ch <http://webrlb02.cern.ch>
> (188.184.9.235): icmp_seq=2 ttl=117 time=8.91 ms
>
> 64 bytes from webrlb02.cern.ch <http://webrlb02.cern.ch>
> (188.184.9.235): icmp_seq=2 ttl=117 time=8.93 ms (DUP!)
>
> 64 bytes from webrlb02.cern.ch <http://webrlb02.cern.ch>
> (188.184.9.235): icmp_seq=2 ttl=117 time=8.94 ms (DUP!)
>
> 64 bytes from webrlb02.cern.ch <http://webrlb02.cern.ch>
> (188.184.9.235): icmp_seq=3 ttl=117 time=9.01 ms
>
> 64 bytes from webrlb02.cern.ch <http://webrlb02.cern.ch>
> (188.184.9.235): icmp_seq=3 ttl=117 time=9.03 ms (DUP!)
>
> 64 bytes from webrlb02.cern.ch <http://webrlb02.cern.ch>
> (188.184.9.235): icmp_seq=3 ttl=117 time=9.04 ms (DUP!)
>
> 64 bytes from webrlb02.cern.ch <http://webrlb02.cern.ch>
> (188.184.9.235): icmp_seq=4 ttl=117 time=8.89 ms
>
> 64 bytes from webrlb02.cern.ch <http://webrlb02.cern.ch>
> (188.184.9.235): icmp_seq=4 ttl=117 time=8.90 ms (DUP!)
>
> 64 bytes from webrlb02.cern.ch <http://webrlb02.cern.ch>
> (188.184.9.235): icmp_seq=4 ttl=117 time=8.90 ms (DUP!)
>
> 64 bytes from webrlb02.cern.ch <http://webrlb02.cern.ch>
> (188.184.9.235): icmp_seq=5 ttl=117 time=9.00 ms
>
> 64 bytes from webrlb02.cern.ch <http://webrlb02.cern.ch>
> (188.184.9.235): icmp_seq=5 ttl=117 time=9.04 ms (DUP!)
>
> 64 bytes from webrlb02.cern.ch <http://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 <tel:%28510%29%20486-7600>
>
> ESnet Office of the CTO (AS293) (800)
> 333-7638 <tel:%28800%29%20333-7638>
>
> Lawrence Berkeley National Laboratory
>
> PGP Key fingerprint = C970 F8D3 CFDD 8FFF 5486 343A 2D31 4478 5F82
> B2B3
>
>
>
>





Archive powered by MHonArc 2.6.16.

Top of Page