perfSONAR User Q&A and Other Discussion

[Mark Feit <>]

Dan Pritts writes:

 

Mark mentioned below that the way around NAT for perfsonar is to get public IPs.  Unfortunately, it's not that simple in AWS.  Even when you have a public address, your linux instance is given an RFC1918 address and AWS does 1:1 NAT for you.   It's weird, but for almost any application this works just fine.  (With IPv6, they've done away with this, and you can get a plain old routed address.)

…
While gathering information for the NOC, I brought up the latest perfsonar on an aws instance and a system here in Ann Arbor.  I could source tests from AWS, but sourcing from Ann Arbor didn't work - pscheduler never started up iperf3.  Manual iperf3's worked fine, of course, and when I got both ends up with IPv6, it worked fine in both directions. 

 

My guess on that would be that pScheduler on the AWS end did start iperf3 in server mode but it ran into a problem and failed.  There would be diagnostic information available in pScheduler to check on that.  When you run into problems, it’s a good idea to run “pscheduler result --diags RUN-URL” against the failed run to see what happened.  A “pscheduler troubleshoot” between the hosts would be good, too.  Sometimes it’s something as simple as the clocks not being in sync and the times where the client and server start don’t match up.

The iperf3 plugin doesn’t do anything special as far as binding to a particular address by default, so NAT (real 1:1 NAT, not cable modem-style PAT) shouldn’t have any effect on the server side.

So let me put in a feature request - make perfsonar tools work with 1:1 NAT like AWS uses.  Manual configuration would be OK - a quick little entry somewhere that says "my public IP is x.y.z.1".    Sorry if this is there and I missed it; it wasn't for lack of searching. 

 

perfSONAR itself doesn’t have anything in it that’s incapable of dealing with NAT, but the protocols used by some of the tools we integrate don’t tolerate it well.  What we’d need to do is a tool-by-tool analysis of the problem and see whether the way the plugins use them can be improved or whether there would need to be changes to the tools themselves.  The latter may pose difficulties because we don’t maintain many of them.

 

We have some time set aside to discuss how we’re going to deal with cloud computing at our upcoming developer meeting and will wrap this topic into it.

 

--Mark