Skip to Content.
Sympa Menu

perfsonar-user - Re: [perfsonar-user] I need your advice: basic use of perfSONAR

Subject: perfSONAR User Q&A and Other Discussion

List archive

Re: [perfsonar-user] I need your advice: basic use of perfSONAR


Chronological Thread 
  • From: Eli Dart <>
  • To:
  • Cc:
  • Subject: Re: [perfsonar-user] I need your advice: basic use of perfSONAR
  • Date: Thu, 23 Aug 2018 08:39:18 -0700
  • Ironport-phdr: 9a23:SEk/xRVHD60tU1SHDf9BK59dN73V8LGtZVwlr6E/grcLSJyIuqrYYh2Ct8tkgFKBZ4jH8fUM07OQ7/i/HzRYqb+681k6OKRWUBEEjchE1ycBO+WiTXPBEfjxciYhF95DXlI2t1uyMExSBdqsLwaK+i764jEdAAjwOhRoLerpBIHSk9631+ev8JHPfglEnjWwba9wIRmssQndqtQdjJd/JKo21hbHuGZDdf5MxWNvK1KTnhL86dm18ZV+7SleuO8v+tBZX6nicKs2UbJXDDI9M2Ao/8LrrgXMTRGO5nQHTGoblAdDDhXf4xH7WpfxtTb6tvZ41SKHM8D6Uaw4VDK/5KptVRTmijoINyQh/W7YhMx/jqJVrhyiqRJi3YDbfJqYO+Bicq7HZ94WWXZNU8RXWidcAo28dYwPD+8ZMOhXq4n9pkYFoxWkCgm2GOPk1zhFiWLs0q0gz+QsCh/J3Bc6E9IIrnvUsMz4OaEPWu67y6nIyC/Mb/JQ2Trl9ofIaQotofeSUrJsd8fa1EohFxvdg1mNt4DoPCmZ2+oXv2WU8uZsT+Oihm0/pw1vvjSiwt0gh4rJi44P1FzI6yt0zJwoKdC8TEN2Z8OvHoFKuCGALYR2R9svQ2F2tyY+zb0LoZC7czYExZg9wx7QcPiHf5KH4hLkSuadOTZ4hHR7d7Kjnxu+7Fasx+7mWsS6ylpHoTdJnsPNu30OzxDT79KISvp5/kevwzaP0AXT5/lZLk8uj6rbN4UszaArlpYJt0TMADP2lF3sjKCKbkUk5vSo6+P/b7X+uJCcLYF0ihr5MqQogMO/G/00MhUVX2eF4+Sxz7nj/UziQLVWlf06jLPVsJHcJcQHuKG5GQlV3Zg/6xqhFTupzskXnWRUZG5CLQiAhYXzJ1bFKer+BKzhq1upmTZvgfvBO+7PGJLIe1XHkf/NdKxhoxpQwRAv5d1EoZRZFudSc7rIRkbtuYmAXVcCOAuuzrO/BQ==

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 



Archive powered by MHonArc 2.6.19.

Top of Page