Unicast flood

From Wikipedia, the free encyclopedia
Jump to: navigation, search

In computer networking, a unicast flood is the unintentional behavior of a switch treating a unicast packet as a broadcast packet; a packet destined for one host is flooded or transmitted out of all the ports of a switch.

Explanation[edit]

The term unicast refers to the method of a router sending a message to a single destination. Conventionally, this packet messaging method is considered more secure. This diagram illustrates the standard unicast packet send from one network host to another:

Unicast.svg

When a switch receives a unicast packet with a destination address not in the switch’s forwarding table, the packet is treated like a broadcast packet and sent to all hosts on a network:

Broadcast.svg

Causes[edit]

A switch that has no room left in its address cache will flood the packet out to all ports. This is a common problem on networks with many hosts. Less common is the artificial flooding of address tables—this is termed MAC flooding.

Another common cause are hosts with ARP timers longer than the address cache timeout on switches—the switch forgets which port connects to the host.[1]

Devices other than switches may create unicast floods as well. A router which has a bridge interface but does not have the destination packet's address in the bridge cache will flood the packet out to all bridge members.[2]

Misconfigured features of the networks may lead to unicast flooding as well. If there are two layer 2 paths from Host A to B and Host A uses path 1 to talk to Host B, but Host B uses path 2 to respond to Host A, then intermediate switches on path 1 will never learn the destination MAC address of Host B and intermediate switches on path 2 will never learn the destination MAC address of Host A.[3]

A final cause of unicast floods are topology changes. When a link state changes on a network port which participates in rapid spanning tree, the address cache on that switch will be flushed causing all subsequent packets to be flooded out of all ports until the addresses are learned by the switch. [4]

Remedies[edit]

There are several remedies discussed in the links above. [1] [2] [3] But for many situations, a low end switch needs to be replaced with a higher end switch—one that has a larger address table and one that can block unicast floods. Blocking unicast floods on a Cisco switch is easy to do, but it is not enabled by default. After ensuring that timeouts and/or security features have been configured to maintain table entries on client access ports longer than typical host ARP cache timeouts, this command is used to quiet down the unicast floods on those ports:[5]

Switch(config-if)# switchport block unicast

Other techniques involve isolating hosts at Layer 2, which blocks intra-LAN communication not destined to the router. A handy tool (available in lower end switches[6] ) is the

Switch(config-if)# switchport protected

or a more robust, cross-switch solution than 'switchport protected' is the use of Private VLANs.[7]

Effects on Networks[edit]

When a network is experiencing unicast flooding, network performance is degraded. Here is an graph of a bridge before and after adjusting the size of the bridge address cache:

StoppingTheUnicastFlood.png

80% of the packets were flooded out never to be received by the destination address, while 20% was valid traffic (image from first reference). In high volume networks, the flooded traffic may cause ports to saturate and lead to packet loss and high latency.

Another side effect of exhausted address tables is the compromise of data. The security considerations are discussed in the MAC flooding—one of several causes of unicast floods. If an end user is running a packet sniffer, the flooded packets could be captured and viewed.

References[edit]

  1. ^ Steven King (2009-06-17). "Unicast Flooding". Retrieved 2012-01-27. 
  2. ^ Rudy Rucker (2012-01-27). "Fix for unicast flooding". Retrieved 2012-01-27. 
  3. ^ "Elimination of Asymmetric Forwarding and Unicast Flooding". Cisco Systems Inc. Retrieved 2012-01-27. 
  4. ^ Balaji Sivasubramanian (2004-09-10). "Troubleshooting Unicast Flooding Due to Topology". Cisco Press. Retrieved 2012-01-27. 
  5. ^ Jeremy Stretch (2010-06-04). "Blocking Unknown Unicast Flooding". PacketLife.net. Retrieved 2012-01-27. 
  6. ^ Petr Lapukhov (2008-07-14). "Private VLANs Revisited". Retrieved 2012-04-07. 
  7. ^ "Configuring Private VLANs". Cisco. Retrieved 2012-04-07.