perfSONAR User Q&A and Other Discussion

["Cottrell, Les" <>]

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




-- 

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