perfSONAR User Q&A and Other Discussion

[Alan Whinery <>]

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