perfSONAR User Q&A and Other Discussion

[Roberto Carna <>]

Dear Eli, you are very clear....I've undertood.

Now it's time to implemenmt and play with perfSONAR.

Thanks a lot again, regardds !!!
El jue., 23 ago. 2018 a las 12:39, Eli Dart 
(<>)
 escribió:
>
> Hi Roberto,
>
> You can put the perfSONAR box wherever you want - it's just that placement 
> has implications for what you're testing and what you can learn with the 
> tests you can run from a given perfSONAR host.
>
> If you connect a perfSONAR host directly to your border router, it gives 
> you a way to measure performance between distant networks and your network 
> without impact by your firewall.
>
> If you only connect a perfSONAR host to your network behind your firewall, 
> then you won't be able to tell what part of the test results might be due 
> to the firewall and what might be due to something else.
>
> Ideally, you'd have a perfSONAR host in front of your firewall and one 
> behind (but don't run throughput tests directly between them). This 
> configuration allows you to compare the performance of test flows which 
> traverse the firewall and those that do not traverse the firewall, and can 
> tell you something about whether your firewall is impacting your 
> performance (many firewalls do, some do not). The kind of testing 
> methodology which uses this (long distance testing using different local 
> testers to try and isolate local problems) is further described here: 
> http://fasterdata.es.net/performance-testing/perfsonar/perfsonar-success-stories/long-distance-troubleshooting/
>
> If you connect the perfSONAR host to your Science DMZ, you can measure the 
> network performance that your DTNs are likely to see.
>
> There is no one "right" way, and no one "right" placement for perfSONAR 
> hosts - it's just a question of what you can and can't learn from tests 
> conducted from a particular location within your network. The answer is 
> always "it depends."
>
> Eli
>
>
> On Thu, Aug 23, 2018 at 8:27 AM Roberto Carna 
> <>
>  wrote:
>>
>> Dear Eli, thank you very much for your time and explanation.
>>
>> Please just a new short question: I was viewing some perfSONAR network
>> diagrams and I could see the perfSONAR servers is always located
>> behind the border router and in front of the corporative firewall.
>> This is your recommendation or can I put the perfSONAR server behind
>> the corporative firewall, sharing a given DMZ with other production
>> servers?
>>
>> Regards !!!
>> El jue., 23 ago. 2018 a las 12:17, Eli Dart 
>> (<>)
>>  escribió:
>> >
>> > Hi Roberto,
>> >
>> > This strikes me as a situation where details are going to matter - 
>> > potentially a lot.
>> >
>> > The L2L tunnel is presumably carrying a bunch of production 
>> > traffic.....I'd want to be sure that I understood the bandwidth 
>> > available on that tunnel before I did any throughput testing over it. 
>> > This includes several things, such as the capabilities of the hardware 
>> > at both ends (interface speeds, tunnel encapsulation/decapsulation 
>> > performance, CPU vs. hardware implementation for tunnel encap/decap, 
>> > etc), what the background traffic characteristics look like (is there a 
>> > bunch of loss-sensitive stuff running over this, what does the blast 
>> > radius for mistakes look like, e.g. does all the phone and video traffic 
>> > traverse it, etc), how the L2L link is integrated into the rest of your 
>> > infrastructure (lots of fan-in, high-speed router vs. cheap low-speed 
>> > router, etc) and so on.
>> >
>> > One thing you might start with is a set of OWAMP boxes, one or two at 
>> > each site depending on how your network is built. Then yes - test across 
>> > the L2L path as well as out to SANReN from each site, and see what you 
>> > can see from a latency/loss perspective. After that, decide how to 
>> > proceed next.
>> >
>> > If this sounds overly-cautious, it might be. However, tunnels are 
>> > tricky. You're dealing with not only the parameters of the local links 
>> > and the local hardware you're running (including several different 
>> > layers just on that stuff), but also everything that the provider is 
>> > doing. Because you're in a tunnel, you can't see the characteristics of 
>> > the tunnel path from within the tunnel - from the perspective of tests 
>> > which traverse the tunnel all you can see is that there is one hop (the 
>> > tunnel) which may or may not have consistent behavior and may or may not 
>> > be able to handle load or bursts or whatever.  Now, if you can engineer 
>> > a perfSONAR test that runs outside the tunnel and traverses the same 
>> > path as the tunnel, that could be very valuable. Then of course you'll 
>> > need to figure out whether your testing competes with the tunnel in a 
>> > way that causes performance problems (e.g. congestion) for the 
>> > encapsulated traffic, but you'll have a way of comparing tests within 
>> > the tunnel to tests outside the tunnel on the same path, which can help 
>> > identify whether problems you might see exist inside or outside the 
>> > tunnel. That can help with attribution.
>> >
>> > Anyway - definitely go forward, and definitely start running tests. I 
>> > would just be cautious with throughput testing at first, and I would 
>> > make sure I understood all the interactions involved before I started 
>> > filling pipes.
>> >
>> > Eli
>> >
>> >
>> >
>> >
>> > On Thu, Aug 23, 2018 at 7:57 AM Roberto Carna 
>> > <>
>> >  wrote:
>> >>
>> >> Dear, I need your advice please:
>> >>
>> >> We have two corporate networks communicated between them by a L2L
>> >> link, and connected to Internet too.
>> >>
>> >> In order to start testing and using pefSONAR, do you think it's a good
>> >> idea to put one perfSONAR server in each site of our company (in a DMZ
>> >> behind both firewalls)  in order to measure the L2L link parameters,
>> >> and also connect these perfSONAR servers to a SANReN perfSONAR server
>> >> near us ???
>> >>
>> >> Thanks a lot, regards !!!
>> >
>> >
>> >
>> > --
>> >
>> > Eli Dart, Network Engineer                          NOC: (510) 486-7600
>> > ESnet Science Engagement Group                           (800) 333-7638
>> > Lawrence Berkeley National Laboratory
>
>
>
> --
>
> Eli Dart, Network Engineer                          NOC: (510) 486-7600
> ESnet Science Engagement Group                           (800) 333-7638
> Lawrence Berkeley National Laboratory