Skip to Content.
Sympa Menu

perfsonar-user - Re: [perfsonar-user] Perfsonar ports - tracepath blocked

Subject: perfSONAR User Q&A and Other Discussion

List archive

Re: [perfsonar-user] Perfsonar ports - tracepath blocked


Chronological Thread 
  • From: Andrew Lake <>
  • To: Brian Candler <>, "" <>
  • Subject: Re: [perfsonar-user] Perfsonar ports - tracepath blocked
  • Date: Tue, 16 Feb 2016 10:03:17 -0500

Hi Brian,

I think you’re right that it’s either an oversight or that tracepath doesn’t really need it. If it’s the latter I imagine someone looked at this back when we did the firewall rules and didn’t note it anywhere so I am not 100% sure of the answer. At the very least it does not need it to report it get to the last hop. I have not yet tried a case where the MTU changes on the last hop though, but it’s quite likely that the MTU will not be reported. If this is the case, then it is probably worth exploring whether we should add those ports to the default firewall config. I am adding an issue for this for someone to explore. 

Thanks,
Andy



On February 16, 2016 at 9:56:48 AM, Brian Candler () wrote:

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.




Archive powered by MHonArc 2.6.16.

Top of Page