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. Jeff