perfSONAR User Q&A and Other Discussion

[Ignacio Peluaga Lozada <>]

Hi Mark,

okay I understand, thanks for the clarification. We will see if we can do 
something with IPv6 considering pscheduler allows using it with its 
'--ip-version' option.

Besides that, I have a question about the case when we have source (only) 
behind NAT. 
Once again I have two VMs, on each there's a perfSONAR Docker container 
running. 
Source VM is behind nat but target isn't, it has an interface with a public 
IP, 89.145.161.126. 

So my question is, why can't I run twping to it? I tried the following (for 
all the possible combinations 4.2.4-latest for source and target):

        twping -Z 89.145.161.126 

And I get always:

        twping: FILE=owping.c, LINE=1757, Unable to open control connection 
to 89.145.161.126.

On the other hand, this works:

        twping -Z psb01-gva.cern.ch

Do you have any idea what could be wrong? on both ends I deploy the 
containers with: 

        docker run -d --net=host <image>

Thanks in advance.

Regards,
Ignacio

________________________________________
From: Mark Feit []
Sent: 16 November 2020 13:44
To: Ignacio Peluaga Lozada; 
Subject: Re: Latency task with source and target behind NAT

Ignacio Peluaga Lozada writes:

our goal is to be able to run tests between two VMs both behind NAT.
NAT on both ends isn’t a use case we support.  The testing infrastructure 
(i.e., pScheduler) and some of the tools can handle it, but others can’t.  
Unfortunately, the tools that measure latency fall into the “can’t” category.
We’ve had semi-regular discussions over the last several years about how to 
support it, and the conclusion has always been that there are too many 
permutations to deal with (true NAT, PAT with hole punching, etc.) to make it 
work universally.  True NAT is what many cloud environments provide and is 
also the easiest to deal with.  What’s missing on our end is the developer 
cycles to dig into the packages and figure out what it will take to make it 
work.
--Mark