Unicast Flooding

Jeff Kell jeff-kell at utc.edu
Thu Jun 18 15:05:51 UTC 2009

Holmes,David A wrote:
> In a layer 3 switch I consider unicast flooding due to an L2 cam table timeout a design defect. To test vendors' L3 switches for this defect we have used a traffic generator to send 50-100 Mbps of pings to a device that does not reply to the pings, where the L3 switch was routing from one vlan to another to forward the pings. 

You don't need an elaborate scenario to create the unicast flooding. 
Syslog servers can cause this quite frequently, if all they do is sink
syslog UDP traffic and never (or rarely) generate any packets themselves.

You can push up L2 / CAM / mac-address-table timeouts, but you may have
some unexpected results if you have a volatile / mobile network where
end devices are not static.

I still don't have a "really comfortable" recommendation on settings,
but agree in general that the ARP timeout should be somewhat less than
the L2 timeout, and yes, the ARP response will refresh the L2 entry.

It gets even more complicated if you are using a NAC / monitoring
function that triggers on mac-address-table tracking / changes / traps,
as the shorter the L2 timeout, the more frequent your mac-address-table
changes are generated.

You can complicate this even further with "smart" monitors that are
trying to keep a mapping of IP-to-MAC-to-switchport -- you may have L2
entries without ARPs, ARPs without L2 entries, etc.


More information about the NANOG mailing list