What are the different packet forwarding mechanisms

introduction

  

This document describes the packet redirection functionality provided by the Internet Control Message Protocol (ICMP). This document explains what typically indicates the presence of ICMP redirect messages on the network and how to minimize negative side effects related to network conditions that cause ICMP redirect messages to be generated.

requirements

conditions

Cisco recommends that you have knowledge of the following areas:

  • Nexus 7000 platform architecture
  • NX-OS software configuration
  • Internet Control Message Protocol, as documented in Request for Comments (RFC) 792

Components used

The information in this document was produced by the devices in a specific laboratory environment. All devices used in this document started with an empty (standard) configuration. With your network up and running, make sure you understand the potential implications of a command.

ICMP forwarding messages

The ICMP redirection functionality is explained in RFC 792 "Internet Control Message Protocol" with the following example.

The gateway sends a redirect message to a host in the followingSituation.

A gateway, G1, receives an internet datagram from oneHost in a network to which the gateway is connected. The gateway,G1 checks its routing table and gets the address of the next oneGateway G2 on the route to the internet destination of the datagramNetwork, X.

When G2 and the host are identified by the internet sourceThe address of the datagram is on the same network, a redirectis sent to the host. The diversion report recommends theHost sends its traffic for network X directly to gateway G2 asThis is a shorter path to the goal.

The gateway directsthe data of the original datagram to its Internet destination.

This scenario is in illustration 1 shown. The host and two routers, G1 and G2, are connected to a common Ethernet segment and have IP addresses in the same network 10.0.0.0/24

The host has the IP address 10.0.0.100. The host's routing table has a standard routing entry pointing to the router's IP address 10.0.0.1 as the default gateway. Router G1 uses the IP address 10.0.0.2 of router G2 as the next hop for forwarding the data traffic to the destination network X.

When the host sends a packet to the destination network X, the following happens

1. Gateway G1 with the IP address 10.0.0.1 receives data packets from the host 10.0.0.100 in a network to which it is connected.

2. The gateway G1 checks its routing table and retrieves the IP address 10.0.0.2 of the next gateway, G2, on the route to the destination network of the data packet, X.

3. If G2 and the host identified by the source address of the IP packet are on the same network, the ICMP redirect message is sent to the host. The ICMP redirect message recommends the host to send its traffic for network X directly to gateway G2 as this is a shorter path to the destination.

4. The gateway G1 forwards the original data packet to its destination.


Depending on the host configuration, you can choose to ignore ICMP redirect messages that G1 sends to them. However, if the host uses ICMP redirect messages to adjust its routing cache and then sends data packets directly to G2, the following benefits are achieved in this scenario:

  • Optimization of the data forwarding path in the network; Traffic reaches its destination faster
  • Reduction of the utilization of network resources, e.g. B. bandwidth and CPU usage of the router

As in Figure 2 shown, after creating the route cache entry for network X with G2 as the next hop, the host achieved the following advantages on the network:

  • Bandwidth usage at the connection between switch and router G1 decreases in both directions
  • The CPU utilization on router G1 is reduced because the data traffic flow from the host to network X no longer passes through this node.
  • End-to-end network delay between host and network X improves.

