[c-nsp] Best practice for CAM and ARP aging timers

[g***@dalyshome.co.uk]

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?
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.
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. 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? Is there any particular
risk due to temporary CAM timer mismatch during the transition period
while the configuration is being rolled out?
Any comments/advice much appreciated!
Thanks,
George
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Lee]

Post by g***@dalyshome.co.uk
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.

Post by g***@dalyshome.co.uk
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)

Post by g***@dalyshome.co.uk
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

Post by g***@dalyshome.co.uk
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

Post by g***@dalyshome.co.uk
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

Post by g***@dalyshome.co.uk
Any comments/advice much appreciated!
Thanks,
George
_______________________________________________
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Florian Weimer]

Post by g***@dalyshome.co.uk
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.
_______________________________________________
cisco-nsp mailing list cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

[Jeff Kell]

Post by Florian Weimer

Post by g***@dalyshome.co.uk
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.

Post by Florian Weimer
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 cisco-***@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/