Re: Unicast flooding and mac address table synchronisation

chris.smailes · ‎10-21-2010

Hello everyone, I wonder if anyone can answer this question:

Since configuring HSRP for some of our networks, we’ve been having an occasional unicast flooding issue. The issue is documented on the Cisco site and in our case seems to be due to the asymmetrical routing caused by using HSRP. The flooding does stop if the standby HSRP interface is shut down.

.

To try to deal with this problem, I increased the global mac address aging timer on each of our 6509’s to 18000 s (5 hrs) to make it longer than the default ARP cache timer (4hrs = 14400 s). The flooding did seem to stop for a couple of days but then happened again.

.

Then I realised that as we are using linecards with dfc’s and also have etherchannels split across linecards (for resilience) that we needed to enable mac address table synchronisation between the dfc’s and pfc’s. using the mac-address-table synchronize command. I couldn’t find much Cisco documentation on the issue of routed mac addresses or on what ‘mac-address-table synchronize auto’ would do.

.

(There are a few snippets on the forums) Our software levels are now all at either 12.2(33)SXH4, SXH6, SXH7 or 12.2(33)SXI. Even with the following commands in: mac-address-table synchronize mac-address-table aging-time 18000 the problem still reoccurred so I’ve left the HSRP standby leg disabled for now.

.

My question is:

.

For an older software level it was advised to use mac-address-table aging-time 0 routed-mac - this command has been deprecated

and I am wondering if we need an equivalent, e.g.

.

no mac-address-table aging-type routed-mac but I don’t want to configure this without some advice on its effect. I've looked at the issue of TCNs and we don't get many - our access ports are configured with portfast so I don't think it's that.

.

(The other option would be to reduce the ARP timer for that vlan but this would increase the broadcast traffic and if possible I’d like to find out why the measures taken so far haven’t worked.)

.

I can send a diagram and configuration data if needed. Thanks very much for your help.

chris.smailes · ‎10-29-2010

Just an update - after moving the two SVI's to 6509's with s/w version 12.2(33)SXI4, the issue looks to have gone. Of course there is still occasional flooding - e.g. when TCN's are received but the excessive flooding has stopped.

mselea · ‎11-27-2012

Imho, your question has nothing to do with the issue... As many poeple do, you are not considering the difference between how HSRP works between two router ports (not interfaces/idb's!) and how HSRP behaves and what it may create when used on a multilayer switching ports (performing l2/l3 switching -as an example...).

Instead of playing around with arp aging timeouts and other similar params in mac address table, try to configure a small hello-time interval for the standby, and configre also the use BIA for standby mac-address... Imho, the issue pops up when the standby flaps over and the same mac-address is used for the standby router...

While about the amc-address-table sync. I'd open a sr with TAC and ask whatever question you might find undocumented... Basically, when having dfc's in the chassis, a mac-addr-table sync is to be configured to avoid unnecessary traffic accross the backplane and let the local engine to perform switching at the same time with sync'ing the params of the mac-addr-table with the sup/rsp one... Good luck!

chris.smailes · ‎11-27-2012

Hi Marian - thanks for the reply. It's an interesting theory but I don't think it is correct in this case. There were no HSRP state changes when this happened. I'm pretty sure the issue is caused by asymmetrical routing. It hasn't happened again with the measures mentioned above and after upgrading the software. Best Regards, Chris.