Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

ICMP Features

Use Internet Control Message Protocol (ICMP) features to diagnose network issues and check device reachability.

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.

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.

Note:

  • Switches do not send protocol redirect messages if the data packet contains routing information.

  • All EX series switches support sending protocol redirect messages for both IPv4 and IPv6 traffic.

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:

Pings

Pings use ICMP. A successful ping is when a device sends an ICMP echo request to a target and the target responds with an ICMP echo reply. However, there might be situations where you do not want your device to respond to ping requests.

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:

Source Quench Messages

When a device is receiving too many or undesired datagrams, it can send a source quench message to the originating device. The source quench message signals the originating device to reduce the amount of traffic it is sending.

By default, the device reacts to 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:

Time-to-Live (TTL) Expiration

The time-to-live (TTL) value in a packet header determines how long the packet remains traveling through the network. The TTL value decrements with each device (or hop) the packet travels through. When a device receives a packet with a TTL value of 0, it discards the packet. The TTL expiry message is sent using ICMP.

You can configure your device to use an IPv4 address as the source address for ICMP time-to-live (TTL) expiry error messages. This means you can configure the loopback address as the source address in response to ICMP error packets. Doing this is useful when you cannot use the device address for traceroute purposes because you have duplicate IPv4 addresses in your network.

The source address must be an IPv4 address. To specify the source address, use the ttl-expired-source-address source-address option at the [edit system icmp (System)] hierarchy level:

This configuration only applies to ICMP TTL expiry messages. Other ICMP error reply messages continue to use the address of the ingress interface as the source address.

Rate Limit ICMP 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 ICMP 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.

ICMP 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 originating IP device.

When network problems prevent IP packet delivery, network devices use ICMP to generate error messages to the source IP address. ICMPv4 and ICMPv6 provide an extension option for selective error messages.

Benefits of ICMP Extension

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.

The ICMP extension enables you to identify the network device responding to the ICMP message that 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
Note:

The ICMPv6 extension is only supported for numbered interfaces.

How to Enable ICMP Extension

To enable the ICMPv4 extension:

To disable the ICMPv4 extension, delete the configuration:

To enable the ICMPv6 extension:

To disable the ICMPv6 extension, delete the configuration:

Related Documentation