CAM table aging

cisco_trooper

I'm working through an issue here that involves the CAM table aging out prior to the ARP table. I'm wondering what repercussions there may be for setting the CAM table aging-time significantly higher than the default of 300 seconds. I can't think of any huge issues off hand other than idle entries stay in the table longer. Can anyone else shed any other light on this?

networker050184

There shouldn't be any other issues besides what you already know. Cisco recommends raising the MAC timeout in situations where the ARP/MAC timeout differences cause an issue. This can also be raised per VLAN so you don't have to increase the timeout on the whole platform.

Would this hapen to be an issue with HSRP?

If so check out Understanding and Troubleshooting HSRP Problems in Catalyst Switch Networks.

cisco_trooper

networker050184 wrote: »

There shouldn't be any other issues besides what you already know. Cisco recommends raising the MAC timeout in situations where the ARP/MAC timeout differences cause an issue. This can also be raised per VLAN so you don't have to increase the timeout on the whole platform.

Would this hapen to be an issue with HSRP?

If so check out Understanding and Troubleshooting HSRP Problems in Catalyst Switch Networks.

Yep, that's it, and I have seen that article. I just want to be absolutely sure before I make such a change.

networker050184

I've made the change before without any known issues in the year that I was there. I don't work in that environment anymore, so I'm not sure if any issues eventually arose though I doubt it.

APA

networker050184 wrote: »

I've made the change before without any known issues in the year that I was there. I don't work in that environment anymore, so I'm not sure if any issues eventually arose though I doubt it.

just out of curiosity.. what led you to changing the default aging timer?

networker050184

A.P.A wrote: »

just out of curiosity.. what led you to changing the default aging timer?

We ran into the asymmetric routing issue and a little research dug up that documentation. Made the change and the unicast flooding was decreased dramatically. It can start to get out of hand when you have about 50+ HSRP groups between a couple of switches.

kpjungle

networker050184 wrote: »

We ran into the asymmetric routing issue and a little research dug up that documentation. Made the change and the unicast flooding was decreased dramatically. It can start to get out of hand when you have about 50+ HSRP groups between a couple of switches.

Thats alot of HSRP groups between a couple of switches. Can I ask what kind of switches they are, and what the use of all those groups are for?

networker050184

These were 6500 data center switches. They had a lot of SVIs serving as the gateways for all the data center devices. The HSRP was set up between the devices to provide redundancy for all the VLANs.

Another solution to the issue would have been to just make one device active for all VLANs and the other standby for all VLANs, but then you don't take advantage of all your bandwidth.

That was a couple years ago that I worked in that environment so not sure if they are still chugging along with the same solution.

kryolla

Good stuff I just spent a couple of hours going over it and why the MAC address was timing out. Another solution but doesnt scale well is to put a static entry for the Host and what trunk port to get to that host.

networker050184

kryolla wrote: »

if you dont have a lot of HSRP groups you can put a static entry

Agreed that it will work, but thats like saying to just use static routes if you don't have a lot of routes. It works, but the overhead of making changes sucks to say the least. Not to mention someone with little knowledge of the setup moves the device to another port.

kryolla

you got to it before I edited my post LOL. If that device moves to another port within the switch that is okay as the mac entry that ages out points to a trunk port. How often does a data center device move, the place where I work they dont move at all except to replace it or add some more but we dont just unplug it and move it and plug it to another port.

networker050184

Yeah we were posting simultaneously.

A static MAC entry to a trunk wouldn't really be a bad idea as long as the device remains behind that trunk, but you would have to add the static entry for every device, which in a data center can be A LOT.