On 6/2/2011 9:36 AM, Florian Weimer wrote: >> have others observed unicast flooding in topologies >> without asymmetric traffic flows but with mismatched ARP/CAM timers? > I've seen them with default timers. I don't know if they were > mismatched. > > There is a feature called unknown unicast flood blocking (UUFB). It > might be available for your platform, too.
There was a thread on this not long ago... Basically if you have the ARP refresh before the CAM expires, the L3 gateway will ARP the device, it will answer, and repopulate both tables. But most (?) Cisco gear and IOS will do an advance unicast ARP query of the target prior to the actual ARP expiration time. According to Rodney Dunn in 1/4/2011: > There were some changes to ARP at one point to provide some more triggered > capability. > I don't recall exactly what that was but the default behavior for many years > was that > we send a unicast arp to the destination 60 seconds prior to the arp timer > set to > expire. If we don't get a response we send it again when the timer pops and > if no > response we invalidate the ARP entry. You might check back on that thread for additional details... but ARP doesn't just "expire", it tries to refresh... twice... before ditching the entry. The ARP response will repopulate/refresh the CAMs in the process. The "unicast flooding" you may see with "sinkhole" hosts -- e.g., a syslog server than never transmits anything, just receives log data. If you have default ARP timeout of 4 hours, the default CAMs will expire in 5 minutes, and the remaining 3:55 will result in the syslog data being unicast-flooded across the vlan. You want the hosts to periodically "speak" -- and cutting the default ARP back (or extending the CAM out) will do just that for you. Jeff _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
