perfSONAR User Q&A and Other Discussion

[Brian Candler <>]

On 16/02/2016 13:56, Andrew Lake wrote:

One clarification, we’re talking about a UDP socket so no connection is actually established. I believe tracepath, much like UDP traceroute, is just firing off UDP packets with the hope of generating ICMP error messages it can use to produce it’s results. It doesn’t much care nor expect anything on the other end. Running a few tests the tracepath tests look complete to me even to hosts blocking ephemeral UDP ports. Did you encounter some cases where this was not the case?

1. I have several perfsonar boxes behind firewalls
2. I opened up all the ports which the documentation said should be opened
3. Firewall logs showed that box A was periodically trying to talk to box B on UDP ports 44445 upwards, and the firewall was blocking these packets and logging them.

The problem is that I don't like seeing lots of rejects in my firewall logs - it means something isn't right :-(

4. Mapping the ephemeral source port used by A with netstat showed that it was a tracepath process at the other side which was generating the packets
5. Checking the iptables rules for perfsonar shows that traceroute (33434 upwards) is enabled, but not tracepath.

My conclusions: either
- perfsonar developers forgot about the tracepath ports (in iptables, and in the documentation)
or
- tracepath doesn't really need the last hop (e.g. if you're only concerned about the MTU of intervening hops)
or
- tracepath is happy with an ICMP "Admin Prohibited" response (I haven't checked if perfsonar's use of iptables generates that)
or
- something else that I don't understand

Regards,

Brian.