Home > Articles > Cisco Network Technology > General Networking > Troubleshooting Unicast Flooding Due to Topology

Troubleshooting Unicast Flooding Due to Topology

Contents

  1. Troubleshooting Unicast Flooding Due to Topology Changes

Article Description

Unicast flooding occurs for many reasons in a switched network. This article addresses how to detect and troubleshoot unicast flooding issues due to spanning tree topology changes.

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 1Figure 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 2Figure 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.