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.
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:
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.
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: