Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

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

Note:

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:

  • For IPv6 traffic:

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:

  • For IPv6 traffic:

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:

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:

To disable the reporting of timestamps in the ICMP echo responses, include the no-ping-time-stamp option at the [edit system] hierarchy level:

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:

To stop ignoring ICMP source quench messages, use the source-quench statement:

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:

  • For IPv6:

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.

Note:

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

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.

Note:

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 icmp statement:

    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 icmp6 statement:

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:

You must configure the DDoS protection mtu-exceeded bandwidth to match that value.

Related Documentation