CAM table aging

cisco_troopercisco_trooper Member Posts: 1,441 ■■■■□□□□□□
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?

Comments

  • networker050184networker050184 Mod Posts: 11,962 Mod
    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.
    An expert is a man who has made all the mistakes which can be made.
  • cisco_troopercisco_trooper Member Posts: 1,441 ■■■■□□□□□□
    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.
  • networker050184networker050184 Mod Posts: 11,962 Mod
    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.
    An expert is a man who has made all the mistakes which can be made.
  • APAAPA Member Posts: 959
    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?

    CCNA | CCNA:Security | CCNP | CCIP
    JNCIA:JUNOS | JNCIA:EX | JNCIS:ENT | JNCIS:SEC
    JNCIS:SP | JNCIP:SP
  • networker050184networker050184 Mod Posts: 11,962 Mod
    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.
    An expert is a man who has made all the mistakes which can be made.
  • kpjunglekpjungle Member Posts: 426
    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?
    Studying for CCNP (All done)
  • networker050184networker050184 Mod Posts: 11,962 Mod
    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.
    An expert is a man who has made all the mistakes which can be made.
  • kryollakryolla Member Posts: 785
    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.
    Studying for CCIE and drinking Home Brew
  • networker050184networker050184 Mod Posts: 11,962 Mod
    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.
    An expert is a man who has made all the mistakes which can be made.
  • kryollakryolla Member Posts: 785
    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.
    Studying for CCIE and drinking Home Brew
  • networker050184networker050184 Mod Posts: 11,962 Mod
    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.
    An expert is a man who has made all the mistakes which can be made.
Sign In or Register to comment.