To understand the importance of the ICMP redirection mechanism, keep in mind that early stage Internet router implementations relied primarily on CPU resources to handle traffic. Therefore, it was very desirable to reduce the volume of traffic that a single router had to handle and to minimize the number of router hops a given traffic flow had to traverse on its way to its destination. At the same time, Layer 2 forwarding (also Switching mainly implemented in custom application-specific integrated circuits (ASICs), and from a forwarding performance perspective, it was compared to Layer 3 forwarding (also Routing called) relatively "cheap", which in turn was done in general purpose processors.

Newer ASIC generations can carry out packet forwarding on Layer 2 and Layer 3. Performing Layer 3 table searches in the hardware helps reduce the performance costs associated with packet processing by the routers. By integrating Layer 3 forwarding functionality into Layer 2 switches (now known as Layer 3 switches packet forwarding becomes more efficient, eliminating the need for a "one-arm router" (also known as a "router on a stick") and avoiding restrictions associated with such network configurations.

picture 3 builds on the scenario in Picture 1 on. Now the layer 2 and layer 3 functions, which were originally provided by two separate nodes, the switch and router G1, are consolidated into a single layer 3 switch, e.g. B. in the platform of the Nexus 7000 series.

When the host sends the packet to destination network X, the following happens on the network

1. Gateway L3 switch with IP address 10.0.0.1 receives data packet from host 10.0.0.100 in a network to which it is connected.

2. The gateway L3 switch checks its routing table and retrieves the address 10.0.0.2 of the next gateway, G2, on the route to the destination network of the data packet, X.

3. If G2 and the host identified by the source address of the IP packet are on the same network, the ICMP redirect message is sent to the host. The ICMP redirect message recommends that the host send its traffic for network X directly to gateway G2 as this is a shorter path to the destination.

4. The gateway forwards the original data packet to its destination.

Since Layer 3 switches can now perform both Layer 2 and Layer 3 packet forwarding at the ASIC level, it can be concluded that both advantages of the ICMP redirection function, (a) the improvement in delay by the network and (b) the reduction of network resources can be achieved, and the techniques for path optimization in multi-point Ethernet segments no longer need much attention.

However, because the ICMP redirection function is enabled on Layer 3 interfaces, suboptimal routing over multi-point Ethernet segments still represents potential performance bottlenecks, even if it happens for another reason, as in the section Nexus Platform Considerations explained later in this document.

Note: ICMP redirects are enabled by default on Layer 3 interfaces in IOS and NX-OS software.

Note: Summary of the conditions under which ICMP redirection messages are generated: The layer 3 switch generates the ICMP redirection message back to the source of the data packet if the data packet is to be forwarded via the layer 3 interface via which this packet is received becomes.

Sub-optimal paths through Ethernet networks

Interior Gateway Protocols (IGP), such as Open Shortest Path First (OSFP) and Cisco Enhanced Interior Gateway Routing Protocol (EIGRP), are designed to synchronize routing information between routers and provide consistent and predictable packet forwarding behavior on all network nodes that use them Comply with information. For example, if all Layer 3 nodes in a segment use the same routing information and agree on the same point of departure to the destination, suboptimal routing over these networks is rarely the case.

To understand what causes sub-optimal forwarding paths, keep in mind that Layer 3 nodes make decisions about packet forwarding independently of one another. The decision made by router B to forward packets does not depend on the decision made by router A to forward packets. This is one of the main principles to keep in mind when troubleshooting packet forwarding over IP networks. It is important to consider when investigating the sub-optimal forwarding path in multi-point Ethernet networks.


As already mentioned, in networks in which all routers rely on a single dynamic routing protocol for the transmission of data traffic between endpoints, suboptimal routing over multipoint Ethernet segments should not be used. In practice-oriented networks, however, it is very common to find a combination of different mechanisms for packet forwarding and forwarding. Examples of such mechanisms are various IGPs, static routing, and policy-based routing. These functions are typically used together to achieve the desired routing of traffic through the network.

While the combined use of these mechanisms can help optimize traffic flow and meet the needs of a particular network design, overlooking the side effects that these tools together can cause on multi-point Ethernet networks can result in poor overall network performance .

Static routing

To illustrate this, consider the scenario in Picture 4. Router A has a static route to network X, with router B acting as the next hop. At the same time, router B uses router C as the next hop in the static route to network X.

  

While the data traffic enters this network at router A, traverses it via router C and is finally delivered to the destination network X, packets have to traverse this IP network twice. This is not an efficient use of network resources. Instead, sending packets directly from Router A to Router C would achieve the same results and use less network resources.

Note: Although router A and router C are used as input and output Layer 3 nodes for this IP network segment in this scenario, both nodes can be replaced by network units (e.g. load balancers or firewalls) if the latter has have a routing configuration that causes the same packet forwarding behavior.

Policy-based routing

Policy Based Routing (PBR) is another mechanism that can cause a sub-optimal path through Ethernet networks. Unlike static or dynamic routing, however, PBR does not work at the routing table level. Instead, it programs the redirection of the access control list (ACL) directly into the switch hardware. In the case of selected data traffic flows, the packet forwarding search on the incoming line card therefore bypasses routing information that is recorded via static or dynamic routing.

In Figure 5 Routers A and B exchange routing information via destination network X using one of the dynamic routing protocols. Both agree that Router B is the best next-hop router for this network.

In the case of a PBR configuration on router B that overwrites the routing information received from the routing protocol and specifies router C as the next-hop-to-network X, the condition that the ICMP forwarding function is activated is met and the packet is sent to the CPU of router B for further processing.

ICMP redirects point-to-point links

So far this document has referred to Ethernet networks that have three (or more) Layer 3 nodes connected, hence the name Multi-pointEthernet networks. Note, however, that ICMP redirect messages can also be generated on point-to-point Ethernet links.

Look at the scenario Pic 6. Router A uses a default static route to send traffic to Router B, while Router B has a static route to Network X that points to Router A.

This design option, also known as a single-homed connection, is popular when connecting small customer environments to service provider networks. Here router B is a provider edge (PE) device and router A is a customer edge (CE) device.

Note that the typical CE configuration includes aggregated static route (s) to customer IP address blocks that point to a Null0 interface. This configuration is a recommended best practice for a single homed CE-PE link option with static routing. However, this example assumes that there is no such configuration.

Suppose router A loses connection to network X as shown in the picture. When packets from customer network Y or remote network Z try to reach network X, routers A and B block data traffic between themselves and thus reduce the IP time-to-live field in each packet until the value reaches 1. At this point, further routing of the packet is not possible.

While traffic to Network X floats back and forth between PE and CE routers, dramatically (and unnecessarily) increasing bandwidth usage on CE-PE links, the problem is exacerbated when ICMP redirects on one or both sides of the point- to point PE-CE connection to be activated. In this case, each packet in the flow destined for network X is processed multiple times in the CPUs of the respective routers to support the creation of ICMP redirect messages.

Nexus Platform Considerations

If ICMP redirects are activated on the layer 3 interface and incoming data packets use this interface for both the input and output layer 3 switch, the ICMP redirection message is generated. While Layer 3 packet forwarding occurs in the hardware on the Cisco Nexus 7000 platform, it is still the task of the switch CPU to generate ICMP forwarding messages. To do this, the CPU on the Nexus 7000 supervisor module must call up IP address information of the data flow, the path of which can be optimized through the network segment. This is the reason that data packets are sent from the input line card to the supervisor module.

If the recipient of the ICMP redirection message ignores this and forwards the data traffic on to the layer 3 interface of the Nexus switch on which ICMP redirects are activated, the ICMP redirection process is triggered for each data packet.

At the line card level, the process begins as a hardware forwarding exception. Exceptions are thrown for ASICs if packet forwarding by the line card module cannot be completed successfully. In this case, the data packet must be sent to the supervisor module to ensure correct packet processing.

Note: Unlike when creating ICMP redirect messages, the CPU on the supervisor module handles many other exceptions for packet forwarding, e.g. For example, processing IP packets with a TTL value set to 1, or IP packets that must be fragmented before being sent to the next hop.

After the CPU on the supervisor module sends the ICMP redirect message to the source, it completes the exception handling by forwarding the data packet to the next hop via the output line card module.

While Nexus 7000 supervisor modules use powerful CPU processors that can handle large amounts of traffic, the platform has been designed so that most of the traffic can be handled at the line card level without the supervisor's CPU processor being involved in the packet forwarding process . This allows the CPU to concentrate on its core tasks and packet forwarding is left to dedicated hardware engines on line cards.

In stable networks, exceptions to packet forwarding should be expected when they occur that are relatively low. Under this assumption, they can be processed by the supervisor CPU without any significant impairment of their performance. On the other hand, CPU processing with packet forwarding exceptions occurring at very high speeds can have a negative impact on the stability and responsiveness of the overall system.

The design of the Nexus 7000 platform offers a number of mechanisms to protect the switch CPU from being overloaded by significant traffic. These mechanisms are implemented at various points in the system. At the line card level there are hardware rate limits and CoPP (Control Plane Policing) functions.In both cases, traffic rate thresholds have been set that effectively control the traffic that is forwarded from each line card module to the supervisor.

  

These protection mechanisms prefer the data traffic of different control protocols, which are crucial for network stability and switch manageability (e.g. OSPF, BGP or SSH). At the same time, traffic types that are not important to the functionality of the switch's control plane are aggressively filtered. Most of the data traffic that is forwarded to the CPU due to exceptions in packet forwarding is heavily regulated by such mechanisms.

  

Hardware rate limits and CoPP policy mechanisms ensure the stability of the switch's control plane and are strongly recommended to always be enabled. However, they can be a major cause of packet loss, transmission delay, and overall poor application performance on the network. For this reason, it is important to understand the paths that traffic flows through the network and have tools to monitor network devices that can and / or should use the ICMP redirection feature.

Monitoring and diagnostic tools

  

show ip traffic

Both Cisco IOS and NX-OS software provide a way to review statistics about the traffic being processed by the CPU. This is done with the command show ip traffic. This command can be used to verify receipt and / or generation of ICMP redirect messages by a Layer 3 switch or router.

Nexus7000 # show ip traffic | begin ICMP

ICMP Software Processed Traffic Statistics
------------------------------------------
Transmission:
Redirect: 1000, unreachable: 0, echo request: 0, echo reply: 0,



ICMP originate Req: 0, Redirects Originate Req: 1000
Originate deny - Resource fail: 0, short ip: 0, icmp: 0, others: 0
Reception:
Redirect: 0, unreachable: 0, echo request: 0, echo reply: 0,

Nexus7000 #

Run the command several times show ip traffic and see if the number of ICMP redirect counters increases.

Ethanalyzer


Cisco NX-OS software has a built-in tool to capture the traffic flowing to and from the switch CPU. This is known as the "Ethanalyzer".

Note: For more information on Ethanalyzer, see the Ethanalyzer Troubleshooting Guide for the Nexus 7000.

Fig 7 shows a scenario similar to that in picture 3 resembles. Here network X is replaced by network 192.168.0.0/24.

Host 10.0.0.100 sends a continuous stream of ICMP echo requests to the destination IP address 192.168.0.1. Host uses Switch Virtual Interface (SVI) 10 of the Nexus 7000 switch as the next hop on the remote network 192.168.0.0/24. For demonstration purposes, the host is configured to ignore ICMP redirect messages.

Use the following command to capture the ICMP traffic received and sent by the Nexus 7000 CPU.

Nexus7000 # ethanalyzer local interface inband capture-filter icmp limit-captured-frames 1000 Capturing on inband 2018-09-15 23: 45: 40.124077 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request 2018-09-15 23: 45: 40.124477 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host) 2018-09-15 23: 45: 40.124533 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request 2018-09-15 23: 45: 40.126344 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request 2018-09-15 23: 45: 40.126607 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host) 2018-09-15 23: 45: 40.126655 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request 2018-09-15 23: 45: 40.128348 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request 2018-09-15 23: 45: 40.128611 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host) 2018 -09-15 23: 45: 40.128659 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request 2018-09-15 23: 45: 40.130362 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request 2018-09-15 23: 45: 40.130621 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host) 2018 -09-15 23: 45: 40.130669 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request 2018-09-15 23: 45: 40.132392 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request 2018-09 -15 23: 45: 40.132652 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host) 2018-09-15 23: 45: 40.132700 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request 2018-09- 15 23: 45: 40.134347 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request 2018-09-15 23: 45: 40.134612 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host) 2018-09-15 23: 45: 40.134660 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request 2018-09-15 23: 45: 40.136347 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request 2018-09-15 23: 45: 40.136598 10.0.0.1 -> 10.0.0.100 ICMP Redirect (Redirect for host) 2018-09-15 23: 45: 40.136645 10.0.0.100 -> 19 2.168.0.1 ICMP Echo (ping) request 2018-09-15 23: 45: 40.138351 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request 2018-09-15 23: 45: 40.138607 10.0.0.1 -> 10.0. 0.100 ICMP Redirect (Redirect for host) 2018-09-15 23: 45: 40.138656 10.0.0.100 -> 192.168.0.1 ICMP Echo (ping) request

...

Timestamps in the above output suggest that three packets highlighted in this example were captured at the same time (2018-09-15 23: 45: 40.128). A package breakdown of this package group is shown below.

  • The first packet is the input data packet, which in this example is an ICMP echo request.

2018-09-15 23: 45: 40.128348 10.0.0.100 -> 192.168.0.1 ICMP echo (ping) request

  • The second packet is an ICMP redirect packet generated by the gateway. This packet is sent back to the host.

2018-09-15 23: 45: 40.128611 10.0.0.1 -> 10.0.0.100 ICMP redirection (redirection for host)

  • The third packet is the data packet that is captured in the outbound direction after it has been routed by the CPU. Although not shown above, the IP-TTL for this packet is degraded and the checksum is recalculated.

2018-09-15 23: 45: 40.128659 10.0.0.100 -> 192.168.0.1 ICMP echo (ping) request

When navigating through large Ethanalyzer surveys that contain many packets of different types and flows, it may not be easy to correlate ICMP redirect messages with the corresponding traffic.

In these situations, focus on ICMP redirect messages to get information about traffic flows that are not being routed optimally. ICMP redirect messages contain the Internet header and the first 64 bits of the data from the original datagram. This data is used by the source of the datagram to match the message with the appropriate process.

Use the Ethanalyzer packet capture tool with detailed Keywords to view the contents of ICMP redirect messages and to find IP address information of the flow that is being forwarded sub-optimally.

Nexus7000 # ethanalyzer local interface inband capture-filter icmp limit-captured-frames 1000 detail
...
Frame 2 (70 bytes on wire, 70 bytes captured)
Arrival Time: Sep 15, 2018 23:54: 04.388577000
[Time delta from previous captured frame: 0.000426000 seconds]
[Time delta from previous displayed frame: 0.000426000 seconds]
[Time since reference or first frame: 0.000426000 seconds]
Frame Number: 2
Frame Length: 70 bytes
Capture Length: 70 bytes
[Frame is marked: False]
[Protocols in frame: eth: ip: icmp: ip: icmp: data]
Ethernet II, Src: 00: be: 75: f2: 9e: bf (00: be: 75: f2: 9e: bf), Dst: 00: 0a: 00: 0a: 00: 0a (00: 0a: 00: 0a: 00: 0a)
Destination: 00: 0a: 00: 0a: 00: 0a (00: 0a: 00: 0a: 00: 0a)
Address: 00: 0a: 00: 0a: 00: 0a (00: 0a: 00: 0a: 00: 0a)
.... ... 0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Source: 00: be: 75: f2: 9e: bf (00: be: 75: f2: 9e: bf)
Address: 00: be: 75: f2: 9e: bf (00: be: 75: f2: 9e: bf)
.... ... 0 .... .... .... .... = IG bit: Individual address (unicast)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
Type: IP (0x0800)
Internet Protocol, Src: 10.0.0.1 (10.0.0.1), Dst: 10.0.0.100 (10.0.0.100)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00 .. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ... 0 = ECN-CE: 0
Total Length: 56
Identification: 0xf986 (63878)
Flags: 0x00
0 .. = Reserved bit: Not Set
.0. = Don't fragment: Not Set
..0 = More fragments: Not Set
Fragment offset: 0
Time to live: 255
Protocol: ICMP (0x01)
Header checksum: 0xadd9 [correct]
[Good: True]
[Bad: False]
Source: 10.0.0.1 (10.0.0.1)
Destination: 10.0.0.100 (10.0.0.100)
Internet Control Message Protocol
Type: 5 (Redirect)
Code: 1 (Redirect for host)
Checksum: 0xb8e5 [correct]
Gateway address: 10.0.0.2 (10.0.0.2)
Internet Protocol, Src: 10.0.0.100 (10.0.0.100), Dst: 192.168.0.1 (192.168.0.1)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00 .. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ... 0 = ECN-CE: 0
Total Length: 84
Identification: 0xf986 (63878)
Flags: 0x00
0 .. = Reserved bit: Not Set
.0. = Don't fragment: Not Set
..0 = More fragments: Not Set
Fragment offset: 0
Time to live: 254
Protocol: ICMP (0x01)
Header checksum: 0xa8ae [correct]
[Good: True]
[Bad: False]
Source: 10.0.0.100 (10.0.0.100)
Destination: 192.168.0.1 (192.168.0.1)
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Code: 0 ()
Checksum: 0x02f9 [incorrect, should be 0xcae1]
Identifier: 0xa01d
Sequence number: 36096 (0x8d00)

...


Disable ICMP redirects

If the network design requires that the traffic flow be routed through the same Layer 3 interface that it reached the switch or router through, the flow of traffic can be prevented from being routed through the CPU by using the ICMP redirection function in the corresponding Layer 3 interface is explicitly deactivated.

In most networks, it is advisable to proactively disable ICMP redirects on all Layer 3 interfaces, both physical and virtual, such as B. Port Channel and SVI Interfaces. Use the NX-OS command at the interface level no ip redirectsto disable ICMP redirects on a Layer 3 interface. Follow these steps to verify that the ICMP redirection feature is disabled.

  • Make sure the interface configuration no command ip redirects will be added.
Nexus7000 # show run interface vlan 10 interface Vlan10
no shutdown no ip redirects ip address 10.0.0.1/24
Nexus7000 #
  • Make sure that the status of ICMP redirects on the interface as "deactivated " is shown.
Nexus7000 # show ip interface vlan 10 | include redirectsIP icmp redirects: disabled Nexus7000 #
  • Make sure that the ICMP Redirect enable / disable flag from the NX-OS software component is set to "0" which transfers the interface configuration from the supervisor of the switch to one of several line cards.
Nexus7000 # show system internal eltm info interface vlan 10 | i icmp_redirect per_pkt_ls_en = 0, icmp_redirect = 0, v4_same_if_check = 0 Nexus7000 #
  • Make sure that the flag for activating / deactivating ICMP redirection for a specific Layer 3 interface on one or more line cards is set to "0" is fixed.
Nexus7000 # attach module 7
Attaching to module 7 ...
To exit type 'exit', to abort type '$.'
Last login: Wed Sep 15 23:56:25 UTC 2018 from 127.1.1.1 on pts / 0
module-7 #


module-7 # vdc 6

module-7 # show system internal iftmc info interface vlan 10 | include icmp_redirect
icmp_redirect: 0x0 ipv6_redirect: 0x1
module-7 #


Summary

The ICMP redirection mechanism, as described in RFC 792, was developed to optimize the forwarding path through multi-point network segments. In the early days of the Internet, this optimization helped save costly network resources such as connection bandwidth and router CPU cycles.

As network bandwidth became more affordable and CPU-based packet forwarding in dedicated hardware ASICs led to faster Layer 3 packet forwarding, the importance of optimal data transmission through multi-point network segments decreased and is no longer receiving as much attention from network designers today like before.

By default, the ICMP redirection function is enabled on every Layer 3 interface. Attempts to inform network nodes in Ethernet segments with several points about optimal forwarding paths are not always understood and implemented by network employees.

In networks that combine various forwarding mechanisms such as static routing, dynamic routing, and policy-based routing, enabling the ICMP forwarding function without proper monitoring can result in undesired use of transit node CPUs for production traffic. This, in turn, can have a significant impact on both production traffic and the stability of the network infrastructure at the control plane.

For most networks, it is important to proactively deactivate the ICMP redirection function on all layer 3 interfaces in the network infrastructure. This prevents production traffic scenarios in the CPU from being handled by Layer 3 switches and routers when there is a better route through multipoint network segments.