cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
126348
Views
68
Helpful
9
Replies

no ip unreachables

davidhuynh5
Level 1
Level 1

What is the purpose of this command?

What will happen if I disable it on an interface?

Thanks in advance.

9 Replies 9

Hi,

ICMP message type 3 is an unreachable message. Within this message type are a number of "codes" which define various types of messages. This table is from IANA and shows the various types:
3 Destination Unreachable [RFC792]

Codes:


0 Net Unreachable [RFC792]
1 Host Unreachable [RFC792]
2 Protocol Unreachable [RFC792]
3 Port Unreachable [RFC792]
4 Fragmentation Needed and Don't [RFC792]
Fragment was Set [RFC792]
5 Source Route Failed [RFC792]
6 Destination Network Unknown [RFC1122]
7 Destination Host Unknown [RFC1122]
8 Source Host Isolated [RFC1122]
9 Communication with Destination [RFC1122]
Network is Administratively Prohibited
10 Communication with Destination Host is [RFC1122]
Administratively Prohibited
11 Destination Network Unreachable for Type [RFC1122]
of Service
12 Destination Host Unreachable for Type of [RFC1122]
Service
13 Communication Administratively Prohibited [RFC1812]
14 Host Precedence Violation [RFC1812]
15 Precedence cutoff in effect [RFC1812]


As you can see the Fragmentation Needed but Do Not Fragment is one of those. So yes PMTUD will be impacted when you configure no unreachables.

Also since the Cisco/Unix traceroute is based on sending UDP packets and looking for the Port Unreachable message to indicate that the probe has reached the destination, then disabling unreachables will break the traceroute.

From a security standpoint when you harden a device you want to minimize the amount of information that the device provides about itself to others and disabling unreachables helps achieve this. But from the standpoint of things that help our network work better the unreachable is helpful.

So you have two different points of view and their position on unreachables. So which is more important hardening devices with reducing information that they provide or helping the network to run better?

hope this wil helps u

regards

karuppu

Thanx karuppu, its very good. keep it up.

Good Explanation

Reza Sharifi
Hall of Fame
Hall of Fame

davidhuynh5 wrote:

What is the purpose of this command?

What will happen if I disable it on an interface?

Thanks in advance.

David,

If the Cisco IOS software receives a nonbroadcast packet destined for itself that uses a protocol it does not recognize, it sends an ICMP unreachable message to the source.

Have a look at the command reference guide for more info:

http://www.cisco.com/en/US/docs/ios/ipapp/command/reference/iap_i2.html#wp1065520

HTH

Reza

What will happen if I disable it on an interface?

Probably nothing at all. Besides what's been said already, its a security measure meant to protect the router's control plane from a DoS attack.

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello David,

>> What will happen if I disable it on an interface?

A typical result of this is when you get * in a traceroute:

traceroute works like a radar using probe packets of increasing time to live TTL value, the router on the path (where the probe TTL becomes 0) has to send back an ICMP unreachable to the traceroute source IP address. The exit interface is chosen looking at the IP routing  table, the interface in the direction towards the traceroute source is used. If that interface has no ip unreachables the probes are discarded on that router silently and you see a * on device performing the traceroute.

As noted by other colleagues like Victor, disabling  ip unreachables is a security measure suggested in security best practices.

But as everything there is a price to pay for this.

Hope to help

Giuseppe

Keep in mind by disabling Type 4 (Fragment needed but DF bit set), Path MTUs will not work correctly, and if there is tunneled traffic, it could run into issues. Best practice according to Cisco documentation is to enable this so PMTUs work correctly. Second best is to adjust tcp mss on the interface which will intercept any TCP Syn packets and rewrite the MSS field.

Just something to think about.

Hi everybody,

I think the question has been perfectly answered already but I'd like to add some thoughts.

Like already stated, the "no ip unreachables" creates PMTU black holes. Within a network where all the router-interface's MTUs are not below the maximal local MTUs of the hosts (e.g. client-VLAN's SVIs), this should be no problem. Host won't send packets with sizes above their local MTU in the PMTUD process. Problems start when a router-interface has a lower MTU (e.g. because of tunnel-protocol overhead) because the "no ip unreachables" command makes no distincions on the code of the ICMP unreachable. Code 4 is mandatory for PMTUD. Windows OS have an option called "PMTU Black Hole Detection" which re-send the packets without the DF-bit set, but it's not enabled by default.

MSS Clamping (ip tcp adjust-mss) can help but it only affects TCP traffic; for ESP, for example, it doesn't work.

If you want to achieve protection against DoS attacks, Cisco routers rate-limit ICMP unreachables by default:

- 1 unreachable code 4 per 500 ms

- 1 unreachable for all the other codes per 500 ms

http://www.cisco.com/en/US/docs/ios-xml/ios/ipapp/command/iapi1.html#GUID-8369086B-6343-4BE3-8330-6754D14BCB5D

Of course you can change this values.

If you want to limit the information given by your devices, CoPP might be a more granular solution.

With extended ACL you can distinguish between wanted and unwanted ICMP messages, e.g.:

access-list 100 permit icmp any any packet-too-big

access-list 100 deny icmp any any net-unreachable

access-list 100 deny icmp any any port-unreachable

(...)

Best regards

Rolf

Umesh Shetty
Level 1
Level 1

Hi Friends,

 

I think the ICMP unreachables prevents a router from sending ICMP Type 3 reply messages for packets received on the interface where the "no ip unreachables" is configured.  I don't think it prevents the router interface being shown in traceroutes, because traceroute (either with cisco& unix using UDP or windows using icmp) uses TTL to identify the transit hosts. Each host in the path when it receives a packet and after decrementing the TTL by one the TTL becomes 0 it has to send back a ICMP Type 11 code 1 -- Time to Live exceeded in Transit. The "no ip unreachables" does not prevent type 11 replies being sent packets.

 

This could impact if the destination address in the trace is the router with  "no ip unreachables" configured on the ingress interface and you are tracing from a Cisco or Unix host. In this case the router needs to decapsulate the IP header ( because it has the destination address as one of its own interfaces). Check the UDP header and since th destination UDP port is a bogus one which the router isn't listening one it needs to reply with a Type 3 Code 3 -- Port Unreachable message and this time the  "no ip unreachables" comes into picture. 

So in a nutshell the "no ip unreachables" will not impact unless the router is the destination and the trace is being done from a Cisco or Unix or any other host using UDP for traceroute.

 

The "no ip unreachables" also helps you when you have an ACL configured on the interface with deny statements with log. The router needs to punt the packet to the CPU which must generate an icmp unreachable message for each dropped packet. In a situation where there are lots of denied packets it could keep the CPU busy in generating these packets. The "no ip unreachables" will silently drop the packets and not generate an unreachable back to the initiator

This is also a security feature, if an attacker is trying to break through he will never know there is a router in between that is dropping these packets because he never get the unreachable messages back.

 

 

Hope to Help

 

Regards

Umesh

 

  

 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco