perfSONAR User Q&A and Other Discussion

[Andrew Lake <>]

Hi Ivan/Brian,

I don’t think any of the below is necessary. Brian has done a very thorough job of providing info on what he was seeing and it’s quite clear the only question is whether we should add UDP ports 44444-44644 to the default iptables rules on the perfSONAR host. I suspect the answer is “yes we should”, but i have created an issue on it so we can do our due diligence first. 

Thanks,

Andy

On February 16, 2016 at 10:36:52 AM, Garnizov, Ivan (RRZE) () wrote:

Hi Brian,

 

This is very much clear from your example.

“For one particular burst, the source port is all the same. It might be for example:
source port 36334 -> dest port 44445
source port 36334 -> dest port 44446
source port 36334 -> dest port 44447
source port 36334 -> dest port 44448
... etc
”

 

I read it as: Sender is using UDP port 36334, on reply back use UDP port 36334 as destination. Where do you suggest the intermediate routers should reply?

 

1)      If your destination host firewall rejects the packages to 4444?, then a reply is formed by the end host.

2)      If your destination host firewall drops the packages to 4444?, then there is no reply and tracepath will timeout.

3)      If something on the way blocks these packages then tracepath will timeout.

 

In any case, the way I see it, the replies are expected by the tracepath initiator on the stated port: (case above ingress UDP 36334) and I can only guess this communication is allowed at the initiator host.

 

 

Could you please try running

 

tracepath destination <port>

(port some of the opened ones on the local FW at the initiator http://linux.die.net/man/8/tracepath )

 

And listen/sniff on this port at the host that initiates the tests.

 

Best regards,

Ivan

 

 

From: Brian Candler [mailto:]
Sent: Dienstag, 16. Februar 2016 16:05
To: Garnizov, Ivan (RRZE); Andrew Lake;
Subject: Re: [perfsonar-user] Perfsonar ports - tracepath blocked

 

On 16/02/2016 14:47, Garnizov, Ivan (RRZE) wrote:

There is something sitting behind the 36334 port and if it is tracepath, then your tracepath access is blocked.

One thing might worth checking is whether tracepath requests indeed set the correct port for the sender (in the case below 36334). But that would be, if you really would like to test the implementation of tracepath.

 

udp        0      0 0.0.0.0:36334

0.0.0.0:*                               6344/tracepath

 

Most likely some router is blocking traceroute on its way to the destination and it could be any direction.

That (direction) can be verified easily on the remote end….with sniffing.

I am sorry if I have been unclear, so let me try to explain it again.

A burst of packets is *arriving* one of my perfsonar hosts (from another perfsonar host of mine)

For one particular burst, the source port is all the same. It might be for example:
source port 36334 -> dest port 44445
source port 36334 -> dest port 44446
source port 36334 -> dest port 44447
source port 36334 -> dest port 44448
... etc

A few minutes later, when the next burst is sent, a different source port is used but the same sweep range of destination ports is used.

The source port is the "ephemeral" port I described - one assigned temporarily by the sending side's OS. Using netstat it allows me to show that the sending application is tracepath (not traceroute).

Both my firewall and the perfsonar iptables are configured to allow inbound traffic to ports 33434-33634, which is the range used by traceroute, but not ports 44444-44644 as used by tracepath.

It is nothing to do with intervening routers. The firewall itself (a Cisco ASA) is reporting that the packets *are* arriving, then the firewall is throwing them away. This is what firewalls are supposed to do, if you haven't configured them to allow particular ports.

But these log messages are an indication that something is wrong. They are "unexpected" packets.

Regards,

Brian.