Dell Force10 S2410-01-10GE-24P SFTOS Configuration Guide - Page 282

www.dell.com | support.dell.com The routing software first looks for the destination MAC address in the ARP table, which it maintains. If it finds the address in the ARP table, it sends the packet to the Layer 2 application, which resolves it and finds the egress port from which to send it. If the software cannot find the destination in the ARP table, it sends an ARP request. After receiving the ARP reply, the Layer 2 tables can be updated, and subsequent packets can be routed by the hardware. In normal situations, the ARP request requires a small CPU hit, and CPU utilization drops once the destination is resolved. Possible situations that require software forwarding for an extended period of time include: • The system receives a lot of traffic with unresolvable destinations. The software constantly sends ARP requests for these packets, but no replies are received. • The system receives packets with destination MAC addresses that cannot be resolved in the MAC Address table, but the destination IP address can be resolved in the ARP table. In this case, the hardware keeps sending the packets up to the CPU to retrieve ARP table entries to return to the Layer 2 application, but the Layer 2 application cannot find an associated egress interface from the MAC Address table. The root cause, in most of these cases, is that the MAC Address table entry (Layer 2) times out earlier than the ARP Table entries (Layer 3). Make sure that the Layer 2 timeout period is longer than the Layer 3, and make sure that the ARP is configured to be a dynamic renew (the default). In most network topologies, traffic flows are bidirectional. Therefore the Layer 2 table entries are constantly relearned/refreshed. However, in some cases, where the traffic flows are uni-directional, the Layer 2 entries time out before the Layer 3 entries, so the packets go to the CPU until the Layer 3 entries are timed out and new ARP requests are sent. Configuring default/static routes does not help. Default routes create a static Layer 3 entry, but Layer 2 entries are still subject to timeouts in SFTOS. Troubleshooting No Output on the Console Your console might experience a temporary or seemingly permanent inability to display output. This symptom may be caused by one of the following transitory conditions: • The switch is experiencing very high CPU utilization - a large number of frames for which there is no hardware forwarding entry or a large number of protocol packets being forwarded to the CPU for processing. • Data is being transferred to or from the switch via TFTP, or the running configuration is being written to non-volatile memory. During these operations, all management access to the switch is blocked. • The management unit in a stack is propagating the configuration to the member switches. • A remote connection to the switch console via a communication server has been lost. To determine whether this symptom is occurring, ping the communications server. If the pings succeed, attempt to log into the server and kill the session connecting to your switch. Then re-connect. • A topology loop is occurring in the network and flooding a large number of broadcasts or unknown unicast frames to all working interfaces in the same VLAN. Such excessive frame flooding can lead to high CPU utilization as the switch becomes overwhelmed with processing the unwanted frames. To prevent unwanted flooding, try the following: 282 | Troubleshooting