perfSONAR User Q&A and Other Discussion

["Garnizov, Ivan" <>]

Hello George,

 

From what you have sent one can see:

 

Case 1:  “from uhmanoa-tp.ps.uhnet.net: Could not resolve host: enpl-pt2-10g.eos.nasa.gov”

Most likely your DNS resolution fails for this FQDN.

My take from here is that the message from pScheduler has ambiguity and it is not clear enough, which participant does the reporting and which has the failure.

 

Case 2: Success with IPv4 address in destination

Apparently the remote participant is live and running and pScheduler coordination / connectivity is present on the specified address.

 

Case 3: pscheduler is unable to use an IP address to bind to the lead interface…

Perhaps that can become a feature request…, but even if it did succeed and your DNS resolution of the destination still fails, you would get in the end the same failure as in case 1.

 

 

In order to be able to further assist you or open a case for a bug, please demonstrate, that you are able to resolve on the enpl-pt2-10g.eos.nasa.gov the hostname of uhmanoa-tp.ps.uhnet.net

 

 

Regards,

Ivan Garnizov

 

GEANT WP6T3: pS development team

GEANT WP7T1: pS deployments GN Operations

GEANT WP9T2: Software governance in GEANT

 

 

 

Von: [mailto:] Im Auftrag von Uhl, George D. (GSFC-423.0)[Arctic Slope Technical Services, Inc.]
Gesendet: Freitag, 6. Dezember 2019 20:44
An:
Betreff: [perfsonar-user] FW: Dual stack throughput test failures

 

Forward to pS user list.

 

From: "George.D.Uhl" <>
Date: Friday, December 6, 2019 at 10:40 AM
To: "" <>
Subject: Dual stack throughput test failures

 

Hi,

 

I run a mesh with a dual stack local host that is failing to run ipv4 throughput tests to any non-agent dual stack remote host when the remote host shares a single hostname for IPv4 and IPv6.  I’ve attached some test cases showing conditions when tests work vs. when they fail.

 

Specifying ip-version as IPv4 in the pscheduler command line doesn’t seem to make a difference.  The local test node has an advanced configuration which includes multiple test interfaces, policy routing and a non-test interface that is used by the main routing table as the default path.  The issue appears that the non-agent remote host prefers using it’s IPv6 address when it translates the “--destination hostname” given to it by the local pscheduler during test setup/tool negotiation.  Thus the ip-version parameter is used to specify the protocol for testing only and isn’t used as part of the test setup.  Would it be possible to support a new feature that specidies the preferred protocol during test setup?

 

Thanks,

George