perfSONAR User Q&A and Other Discussion

[Mark Feit <>]

Martinez Velasquez, Heberth Fabian writes:

 

Scenario:

When we installed MadDash, we got some errors with the grid, and it has been impossible to read throughput and latency information from jetstream and chameleon, I think the problem is related to the private IP, and for that reason, I tried to implement remote-addresses configuration to set the private Ip but still not working, In our use case we don't have an additional VM connected by a private network, we have a scenario with public and private networks. 

…

I tried to run the tests directly on each VM. In this case, the command used was: 

 

pscheduler task --archive '…' throughput --source 128.110.217.203 --dest 149.165.168.196 - -source-node 128.110.217.203

 

And I got the following error: 

 

Error from 128.110.217.203:

  …

    "error": "unable to connect to server: connection refused"

  …

…

Error from 149.165.168.196:

  Iperf3 returned an error: error – unable to start listener for connection: Cannot assign requested address

 

Diagnostics from 149.165.168.196:

  /usr/bin/iperf3 … -B 149.165.168.196 …

 

 

You’ve mostly hit the nail on the head; the problem isn’t the private addresses, it’s the NAT between it and the outside world.  The plugin for iperf3 forces a bind to the source or destination address depending on which end it’s running.  This works fine at Utah because it has a non-NATted IP but won’t work at  Jetstream2 because no interface has an address of 149.165.168.196. 

 

There is a way around that, fortunately.  The throughput test has a --local-address switch that will let you specify a bind address for the source side of the test.  If you run the test from Jetstream2 to Utah with that switch and reverse the direction, you’ll get the measurement you want:

 

pscheduler task throughput \

    --source 149.165.168.196 --local-address 10.0.109.89 \

    --dest 128.110.217.203 --reverse

 

I think there’s also no reason we couldn’t have a similar switch to force a bind at the destination end as well, so I’ve opened a ticket to consider that for a future release (https://github.com/perfsonar/pscheduler/issues/1323).

 

--Mark

 

P.S.:  Thanks for sending a through description of the problem.  Those help a lot.