On 6/2/11, [email protected] <[email protected]> wrote: > I'm trying to establish consensus on best practice CAM and ARP aging > timers for Cat6500 12.2(33)SXI5. > Various cisco docs state these should be synched to minimise unknown > unicast flooding. I'm looking into modifying them from the default > values (ARP timer 14400 sec, MAC aging time 300 sec) to minimise > excessive unknown unicast flooding which I'm seeing in the L2 network > (~400 downstream 3560 switches with ~8000 downstream hosts) which > aggregates at these 6500s. This topology does not have asymmetric > traffic flows - have others observed unicast flooding in topologies > without asymmetric traffic flows but with mismatched ARP/CAM timers?
In addition to mismatched arp/cam timers you might also have to watch out for topology change notifications [what does TCN stand for?] - ie. portfast disabled on a port and the port goes up/dn. That sets the fast aging timer to 15 seconds. We do have asymmetric traffic flows; I'm not sure if fast aging would be a problem for you or not. > I don't see the same problem with excessive unknown unicast flooding > in a similar network which aggregates at a pair of Nexus 7000. Cisco > modified the default values for ARP and MAC aging in NX-OS to 1500 > sec and 1800 sec respectively. Downstream access switches are still > using the IOS defaults, I've not seen a negative impact from the > mismatched MAC timers but would be keen to hear if others have > experienced issues with mismatched MAC timers between collapsed cores > and access switches. I like leaving the arp aging time at the default 4 hours and changing the mac aging time to 6 hours. That gives you a better chance of finding a mac address & you only have to sweep the network 4 times a day for the mac address / switch port info. (yes, you could do a ping sweep of every vlan on the switch before grabbing the mac/switchport info, but I suspect that causes it's own issues) > The quickest option I can see would be to reduce the ARP timer to > 300sec as I would only need to touch the SVIs on the 6500s but I'm > concerned that 300sec feels too low for an ARP timer in a relatively > large L2 domain and could have CPU impact. dunno, never tried that > Alternatively I could > increase the MAC aging timer to 14400sec to synch with the ARP timer, > or choose some new value altogether (perhaps the NX-OS defaults?). If > I did change the MAC aging timer is it strictly necessary to roll that > configuration out throughout the L2 domain? *strictly* necessary? no. nice? yes > Is there any particular > risk due to temporary CAM timer mismatch during the transition period > while the configuration is being rolled out? I can't imagine what risk there would be. Regards, Lee > Any comments/advice much appreciated! > Thanks, > George > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
