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]
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]
11 Destination Network Unreachable for Type [RFC1122]
12 Destination Host Unreachable for Type of [RFC1122]
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
What is the purpose of this command?
What will happen if I disable it on an interface?
Thanks in advance.
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:
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.
>> 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
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.
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
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
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