From the author of

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.

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.

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 vlanvlan-iddetail

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.

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:

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.