Unicast flood

The term unicast refers to a one-to-one transmission from one point in the network to another point. Conventionally, unicast is considered more secure because the frame is delivered solely to the intended recipient and not to multiple hosts. This diagram illustrates the unicast transmission of a frame from one network host to another:

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

The learning process of transparent bridging requires that the switch receive a frame from a device before unicast frames can be forwarded to it. Before any such transmission is received, unicast flooding is used to assure transmissions reach their intended destination. This is normally a short-lived condition as receipt typically produces a response that completes the learning process. The process occurs when a device is initially connected to a network, or is purged from the forwarding information base. An entry is purged when the device is moved from one port to another (causing the link status to change on the original port) or after a MAC table entry expires due to inactivity (5 minutes is the default on Cisco switches).

A switch that has no room left in its address cache will flood the frame 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] The solution to prevent this is to have the switch configured with a MAC address timeout longer than the ARP timeout. For example, set the MAC timeout to 360 seconds and the ARP timeout to 300 seconds.

Devices other than switches may create unicast floods as well. A router which has a bridge interface but does not have the destination frame's address in the bridge cache will flood the frame 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 frames to be flooded out of all ports until the addresses are learned by the switch. [4]

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 specific nodes providing a shared service (e.g. a router). A handy tool for this are protected ports (ports which are forbidden to communicate with other protected ports), available in lower end switches:[6]

Switch(config-if)# switchport protected

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

To block flooding on a Linux machine modern enough to have iproute2 installed, you can control the flooding in the devices bridge by running bridge link set dev phy6 flood off. To set a MAC timeout larger than the ARP timeout, these commands can be issued:

brctl setageing br0 330; echo 300 > /proc/sys/net/ipv4/neigh/br0/gc_stale_time

Most modern switches -- high and low end -- support flooding protection.l

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

80% of the frames were flooded out never to be received by the destination address, while 20% was valid traffic. 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 frames could be captured and viewed.

• Broadcast, unknown-unicast and multicast traffic