Skip to Content.
Sympa Menu

perfsonar-user - RE: [perfsonar-user] Latency task with source and target behind NAT

Subject: perfSONAR User Q&A and Other Discussion

List archive

RE: [perfsonar-user] Latency task with source and target behind NAT


Chronological Thread 
  • From: Ignacio Peluaga Lozada <>
  • To: Mark Feit <>, "" <>
  • Subject: RE: [perfsonar-user] Latency task with source and target behind NAT
  • Date: Wed, 18 Nov 2020 19:25:01 +0000
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 188.184.36.50) smtp.rcpttodomain=internet2.edu smtp.mailfrom=cern.ch; dmarc=bestguesspass action=none header.from=cern.ch; dkim=none (message not signed); arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1giLjyMoI4XngRUt7gL20yFuodMSEThyUBS8hT9krXs=; b=VIJrltvS1oS0BaI7iIWV4ZLPu7QdE9xr2/on5QOvsS20TJRu+XI9Gap46JeGHFnm7ZlS6bUQL+4UqnTUAQoADtsOH4dwW7HpoC7ql7c6woZ6uansEAEMVa23KqKaaBX4XKbPkLpp3iTx0I/kwsDyfgrwRNSwOHeeW/lHCU+kudFcv+AXeuVDOZSuvrd7CoA/KKZeJ3YbGg3cynMZxZvBhWbjJSvyUYy2Pw30+0I/rQy4tQC+e+ZuLZE7vmj0+DWWUapB/T2xeMm9yWxWEkm3sH371rJ50v4TDjnGgazh6DAw/juHhPdGMg2cjyqEXB3+q+3+i09TtjUQJ2s4vO3nAw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=L1rrtr9q4B5437/vP7RR0JoV/wvgsBVJBIxJTIJLQV3c0aWRvxliG2mxeqXzu20oJ1nXbNVPLjfPHs8qEg3Xc7eQSiW7yHSaUEi9nWymy44ZZwg4snT5WezC2PZOpsoxcmtA91aviIz1Ps2c4sE2XnkP/J/4TiP4XAzxzJ49yw0VoCnOK1wHZjZ7yR8FP4Raqpv65rn+C/rRCqIl3oFX3eFgn2bfNlkOrePvqibJGfpnJoz45qfGNaabwZ8diWxodJtFd4C0MOC6tKRvu+gOZv/kz72gNlb88b27bXSpkFvy1BEKlUYJvHkcH+jTM9b+sEc/5rjYgktehA+PZRIFyA==

Hi Mark,

this is what I got:

1) From the testpoint behind NAT to the testpoint with public IP interface
(no NAT):

$ pscheduler troubleshoot --host 89.145.161.126
Performing basic troubleshooting of 89.145.161.126.

89.145.161.126:

Measuring MTU... Unsafe or unknown: Error: Process took too long to
run.
Looking for pScheduler... OK.
Fetching API level... 4
Checking clock... Unsynchronized (Not considered fatal)
Exercising API... Status... Tests... Tools... OK.
Fetching service status... OK.
Checking services... ticker... scheduler... runner... archiver...
OK.
Idle test.... 9 seconds.... Checking archiving... OK.

pScheduler appears to be functioning normally.

2) The other way around:

$ pscheduler troubleshoot --host 80.158.55.226
Performing basic troubleshooting of 80.158.55.226.

80.158.55.226:

Measuring MTU... 1500+
Looking for pScheduler... OK.
Fetching API level... 4
Checking clock... Unsynchronized (Not considered fatal)
Exercising API... Status... Tests... Tools... OK.
Fetching service status... OK.
Checking services... ticker... scheduler... runner... archiver...
OK.
Idle test.... 3 seconds... Failed.

Did not get a result: Resource Not found.

I got these outputs when using the latest version of the image, I tried also
4.2.4 and the outcome was pretty much the same.
Looks like the firewall is not the problem, right?

Thanks.

Regards,
Ignacio

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

Ignacio Peluaga Lozada writes:

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
twping: FILE=owping.c, LINE=1757, Unable to open control connection
to 89.145.161.126.


The control part of that is just a regular TCP connection, so it’s probably a
firewall or ACL problem. Can you do a successful “pscheduler troubleshoot”
between the two hosts?

--Mark




Archive powered by MHonArc 2.6.19.

Top of Page