Asymmetric Routing: Unicast Flooding Control

Unanswered Question
Jan 26th, 2009

Sniffing a vlan I see multiple unicast conversations. Some suspect the additional unicasts are overwhelming our file server(s), hence performance issues, hence "its the network".

switchport block unicast shuts down the DFS, so this isn't helpful troubleshooting. I see this storm-control unicast level xxx command. Some have told me this clears the interface unicast flood counters but still allows the excess unicast to hit the interface. sh mac-address-address unicast flooding command isn't supported on 12.233SFX so I need to upgrade IOS but the release notes of anything newer doesn't address unicast flooding. Any direction on how to work this would be helpful?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
chuckwirth Mon, 01/26/2009 - 08:09

When you say "multiple unicast conversations", do you mean that packets are being duplicated or just that many conversations are unicast? On most networks you probably should see multiple unicast conversations (as opposed to lots of broadcasts); it just means two hosts are talking to each other. If your sniffing shows one host responsible for most of the traffic (and it isn't a server) there may be something wrong with it such as a virus or hardware problem. Some unicast flooding is normal such as when the mac-address table entry has timed out. The frames need to be flooded because the switch doesn't know which port to use.

Try a show interfaces command on the switch interface the server is attached to. Near the top of the output there should be a line that looks like this: txload 1/255 rxload 1/255. This is traffic going out and coming in the interface respectively. You'll have to do the math to get the percentage.

If your percentage is low there isn't any problem. If it's high you could try the storm-conrtol command.

Router(config-if)# storm-control unicast level "level"

Specify the level as a percentage of the total interface bandwidth:

-The level can be from 0 to 100.

-100 percent means no traffic storm control.

-0.0 percent suppresses all traffic.

To see if frames are being dropped use:

#show interfaces "interface" counters unicast

A traffic storm occurs when packets flood the LAN, creating excessive traffic and degrading network performance. The traffic storm control feature prevents LAN ports from being disrupted by a broadcast, multicast, or unicast traffic storm on physical interfaces.

Traffic storm control monitors the level of each traffic type for which you enable traffic storm control in 1-second traffic storm control intervals. Within an interval, when the ingress traffic for which traffic storm control is enabled reaches the traffic storm control level that is configured on the port, traffic storm control drops the traffic until the traffic storm control interval ends.

If you're getting unicasts due to mac-address aging you could try to configure the aging time for entries in the Layer 2 table. Use the mac-address-table aging-time command in global configuration mode. To reset the seconds value to the default setting, use the no form of this command. The default value is 300 seconds or 5 minutes.

Cisco 2600 Series, Cisco 3600 Series, and Cisco 3700 Series Routers:

#mac-address-table aging-time "seconds"

#no mac-address-table aging-time "seconds"

Catalyst Switches:

#mac-address-table aging-time "seconds" [vlan vlan-id]

#no mac-address-table aging-time "seconds" [vlan vlan-id]

Storm control:

mac-address-table aging-timer

mlenco Mon, 01/26/2009 - 12:24

The mac-address table age timer is 5 minutes. The layer 3 arp table timer is 4 hours. When the switch mac timer ages out and a pc generates a unicast to another host with a switchport of a distant switch that has been idle for at least 4 minutes the switch generates an arp. If you multiply this by many hosts you can get some added unicasts. When we changed the mac-address age timer 16200 we initially didn't see any additional unicasts but now we see them again.

The interface stats are golden 1/255, 255/255, 1/255. The storm control may be an option but it just seems to be a bandaid. Why is the switch unable to control unicasts?

chuckwirth Tue, 01/27/2009 - 10:10

Why do you think the switch is unable to control unicasts? How are you measuring it? What is your baseline? Is there a common source or destination address or is it evenly spread? A common source could mean a problem with a host.

If your interface stats are good, it means there is very little traffic coming in or out of the port and it is most likely not a problem that is affecting your server or anything else. Remember that the show interfaces command is just a snapshot and you should be using network monitoring with snmp to get a more realistic long-term view of your link utilization.

Limited unicast and broadcast flooding is part of the normal switching process.

You may be confusing some terminology. ARPs are layer 2 broadcasts, not unicasts. Switches flood layer 2 broadcasts out all ports on the VLAN except for the one it came in on. Switches do not normally generate ARPs, only hosts and servers. The exception would be switches that are doing it for management purposes, but not in the normal transmission of user data.

Your workstations also have arp caches. If you are using vista, they have changed the timers from XP from 2 minutes (maximum of 10 minutes) to between 15 and 45 seconds. This means that the hosts will be sending out ARP requests more frequently.

Here is a reference for troubleshooting unicast flooding. The most common problem is asymmetric routing.

troubleshoot unicast flooding

arp cache explained

Vista arp caching behavior


This Discussion