Asymmetric Routing and HSRP

[Zhiyuelkeliu_2]

Question:

I am wondering if the asymmetric routing and HSRP issue demonstrated in the following link as Case Study #8 will apply to any multilayer switches environment with same topology and same config as case 8? Such as if the two switches are 4506E..

http://www.cisco.com/c/en/us/support/docs/ip/hot-standby-router-protocol-hsrp/10583-62.html#t8

thank you in advance,

[Joseph W. Doherty]

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

Yes, and the issue (#8) isn't limited to HSRP.

[Zhiyuelkeliu_2]

thanks you Joseph for your kind reply.

Some background informatioin: Network slowness was observed a few year ago when the two switches were 6509, and it was resolved after I changed the MAC aging time and ARP timeout to the same value. For some reason, we migrated the switches to 4506E two years ago with same topology and same HSRP design (one is active for odd vlans, and the other is active for the even vlans), but kept the MAC aging time and ARP timeout as default, but so far so good. I started wondering if the issue is platform related, as different platform use different switching techologies, but any way, layer 2 and layer 3 still have different tables, and aging times.

So just want to clarify it with you that: if we still want to have HSRP load sharing, then we should adjust the MAC or ARP timeout value, to ensure good network performance, or keep HSRP active on one switch.

thanks again..

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

I would suggest aligning your MAC and ARP timers as it's a generic issue on any of Cisco L3 switches, also noted when you search for dealing with unicast flooding, e.g.:

http://www.cisco.com/c/dam/en/us/td/docs/video/headend/Digital/QAM_Series/4022934_A.pdf

http://www.cisco.com/c/en/us/support/docs/switches/catalyst-6000-series-switches/23563-143.html?referring_site=smartnavRD

[Zhiyuelkeliu_2]

Thanks Joseph again for your kind help. It is much clear now..

All the best!!

[Zhiyuelkeliu_2]

Hi Joshph,

In the 'Introduction' of the first article, it is saying 'However, there have been occasions in which those packets are 'flooded' through all ports on the same switch every five minutes. I don't think it is every five minutes, instead, the packets will be flooded through all ports in the same vlan after 5 minutes(CAM table aged out), untill another arp sending out (arp table timeout). Is that correct?

thanks,

[Joseph W. Doherty]

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Yes, I agree with you on both points.  I.e. flooding would be limited to same VLAN (or trunk) ports.  Problem begins after CAM timer expires and until something like an ARP causes a refresh of CAM address table.

[Zhiyuelkeliu_2]

Great. Thanks a lot!!

[Zhiyuelkeliu_2]

Hi Joseph,

I think the issue doesn't exist in Nexus or VSS enviroment, as they do sync the layer 2 forwarding table (mac-address-table). Is it correct?

thanks again,

[Joseph W. Doherty]

Disclaimer

The  Author of this posting offers the information contained within this  posting without consideration and with the reader's understanding that  there's no implied or expressed suitability or fitness for any purpose.  Information provided is for informational purposes only and should not  be construed as rendering professional advice of any kind. Usage of this  posting's information is solely at reader's own risk.

Liability Disclaimer

In  no event shall Author be liable for any damages whatsoever (including,  without limitation, damages for loss of use, data or profit) arising out  of the use or inability to use the posting's information even if Author  has been advised of the possibility of such damage.

Posting

Yes, correct, you don't have that problem when your gateway is on a logical device.  That would apply to VSS, Nexus fabric extenders, 6800ia switches or stackable switches.

[Zhiyuelkeliu_2]

thumbs up!!

  much appreciated!!