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: Brian Candler <>
  • To: "Garnizov, Ivan (RRZE)" <>, Andrew Lake <>, "" <>
  • Subject: Re: [perfsonar-user] Perfsonar ports - tracepath blocked
  • Date: Tue, 16 Feb 2016 15:04:52 +0000
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=pobox.com; h=subject:to :references:from:message-id:date:mime-version:in-reply-to :content-type; q=dns; s=sasl; b=jnyMi/wEQk+H14QR12yX9etIRblVkpya 5pF/UdIsZQ1C01nkeclIdjBNAlfJjBQo+GsZr6qkCns+sBNxwneKzastYW1sh0UQ D6wb5+dOFMY6XyBCxjZbn+F/SouyoFtB9/kchsM0jK8Yir+G2vOFmsmQm4mtlMue FQMPHMFIs6E=

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.




Archive powered by MHonArc 2.6.16.

Top of Page