Root Causes and Mitigation of Unknown Unicast Flooding in Data Center Networks

Data packets are encapsulated with an IP header (containing source and destination IP addresses) and a MAC frame header (containing source and destination MAC addresses); the MAC addresses change at each routing hop while the IP addresses remain constant.

When two hosts are in the same subnet, the source host determines that the destination IP belongs to its own network and must obtain the destination MAC address, first checking the ARP table for an existing entry.

If the ARP table lacks the entry, the host broadcasts an ARP request, receives an ARP reply, stores the IP‑to‑MAC mapping with an aging timer, and then uses that MAC as the frame’s destination address.

The source host then places its own MAC as the source MAC and the resolved destination MAC into the frame header before transmitting the frame.

Layer‑2 switches learn the source MAC address from incoming frames and build a MAC address table; when a destination MAC is not found in this table, the switch floods the frame out all ports belonging to the relevant VLAN, a process known as unknown unicast flooding, which can exhaust bandwidth and cause packet loss.

For hosts in different subnets, the source host forwards the packet to the default gateway, which performs routing; the gateway resolves the destination MAC via ARP if needed, and because the gateway’s MAC table contains the destination MAC, unknown unicast flooding does not occur in this path.

However, if the gateway’s ARP table has an entry but its MAC address table lacks the corresponding entry, the gateway will also flood the frame, creating unknown unicast flooding.

The differing aging times of ARP entries (longer) and MAC table entries (shorter) are a key factor that can trigger unknown unicast flooding.

In the presented data‑center case, a server behind an LVS tunnel sends responses directly to the client, bypassing the LVS node; after the client’s MAC entry on SW2 ages out (≈5 minutes), SW2 begins flooding traffic destined for the client, sending it to the core switch.

The core switch’s vendor‑specific learning policy only records source MACs for frames that are switched at Layer‑2, ignoring those that are routed at Layer‑3; because client‑to‑LVS traffic requires Layer‑3 forwarding, the core switch never learns the client’s MAC, causing persistent unknown unicast flooding.

Since the core and access switches are connected via trunk links that carry all VLANs, the flooded traffic propagates to every access switch and then to all hosts in those VLANs, potentially saturating 1 Gbps links and degrading server network performance.

Mitigation steps include: (1) reconfiguring the core switch to learn source MAC addresses from all incoming frames regardless of egress interface, eliminating the flooding at the core; and (2) adjusting the server’s routing to use source‑IP‑based routing so that packets with the LVS VIP as the source IP are sent directly to the core switch, removing the flooding on SW2.