Skip to Content.
Sympa Menu

perfsonar-user - Re: [perfsonar-user] Problem with Persfonar firewall ports

Subject: perfSONAR User Q&A and Other Discussion

List archive

Re: [perfsonar-user] Problem with Persfonar firewall ports


Chronological Thread 
  • From: Mark Feit <>
  • To: Raul Lopes <>, Szymon Trocha <>
  • Cc: "" <>, Tim Chown <>, Ivan Garnizov <>
  • Subject: Re: [perfsonar-user] Problem with Persfonar firewall ports
  • Date: Thu, 27 Feb 2020 03:17:38 +0000

Raul Lopes writes:

 

I'd like an option like

  pscheduler task --rawtool iperf3 ...

 

That’s not in the cards.  pScheduler was designed to not be a proxy for running individual tools directly.

 

The task command has a --tool switch that allows specifying the tool(s) to use and the throughput test has a --single-ended switch which, for iperf2 and iperf3, will run a test without trying to schedule it with the far end.  That only works in the pScheduler-to-iperf3 direction.  If you need to test iperf3-to-pScheduler, you can still run a single-ended task on the pScheduler node and use the throughput test’s --reverse switch.

 

If you need to reserve some time on pScheduler’s timeline where it won’t run any non-background tasks, there’s a test called idleex that will do nothing and grab exclusive use of the system while it’s running.  (For example, pscheduler task idleex --duration PT5M will give you five minutes.)

 

 

As for what appears to be the problem, specifically:


[PSREMOTE@ps03 ~]$ pscheduler task throughput --source ps03-ban --dest ps01-ban

Submitting task...

Failed to post task: Error getting tools from ps01-ban: Connection timed out after 10001 milliseconds

 

This is part of the pScheduler-to-pScheduler negotiation that takes place long before iperf3 is ever involved.  In this case, pScheduler is trying to connect from ps03 or ps03-ban to the HTTPS port on ps01-ban and failing.    Without access to ps03, my guess would be that ps01-ban or the network between them is dropping traffic to the HTTPS port rather than the usual refusal or no-route reaction.

 

If that can’t be corrected, there are some ways to control how pScheduler handles is communication with other pSchedulers.  The first is lead binding, which is described at https://github.com/perfsonar/pscheduler/wiki/Binding-Requests.  The second is that tests with source, dest or host parameters have companion source-node, dest-node or host-node parameters that specify what address should be connected to so pScheduler can negotiate.  Putting all of this together for your task might look like this:

 

pscheduler task --lead-bind ps03-ban throughput --source ps03-ban --dest ps01-ban --dest-node ps01

 

 

Hope that helps get you a little closer to getting your tasks to run.

 

--Mark

 




Archive powered by MHonArc 2.6.19.

Top of Page