Troubleshooting Unicast Flooding Due to Topology
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Troubleshooting Unicast Flooding Due to Topology Changes
Unicast flooding occurs for many reasons in a switched network. The following article addresses how to detect and troubleshoot unicast flooding issues due to spanning tree topology changes. Having the ability to identify and successfully troubleshoot these situations can significantly improve network performance.
Catalyst® Switches, at Layer 2, forward or switch frames based on the destination MAC addresses of the frames received. In addition, Catalyst switches build MAC address tables used to forward frames at Layer 2 based on the unicast source MAC of incoming frames.
Maximum performance and efficiency is achieved if the switch already knows the egress interface for ingress frames. For example, in Figure 1, the switch knows on which ports the PCs are located and, hence, is able to switch out frames using the MAC address table without flooding the frame on all ports.
)
Figure
1 Switch Forwards Traffic Sourced from PC-A to PC-D Efficiently
Use the following command on Cisco IOS-based Catalyst switches to display the dynamically learned MAC addresses for a specific VLAN:
show mac-address-table dynamic vlan vlan-id
For CatOS-based Catalyst switches, use the following command to display the dynamically learned MAC addresses for a specific VLAN:
show cam dyanamic vlan-id
However, if the frame destination of the MAC address is not yet learned by the switch (that is, it is an unknown unicast), the switch floods the frame to all the interfaces in the VLAN. In Figure 2, the switch has not learned the PC-D MAC address; hence, traffic from PC-A to PC-D is flooded to all interfaces in the same VLAN. Flooding to all ports in a VLAN always occurs for broadcast frames. If this flooding is happening for unicast frames, network performance might be affected. This issue is known as unicast flooding.
)
Figure
2 Switch Floods Traffic Sourced from PC-A to PC-D to All Interfaces
Unicast flooding is a normal and expected behavior of Ethernet LAN networks. Nevertheless, there are configuration and spanning-tree events that might increase the number of frames flooding in a VLAN.
Also, because the dynamically learned MAC addresses need to stay current, Catalyst switches have a mechanism to age out the MAC address table entries after a certain idle period. When the switch receives a frame destined to the device after the idle period, the switch has to flood the packet again as though the switch never learned that MAC address. The learning process starts again, and, ultimately, the switch stops flooding the packet.
The preceding scenario is normal and common in most networks and is not a cause for concern. However, other events in the network might cause the switch MAC address table to be flushed more frequently than the configured aging time. One such event is due to spanning-tree topology changes in the network.
Topology changes reduce the MAC address table aging time from the default time of 300 seconds to 15 seconds in the case of 802.1D Spanning Tree Protocol (STP) to freshen stale MAC address table entries. This reduction of aging time is discussed in detail in Chapter 5, "Understanding and Configuring the 802.1D, 802.1s, and 802.1w Spanning-Tree Protocols," of CCNP Self-Study: Building Cisco Multilayer Switched Networks (BCMSN), Second Edition, published by Cisco Press (ISBN: 1-58705-150-8).
In the case of Rapid Spanning Tree Protocol (RSTP), the MAC address is immediately flushed and the scenario is even more severe. In a steady-state Catalyst switch-based network, topology changes should be few and far between. Some of the legitimate reasons for topology changes include the following:
Addition of a new switch to the network
Removal of an old switch
A configuration change or hardware replacement by an administrator
A topology change due to these reasons is typically not avoidable as the topology probably does significantly change, and it becomes essential that the switch flush the MAC address table to minimize misdirected packet loss due to a stale MAC address table.
The most common reason for excessive unicast flooding in steady-state Catalyst switch networks is the lack of proper host port configuration. Hosts, servers, and any other end-devices do not need to participate in the STP process; therefore, the link up and down states on the respective NIC interfaces should not be considered an STP topology change. Logically, host ports are not involved in the STP topology or in forwarding STP BPDUs. To suppress the STP topology for a port, use the STP PortFast feature, but even with the best of the intents, it is possible that the PortFast feature is not configured properly on specific host ports.
The following steps illustrate how to properly identify which ports on a switch are causing STP topology changes on Cisco IOS switches:
Step 1 Identify the unicast flooding condition due to a STP topology change that might have occurred previously.
Use the following command to display the current MAC address table aging time:
show mac-address table aging vlan vlan-id
Example 1 shows a sample output when the topology change has set the MAC address table aging to 15 seconds on Cisco IOS-based Catalyst switches.
Example 1 Displaying MAC Address Table Aging on Cisco IOS-Based Switches
4507R#show mac-address-table aging-time vlan 1 Vlan Aging Time Configured Aging Time ---- ---------- --------------------- Global Vlan Admin Age: 300 1 15 300
Use the following command to display the current MAC address table aging time on CatOS-based Catalyst switches.
show cam agingtime vlan-id
Example 2 shows a sample output where the topology change has set the MAC address table aging to 15 seconds on CatOS-based Catalyst switches.
Example 2 Display MAC Address Table Aging on CatOS-Based Switches
4006-1 (enable) show cam agingtime 1 VLAN 1 aging time = 15 sec
Step 2 Identify the interface that is receiving the topology change or initiating the topology change.
To identify the device causing the topology change, issue the following command on the root switch for that VLAN on a Cisco IOS-based Catalyst switch:
show spantree-tree vlan vlan-id detail
Example 3 shows output from the root switch where the last topology was detected due to a device on Fast Ethernet interface 7/2 or received a topology change notification (TCN) on Fast Ethernet interface 7/2 that could have been generated by the switch connected on that interface or other switches connected to that neighbor switch on that interface.
Example 3 Identify the Topology Change Initiator on Cisco IOS-Based Catalyst Switches
4507R#show spanning-tree vlan 1 detail
VLAN0001 is executing the ieee compatible Spanning Tree protocol
Bridge Identifier has priority 0, sysid 1, address 000a.4173.f540
Configured hello time 2, max age 20, forward delay 15
We are the root of the spanning tree
Topology change flag set, detected flag set
Number of topology changes 232 last change occurred 00:00:08 ago
from FastEthernet7/2
Times: hold 1, topology change 35, notification 2
hello 2, max age 20, forward delay 15
Timers: hello 1, topology change 34, notification 0, aging 15
<output skipped>
On CatOS-based Catalyst switches, issue the following command to identify the port receiving or generating topology change:
show spantree statistics mod/port vlan-id
Example 4 shows a sample output from a CatOS-based switch that received a topology change on Port 3/13.
Example 4 Identify the Topology Change Initiator on CatOS-Based Catalyst Switches
4006-1 (enable) show spantree statistics 3/13 1
Port 3/13 VLAN 1
SpanningTree enabled for vlan = 1
BPDU-related parameters
port spanning tree enabled
state forwarding
port_id 0x208d
port number 0x8d
path cost 19
message age (port/VLAN) 0(20)
designated_root 00-04-9a-80-a4-00
designated_cost 0
designated_bridge 00-04-9a-80-a4-00
designated_port 0x208d
top_change_ack FALSE
config_pending FALSE
port_inconsistency none
PORT based information & statistics
config bpdu's xmitted (port/VLAN) 697(151817)
config bpdu's received (port/VLAN) 2(5)
tcn bpdu's xmitted (port/VLAN) 0(0)
tcn bpdu's received (port/VLAN) 0(4)
forward trans count 1
scp failure count 0
root inc trans count (port/VLAN) 0(0)
inhibit loopguard FALSE
loop inc trans count (port/VLAN) 0(0)
Status of Port Timers
forward delay timer INACTIVE
forward delay timer value 15
message age timer INACTIVE
message age timer value 0
topology change timer INACTIVE
topology change timer value 35
hold timer INACTIVE
hold timer value 1
delay root port timer INACTIVE
delay root port timer value 0
delay root port timer restarted is FALSE
Vlan based information & statistics
spanningtree type ieee
spanningtree multicast address 01-80-c2-00-00-00
bridge priority 32768
bridge mac address 00-04-9a-80-a4-00
bridge hello time 2 sec
bridge forward delay 15(15) sec
topology change initiator: 3/13
last topology change occured: Fri May 14 2004, 10:04:36
topology change FALSE
topology change time 35
topology change detected FALSE
topology change count 9
topology change last recvd. from 00-07-50-8b-55-dc
Other port-specific info
dynamic max age transitions 0
port bpdu ok count 0
msg age expiry count 0
link loading 1
bpdu in processing FALSE
num of similar bpdus to process 1
received_inferior_bpdu FALSE
next state 3
src mac count: 0
total src mac count 0
curr_src_mac 00-00-00-00-00-00
next_src_mac 00-00-00-00-00-00
channel_src_mac 00-00-00-00-00-00
channel src count 0
channel ok count 0
NOTE
If the interface generating the topology change is not an end-device such as a workstation or server, but rather another device participating in STP, access this device and repeat the same command or similar commands until you reach the switch that shows the topology change generated by an end-device.
Step 3 Configure PortFast on the end-device interface that initiated the topology change. Further link up/down on that interface should not cause any STP topology change to be generated and, hence, no unnecessary unicast flooding due to this misconfiguration.
Use the following interface level command to configure the PortFast feature on a specific interface on Cisco IOS-based Catalyst switches:
spanning-tree port-fast
Example 5 shows an example of configuring PortFast on Fast Ethernet interface 7/2 on a Cisco IOS-based Catalyst switch.
Example 5 Configuring PortFast on an Interface on Cisco IOS-based Catalyst Switches
B#configure terminal Enter configuration commands, one per line. End with CNTL/Z. B(config)#interface FastEthernet 7/2 B(config-if)#spanning-tree portfast %Warning: portfast should only be enabled on ports connected to a single host. Connecting hubs, concentrators, switches, bridges, etc... to this interface when portfast is enabled, can cause temporary bridging loops. Use with CAUTION %Portfast has been configured on FastEthernet7/2 but will only have effect when the interface is in a non-trunking mode. B(config-if)#end
Unicast flooding might also occur due to other reasons such as asymmetrical routing, which manifests if the packets flow in different paths depending on direction of a bidirectional conversation. The preceding procedure addresses how to identify and rectify unicast flooding as a result of STP topology change due to host port misconfiguration. Taking corrective measures as outlined could improve network performance significantly.