Troubleshooting No Output On The Console - Dell Force10 S2410-01-10GE-24P Configuration Manual

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