Skip to Content.
Sympa Menu

perfsonar-user - Re: [perfsonar-user] ESnet Dashboard Testing Results

Subject: perfSONAR User Q&A and Other Discussion

List archive

Re: [perfsonar-user] ESnet Dashboard Testing Results


Chronological Thread 
  • From: Jason Zurawski <>
  • To: John Bell <>
  • Cc: "" <>
  • Subject: Re: [perfsonar-user] ESnet Dashboard Testing Results
  • Date: Tue, 20 Oct 2015 15:48:34 -0500

Greetings John;

Was this host configured to be jumbo frames, and was the network it is attached to (entire broadcast domain) configured the same?  When I look at the host info (e.g. http://ps-dmz-1.unm.edu/toolkit/, then click 'details' on the right, near the word 'interfaces') the host seems to suggest its 9000 byte configured.  Ping from an ESnet host seems to indicate this is not possible:

[rootjz@ga-pt1 ~]# ping -c 5 -s 8972 198.83.92.4
PING 198.83.92.4 (198.83.92.4) 8972(9000) bytes of data.

--- 198.83.92.4 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 13999ms


I can ping using a regular frame:

[rootjz@ga-pt1 ~]# ping -c 5 -s 1472 198.83.92.4
PING 198.83.92.4 (198.83.92.4) 1472(1500) bytes of data.
1480 bytes from 198.83.92.4: icmp_seq=1 ttl=58 time=39.6 ms
1480 bytes from 198.83.92.4: icmp_seq=2 ttl=58 time=39.7 ms
1480 bytes from 198.83.92.4: icmp_seq=3 ttl=58 time=39.6 ms
1480 bytes from 198.83.92.4: icmp_seq=4 ttl=58 time=39.7 ms
1480 bytes from 198.83.92.4: icmp_seq=5 ttl=58 time=39.6 ms

--- 198.83.92.4 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4042ms
rtt min/avg/max/mdev = 39.636/39.687/39.757/0.047 ms

But no more:

[rootjz@ga-pt1 ~]# ping -c 5 -s 1473 198.83.92.4
PING 198.83.92.4 (198.83.92.4) 1473(1501) bytes of data.

--- 198.83.92.4 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 13999ms


I would suggest either downgrading the host to 1500, or verifying that everything on the network is capable of handling 9000.  In any event, BWCTL wont work if the MTU settings are inconsistent. 

Thanks;

-jason

John Bell wrote:

Hi Jason,

 

Thank you for the reply. It seems that there have been a massive set of rules added to itpables. The ports you mentioned are allowed:

 

[ps-dmz-1 ~]$ sudo cat /etc/sysconfig/iptables | grep perf

:perfSONAR - [0:0]

-A INPUT -j perfSONAR

-A perfSONAR -p icmp -m icmp --icmp-type any -j ACCEPT

-A perfSONAR -p ipv6-icmp -j ACCEPT

-A perfSONAR -p tcp -m tcp --dport 80 -m state --state NEW,ESTABLISHED -j ACCEPT

-A perfSONAR -p tcp -m tcp --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT

-A perfSONAR -p udp -m udp --dport 123 -m udp -j ACCEPT

-A perfSONAR -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 8090 -j ACCEPT

-A perfSONAR -p udp -m udp --dport 33434:33634 -j ACCEPT

-A perfSONAR -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 8000 -j ACCEPT

-A perfSONAR -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 8001:8020 -j ACCEPT

-A perfSONAR -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 843 -j ACCEPT

-A perfSONAR -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 7123 -j ACCEPT

-A perfSONAR -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 3001:3003 -j ACCEPT

-A perfSONAR -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 861 -j ACCEPT

-A perfSONAR -p udp -m udp --dport 8760:9960 -j ACCEPT

-A perfSONAR -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 4823 -j ACCEPT

-A perfSONAR -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 6001:6200 -j ACCEPT

-A perfSONAR -p udp -m udp --dport 6001:6200 -j ACCEPT

-A perfSONAR -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 5000:5900 -j ACCEPT

-A perfSONAR -p udp -m udp --dport 5000:5900 -j ACCEPT

-A perfSONAR -p udp -m udp --dport 5001:5300 -j ACCEPT

-A perfSONAR -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 5001:5300 -j ACCEPT

-A perfSONAR -p udp -m udp --dport 5001:5300 -j ACCEPT

-A perfSONAR -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 5001:5300 -j ACCEPT

-A perfSONAR -p udp -m udp --dport 5301:5600 -j ACCEPT

-A perfSONAR -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 5301:5600 -j ACCEPT

-A perfSONAR -p udp -m udp --dport 5301:5600 -j ACCEPT

-A perfSONAR -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 5301:5600 -j ACCEPT

-A perfSONAR -p udp -m udp --dport 5601:5900 -j ACCEPT

-A perfSONAR -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 5601:5900 -j ACCEPT

-A perfSONAR -p udp -m udp --dport 5601:5900 -j ACCEPT

-A perfSONAR -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 5601:5900 -j ACCEPT

-A perfSONAR -p udp -m udp --dport 6001:6200 -j ACCEPT

-A perfSONAR -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 6001:6200 -j ACCEPT

-A perfSONAR -p udp -m udp --dport 6001:6200 -j ACCEPT

-A perfSONAR -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 6001:6200 -j ACCEPT

-A perfSONAR -p udp -m udp --dport 8760:9960 -j ACCEPT

-A perfSONAR -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 8760:9960 -j ACCEPT

-A perfSONAR -p udp -m udp --dport 8760:9960 -j ACCEPT

-A perfSONAR -p tcp -m state --state NEW,ESTABLISHED -m tcp --dport 8760:9960 -j ACCEPT

-A perfSONAR -j RETURN

 

 

What else could cause this issue? There is no network firewall between this host and the internet.

 

 

-- John Bell

IT Networks

University of New Mexico

 

From: [] On Behalf Of Jason Zurawski
Sent: Tuesday, October 20, 2015 1:35 PM
To: John Bell
Cc:
Subject: Re: [perfsonar-user] ESnet Dashboard Testing Results

 

Greetings John;

BWCTL requires some more ports than just 6001-6200 unfortunately - the full listing is here:

    http://www.perfsonar.net/deploy/security-considerations/#Using_perfSONAR_with_Firewalls

In particular it needs 6001-6200/tcp,udp, 4823/tcp (control) and 5001-5900/tcp,udp (test ports). 

Thanks;

-jason

John Bell wrote:

Hello Everyone,

 

We recently added our Science DMZ perfSONAR nodes to the perfSONAR Dashboard hosted by ESnet (ps-dashboard [dot] es [dot] net).

 

We are listed under the University categories.

 

With one our PF servers, the one related to BWCTL testing, data has not appeared since it has been added a few weeks back. I thought at first it was due to scheduling, but the another of our hosts has since been showing results. When I dig into the events on the dashboard, I see:

“Error from bwctl/:

bwctl: Unable to initiate peer handshake with [198.83.92.4]:6145 – canceling”

 

On my local host, we have IPTables running but there are rules in place for allowing these ports:

16   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW,ESTABLISHED tcp dpts:6001:6200

17   ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp dpts:6001:6200

32   ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp dpts:6001:6200

33   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW,ESTABLISHED tcp dpts:6001:6200

34   ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           udp dpts:6001:6200

35   ACCEPT     tcp  --  0.0.0.0/0            0.0.0.0/0           state NEW,ESTABLISHED tcp dpts:6001:6200

 

I see this message in the /var/log/perfsonar/owamp_bwctl.log:

Oct 20 12:44:31 ps-dmz-1 bwctld[13490]: FILE=sapi.c, LINE=353, Connection to (ps-dmz-1.unm.edu:6070) from (atla-pt1.es.net:37802)

Oct 20 12:44:42 ps-dmz-1 bwctld[13491]: FILE=sapi.c, LINE=353, Connection to (ps-dmz-1.unm.edu:4823) from (elpa-pt1.es.net:59341)

Oct 20 12:44:49 ps-dmz-1 bwctld[13490]: FILE=sapi.c, LINE=391, BWLControlAccept(): Unable to read ClientGreeting message

 

 

With this information, are we able to determine why the bwctl test is failing?

 

Thank you for your time,

 

-- John Bell

IT Networks

University of New Mexico

 

 





Archive powered by MHonArc 2.6.16.

Top of Page