I am trying to prevent a Cisco 2911 router's IP address from appearing in an inbound traceroute. I have configured the line:

no ip unreachables

on the Internet-facing interface, and while this successfully prevents a response to a traceroute probe when the destination is the router itself, it does NOT prevent the router from showing up in a traceroute to hosts behind the router. I am desiring to prevent the router from showing up not only in the typical, standard ICMP traceroutes but also 'tcptraceroute' and anything else that would completely trace the route into the network and to the destination.

I am vaguely aware of some kind of access list configuration whereby one would block the ICMP unreachables (and others) and then apply it to the interface, with perhaps trusted hosts added as exceptions. If this is indeed the way to do this, how would I configure my Cisco?

Has anyone implemented something similar to this and, if so, how? If not, how would you propose to do this?

  • 2
    Yes! please block ICMP an break the Internet! If you ever do IPv6 I advise you to completely block ICMPv6. It makes your network save!
    – user2084
    Sep 1, 2016 at 10:01

2 Answers 2


You don't block the icmp unreachables - which are sent by your router - but the inbound packets sent by the traceroute or other tool, that have a TTL (time to live) of 1. See e.g. Cisco Guide to Harden Cisco IOS Devices - look for the section " Filter on TTL Value"

edit: corrected url

edit: note that in that Cisco document the example filters everything with a TTL < 6. This way you also prevent the next 4 hops in your network to appear in the traceroute without having to add an ACL to those routers as well (assuming all traffic passes through the router you are configuring). Also note that the number 6 is just an arbitrary example, you should use a value based on the diameter of your network (maximum number of hops a packet might traverse within your network). An added benefit of this is that traceroute will still work within your network.

edit: Please note that as Brendan notes in the comments, some protocols like BGP, IGMP, ... may require you to make exemptions in the ACL as they use low TTL values.

  • I setup the rule as specified to block inbound packets w/ TTL < 6, and while I cannot then traceroute to hosts behind the router successfully, the router IP itself is still showing up. It's just showing as the last hop. Then after a period of time, it seemed to have actually just died off - I added exemptions to the rule (permit) for the BGP peer IP, and even with that, I lost connectivity. So I went in (from another route) and removed the ACL rule, and had to soft clear BGP to get it working again. eBGP requires the TTL i guess but i DID exempt. Any ideas?
    – Brendan
    Sep 3, 2016 at 2:43
  • Okay got it working again; got the allow rules in there for the BGP address for eBGP. But still - the IP of the router still shows up in a traceroute, its just the last hop instead of passing on to inside the network. I want the router itself to not show up as the last hop.
    – Brendan
    Sep 3, 2016 at 2:50
  • Yet another update - I added 'no ip unreachables' to the interface configuration directives as well, and it achieves the desired effect of the router IP not showing up. However, a 'traceroute' successfully traces to the destination host - there are just SIX missed hops, and then the host shows up. Any idea with that? Besides this, it seems the solution is: set the ip access group to block TTL lt 6, make sure you PERMIT your BGP peers if you use eBGP since it requires use of TTL, and set no ip unreachables on the interface as well. But I'd like to know why the destination is being traced...
    – Brendan
    Sep 3, 2016 at 2:53
  • If there are 6 missed hops and then the host, it means you don't filter enough hops :) So try filtering TTL<7 in your case.
    – hertitu
    Sep 5, 2016 at 7:22

You will need to block the ICMP "time-exceeded" messages in order to keep the router from showing up in traceroute output.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.