07-13-2010 09:32 AM - edited 03-06-2019 12:00 PM
We want to configure the "mac-address-table synchronize" command on our 6500 series switches to ensure that the CAM tables on our DFCs are in synch with the PFC on the supervisor modules. In reading this
it is recommended that we disable the routed MAC purging with the mac-address-table aging-time 0 routed-mac global configuration command.
What is a routed mac entry? Are there any issues with running that mac aging-time command?
We also plan to run this command "mac-address-table aging-time 14400" to keep our ARP and CAM tables on the same aging time to reduce unicast flooding on our network. Can we run this command with the "routed-mac" command above?
Solved! Go to Solution.
07-13-2010 02:37 PM
Hi,
There is always a catch when using the DFC on the Cat 6500 and what we should add to help reduce the
potential of unicast flood issues. When we use Distributed Feature Card (DFC) is
responsible for maintaining each own CAM table. This means that each DFC learns the MAC
address and ages them, which depends on the CAM aging and traffic matching that particular
entry. With distributed switching, it is normal that the supervisor engine does not see
any traffic for a particular MAC address for a while, so the entry might expire in which some
cases can induce the unicast floods.
mac-address-table synchronize
mac-address-table aging-time 0 routed-mac
Note: “mac-address-table synchronize command purges the routed MAC entires. In order to
avoid this, disable the routed MAC purging with the mac-address-table aging-time 0
routed-mac global configuration command.”
The mac-address-table aging-time 0 routed-mac in the SXH code train has been deprecated,
So as we move to SXH this command is no longer needed when using the synchronized
functions.
HTH,
07-13-2010 02:37 PM
Hi,
There is always a catch when using the DFC on the Cat 6500 and what we should add to help reduce the
potential of unicast flood issues. When we use Distributed Feature Card (DFC) is
responsible for maintaining each own CAM table. This means that each DFC learns the MAC
address and ages them, which depends on the CAM aging and traffic matching that particular
entry. With distributed switching, it is normal that the supervisor engine does not see
any traffic for a particular MAC address for a while, so the entry might expire in which some
cases can induce the unicast floods.
mac-address-table synchronize
mac-address-table aging-time 0 routed-mac
Note: “mac-address-table synchronize command purges the routed MAC entires. In order to
avoid this, disable the routed MAC purging with the mac-address-table aging-time 0
routed-mac global configuration command.”
The mac-address-table aging-time 0 routed-mac in the SXH code train has been deprecated,
So as we move to SXH this command is no longer needed when using the synchronized
functions.
HTH,
05-01-2012 08:45 AM
I'm bumping this old thread for further clarification.
It is not clear whether routed-mac addresses are cleared only during execution of the "mac-address-table syncronize" command, or whether they are cleared on an ongoing basis as long as the "mac-address-table syncronize" command is in effect.
1) Should we take care to use the "mac-address-table aging-time 0 routed-mac" command *before* applying the "mac-address-table syncronize" as opposed to after doing so?
2) Should we execute "no mac-address-table aging-time 0 routed-mac" after executing the "mac-address-table syncronize" command (or apply a non-zero time) or should we leave the "mac-address-table aging-time 0 routed-mac" command intact? If the former, how long should we wait for things to settle?
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: