4

AFAIK tcptraceroute is the best tool to check if a firewall is blocking the tcp connection to a service. (If you know a better tool, please let leave a comment)

Some hops do not reply. See * * *

remotehost:~ # tcptraceroute ftp.example.com ftp
Selected device eth0, address 10.172.19.11, port 40768 for outgoing packets
Tracing the path to ftp.example.com (10.101.7.124) on TCP port 21 (ftp), 30 hops max
 1  * * *
 2  172.18.56.12  0.407 ms  0.222 ms  0.230 ms
 3  * * *
 4  * * *
 5  * * *
 6  * * *
 7  10.102.1.1  32.017 ms  31.728 ms  31.486 ms
 8  * * *
 9  10.101.7.124 [open]  31.728 ms  32.391 ms  33.549 ms

Is there a term for the behaviour of these hops?

How to call this, if the hop does not respond, and I see * * * in the output?

(Unfortunately I don't have 300 reputations and can't create the new tag "tcptraceroute")

Background: I would like to tell the people how are responsible for the network, that they should use routers which do NOW-I-AM-MISSING-THE-MAGIC-TERM.

guettli
  • 3,113
  • 14
  • 59
  • 110
  • 2
    This can be caused by an MPLS network with L2/L3 VPNs or by firewalls which are configured not to send back any ICMP packets. – Tommiie Sep 06 '18 at 07:38
  • AFAIK there is no generic term. – Zoredache Sep 06 '18 at 07:41
  • @Tom how to call this behaviour? – guettli Sep 06 '18 at 08:01
  • As Zoredache said, there is no specific term for it. Also, sometimes firewalls don't lower the TTL so they don't appear as a hop in the traffic path. There's also no name for that. – Tommiie Sep 06 '18 at 08:04
  • It just happens simply with an host not answering the TCP SYN packet. tcptraceroute then increments the TTL after some time, to hit the next host. – Patrick Mevzek Sep 08 '18 at 22:28
  • 2
    @Tom `tcptraceroute` does not use ICMP at all (which is why it is a good tool, far superior to `ping` and `traceroute`) and only TCP: it does a TCP SYN, then it gets back either: no response, or TCP RST, or TCP SYN+ACK – Patrick Mevzek Sep 08 '18 at 22:30
  • @PatrickMevzek One of the `traceroute` implementations available on Ubuntu can also send TCP SYN packets. As far as I recall it's the one installed by default. – kasperd Oct 19 '18 at 10:27
  • @guettli The word I'd use to describe that behavior is misconfigured. – kasperd Oct 19 '18 at 10:28
  • I went to read the relevant RFCs, and it turns out in IPv4 it is optional for routers to respond but in IPv6 it is mandatory. In IPv4: "The gateway **may** also notify the source host via the time exceeded message." [RFC 792](https://tools.ietf.org/html/rfc792). In IPv6: "If a router receives a packet with a Hop Limit of zero, or if a router decrements a packet's Hop Limit to zero, it **MUST** discard the packet and originate an ICMPv6 Time Exceeded message with Code 0 to the source of the packet." [RFC 4443](https://tools.ietf.org/html/rfc4443). – kasperd Oct 19 '18 at 10:45
  • @kasperd "One of the traceroute implementations available on Ubuntu can also send TCP SYN packets. As far as I recall it's the one installed by default. " which is not the point as by default (without specific options), `traceroute` will do UDP which is not good for many troubleshooting. People knowing things will know the appropriate flags (`tcptraceroute` is often just a wrapper around `traceroute` with appropriate flags`, but if you just say "use traceroute", people will do not the correct thing by default. – Patrick Mevzek Oct 19 '18 at 13:21
  • @PatrickMevzek I'd much rather blame those who configure networks in a way that break debugging tools than I'd blame this on the debugging tools or the users. – kasperd Oct 19 '18 at 13:27
  • @kasperd " I'd much rather blame those who configure networks in a way that break debugging tools " I completely disagree with that assumption. If you want to troubleshoot a webserver, the appropriate debugging tool is a TCP query to port 80, if it is SMTP then it is TCP port 25, if it is DNS it use TCP **AND** UDP in port 53, etc. In short traceroute doing UDP is almost never the appropriate debugging tool... it is only if you are debugging a service based on UDP. In other cases you need troubleshooting using TCP. – Patrick Mevzek Oct 19 '18 at 13:30

2 Answers2

1

As already stated in the comments, there is no real answer to this (so I feel a little silly for typing this, but it would become too long for a comment). What you're seeing is just tcptraceroute saying it did not get a response back from the hop. There is no term for this, it's just the way traceroute was designed. When the hop does not reply to the ICMP request, you get a * response, meaning nothing was returned, so a response in the form of a ping response time could not be determined.

So to get to your background:

I would like to tell the people how are responsible for the network, that they should use routers which do NOW-I-AM-MISSING-THE-MAGIC-TERM.

Just tell them that they should have their routers block ICMP requests and voila, they'll understand what you mean with just a few words. Also because it's not so much a feature, but a setting. So you don't "use routers that block ICMP requests", you instruct them to do that (it might be the default setting, but it's a setting nevertheless). The people responsible for the network should know that.

Oldskool
  • 2,005
  • 1
  • 16
  • 26
  • 4
    You wrote "Just tell them that they should have their routers block ICMP requests". Why should they block ICMP? – guettli Oct 19 '18 at 14:20
1

There's not really an exact word for that, but to help you with your dialogue with those who manage that network you might look into CoPP (Control Plane Policing)

It's worth noting that the device may not actually be set to deny these packets, it may just be rate-limiting them, so if you want responses you can ask them exclude certain IPs from the rate limit or raise the limit for everything if that is desired.

I'll warn you that you might have a hard time getting the network team to make these changes as they are there to protect the device from DoS attacks or normal-use overload on the control plane.

From Cisco's docs, below are some of the effects that can be seen if the control plane is overloaded:

  • Reduced service quality (such as poor voice, video, or critical applications traffic)
  • High route processor or switch processor CPU utilization
  • Route flaps due to loss of routing protocol updates or keepalives
  • Unstable Layer 2 topology
  • Slow or unresponsive interactive sessions with the CLI
  • Processor resource exhaustion, such as the memory and buffers
  • Indiscriminate drops of incoming packets
Harrison Gibbs
  • 369
  • 1
  • 8