ICMP Features
Learn more about how to configure Internet Control Message Protocol (ICMP) features.
Protocol Redirect Messages
ICMP redirect, also known as protocol redirect, is a mechanism used by switches and routers to convey routing information to hosts. Devices use protocol redirect messages to notify the hosts on the same data link of the best route available for a given destination. All EX series switches support sending protocol redirect messages for both IPv4 and IPv6 traffic.
Switches do not send protocol redirect messages if the data packet contains routing information.
Understanding Protocol Redirect Messages
Protocol redirect messages inform a host to update its routing information and to send packets on an alternate route. Suppose a host tries to send a data packet through a switch S1 and S1 sends the data packet to another switch, S2. Also, suppose that a direct path from the host to S2 is available (that is, the host and S2 are on the same Ethernet segment). S1 then sends a protocol redirect message to inform the host that the best route for the destination is the direct route to S2. The host should then send packets directly to S2 instead of sending them through S1. S2 still sends the original packet that it received from S1 to the intended destination.
Refer to RFC-1122 and RFC-4861 for more details on protocol redirecting.
Disable Protocol Redirect Messages
By default, devices send protocol redirect messages for both IPv4 and IPv6 traffic. For security reasons, you may want to disable the device from sending protocol redirect messages.
To disable protocol redirect messages for the entire device,
include the no-redirects or no-redirects-ipv6 statement
at the [edit system] hierarchy level.
For IPv4 traffic:
[edit system] user@host# set no-redirects
For IPv6 traffic:
[edit system] user@host# set no-redirects-ipv6
To re-enable the sending of redirect messages on
the device, delete the no-redirects statement (for IPv4
traffic) or the no-redirects-ipv6 statement (for IPv6 traffic)
from the configuration.
To disable protocol redirect messages on a per-interface basis,
include the no-redirects statement at the [edit interfaces interface-name unit logical-unit-number family family] hierarchy level.
For IPv4 traffic:
[edit interfaces interface-name unit logical-unit-number] user@host# set family inet no-redirects
For IPv6 traffic:
[edit interfaces interface-name unit logical-unit-number] user@host# set family inet6 no-redirects
Disable the Routing Engine Response to Multicast Ping Packets
By default, the Routing Engine responds to ICMP echo requests sent to multicast group addresses. By configuring the Routing Engine to ignore multicast ping packets, you can prevent unauthorized persons from discovering the list of provider edge (PE) devices in the network.
To disable the Routing Engine from responding to
these ICMP echo requests, include the no-multicast-echo statement at the [edit system] hierarchy level:
[edit system] no-multicast-echo;
Disable Reporting IP Address and Timestamps in Ping Responses
When you issue the ping command with
the record-route option, the Routing Engine displays the
path of the ICMP echo request packets and the timestamps in the ICMP
echo responses by default. By configuring the no-ping-record-route and no-ping-timestamp options, you can prevent unauthorized
persons from discovering information about the provider edge (PE)
device and its loopback address.
You can configure the Routing Engine to disable the setting
of the record-route option in the IP header of the ping
request packets. Disabling the record-route option prevents
the Routing Engine from recording and displaying the path of the ICMP
echo request packets in the response.
To configure the Routing Engine to disable the setting of the record route option, include the no-ping-record-route statement at the [edit system] hierarchy level:
[edit system] no-ping-record-route;
To disable the reporting of timestamps in the ICMP echo responses,
include the no-ping-time-stamp option at the [edit system] hierarchy level:
[edit system] no-ping-time-stamp;
Configure Junos OS to Ignore ICMP Source Quench Messages
By default, the device reacts to Internet Control
Message Protocol (ICMP) source quench messages. To ignore ICMP source
quench messages, include the no-source-quench statement
at the [edit system internet-options] hierarchy level:
[edit system internet-options] no-source-quench;
To stop ignoring ICMP source quench messages, use
the source-quench statement:
[edit system internet-options] source-quench;
Rate Limit ICMPv4 and ICMPv6 Traffic
To limit the rate at which ICMPv4 or ICMPv6 messages can be
generated by the Routing Engine and sent to the Routing Engine, include
the appropriate rate limiting statement at the [edit system internet-options] hierarchy level.
For IPv4:
[edit system internet-options] icmpv4-rate-limit bucket-size bucket-size packet-rate packet-rate
For IPv6:
[edit system internet-options] icmpv6-rate-limit bucket-size bucket-size packet-rate packet-rate
Rate Limit ICMPv4 and ICMPv6 Error Messages
By default, ICMP error messages for non-ttl-expired IPv4 and IPv6 packets are generated at the rate of 1 packet per second (pps). You can adjust this rate to a value that you decide provides sufficient information for your network without causing network congestion.
For ttl-expired IPv4 or IPv6 packets, the rate for ICMP error messages is not configurable. It is fixed at 500 pps.
- Why to Rate Limit ICMPv4 and ICMPv6 Error Messages
- How to Rate Limit ICMPv4 and ICMPv6 Error Messages
Why to Rate Limit ICMPv4 and ICMPv6 Error Messages
An example use case for adjusting the rate limit is a data center providing web services. Suppose this data center has many servers on the network that use jumbo frames with an MTU of 9100 bytes when they communicate to hosts over the Internet. These other hosts require an MTU of 1500 bytes. Unless maximum segment size (MSS) is enforced on both sides of the connection, a server might reply with a packet that is too large to be transmitted across the Internet without being fragmented when it reaches the edge router in the data center.
Because TCP/IP implementations often have Path MTU Discovery enabled by default with the dont-fragment bit set to 1, a transit device will drop a packet that is too big rather than fragmenting it. The device will return an ICMP error message indicating the destination was unreachable because the packet was too big. The message will also provide the MTU that is required where the error occurred. The sending host should adjust the sending MSS for that connection and resend the data in smaller packet sizes to avoid the fragmentation issue.
At high core interface speeds, the default rate limit of 1 pps for the error messages may not be enough to notify all the hosts when there are many hosts in the network that require this service. The consequence is that outbound packets are silently dropped. This action can trigger additional retransmissions or back-off behaviors, depending on the volume of requests that the data center edge router is handling on each core-facing interface.
In this situation, you can increase the rate limit to enable a higher volume of oversized packets to reach the sending hosts. (Adding more core-facing interfaces can also help resolve the problem.)
How to Rate Limit ICMPv4 and ICMPv6 Error Messages
Although you configure the rate limit at the [edit chassis] hierarchy level, it is not a chassis-wide limit. Instead, the rate
limit applies per interface family. This means, for example, that
multiple physical interfaces configured with family inet can simultaneously generate the ICMP error messages at the configured
rate.
This rate limit takes effect only for traffic that lasts 10 seconds or longer. The rate limit is not applied to traffic with a shorter duration, such as 5 seconds or 9 seconds.
To configure the rate limit for ICMPv4, use the
icmpstatement:[edit chassis] user@host# set icmp rate-limit rate-limit
Starting in Junos OS Release 19.1R1, the maximum rate increased from 50 pps to 1000 pps.
To configure the rate limit for ICMPv6, use the
icmp6statement:[edit chassis] user@host# set icmp6 rate-limit rate-limit
You must also consider that the rate limit value can interact
with your DDoS protection configuration. The default bandwidth value
for exceptioned packets that exceed the MTU is 250 pps. DDoS protection
flags a violation when the number of packets exceeds that value. If
you set the rate limit higher than the current mtu-exceeded bandwidth value, then you must configure the bandwidth value to
match the rate limit.
For example, suppose you set the ICMP rate limit to 300 pps:
user@host# set chassis icmp rate-limit 300
You must configure the DDoS protection mtu-exceeded bandwidth to match that value.
user@host# set system ddos-protection protocols exceptions mtu-exceeded bandwidth 300
ICMPv4 and ICMPv6 Extension Option for Selective Error Messages
An IP device uses the ICMP protocol to diagnose network communications problems, particularly to determine whether a datagram is arriving at its intended destination in a timely manner. If a datagram does not arrive at the intended destination, ICMP reports an appropriate error message to the origination IP device.
When network problems prevent IP packet delivery, network devices use ICMP to generate error messages to the source IP address.
- Why ICMPv4 or ICMPv6 extension required for Error Messages
- How to enable extension option for ICMPv4 or ICMPv6 Error Messages
Why ICMPv4 or ICMPv6 extension required for Error Messages
ICMP extension helps to identify the interface and other information as follows:
-
ICMPv4 and ICMPv6 messages couldn't identify the interface of a datagram that cannot be processed on an unnumbered interface.
-
ICMP messages are created by determining the source address of an incoming interface and sending packets to the origination device; however, the origin device has no way of knowing where the ICMP message originated.
Starting in Junos OS Release 21.4R1, the ICMP extension enables you to identify the network device responding to the ICMP message which includes the following information:
-
A datagram received through an IP interface.
-
A datagram arrived at the sub-IP component of an IP interface.
-
The IP interface in which the datagram would be forwarded.
-
Next-hop IP address to which it would have been forwarded.
We’ve implemented RFC5837 to enable us to append additional fields to select ICMP (IPv4 and IPv6) messages for both numbered and unnumbered aggregated Ethernet interfaces:
- ICMPv4 Time Exceeded
- ICMPv4 Destination Unreachable
- ICMPv6 Time Exceeded
- ICMPv6 Destination Unreachable
ICMPv6 extension for unnumbered interface is not supported.
How to enable extension option for ICMPv4 or ICMPv6 Error Messages
To enable ICMPv4 extension, use set system allow-icmp4-extension
statement:
[edit chassis] user@host# set system allow-icmp4-extension
To disable ICMPv4 extension, use delete system
allow-icmp4-extension statement:
[edit chassis] user@host# delete system allow-icmp4-extension
To enable ICMPv6 extension, use set system allow-icmp6-extension
statement:
[edit chassis] user@host# set system allow-icmp6-extension
To disable ICMPv6 extension, use delete system
allow-icmp6-extension statement:
[edit chassis] user@host# delete system allow-icmp6-extension