[c-nsp] Useful HSRP feature additions WAS:Rate limiting questions

[Matt Buford]

> As the the other side of things, I do have a number of 2 - 4 routers
> HSRP groups where the actual routers are miles apart and usually on
> different legs of the spanning tree star.  Unless I cannot do so for
> some reason (large number of very stupid clients) all of the HSRP
> speaking interfaces are running a 240 second arp timeout.

Personally, I do both.  I want to avoid flushing the MAC table as much as 
possible, so I set a very high timeout.  My network is large DCs with 
thousands of hosts - so I don't see much for temporary MACs.  Any MAC on 
there now is almost certain to be there for the forseeable future, so no 
need to time things out much.

However, keep in mind that whenever there is a STP topology change the MAC 
table is flushed.  So, you need low ARP timeouts on the HSRP interfaces to 
get things refreshed quick after a topology change.  Also, use portfast to 
minimize topology changes.  Only backbone link state changes should be a 
topology change - not customer host ports.

In this way, I pretty much completely avoid the issue - except immediately 
after a topology change (which I work to make rare).  It is not uncommon to 
see hundreds of megabits of flooded unknown unicast traffic in the tagged 
backbone inter-switch links in the moments after a topology change.

I played around with GLBP as an interesting workaround too.  GLBP can act 
like an active/active HSRP configuration, with two virtual MACs and random 
responses sent to clients pointing them to one or the other.  Since most 
hosts (servers I mean - PIX firewalls were a notable exception) have very 
short ARP timeouts, they tend to move back and forth between the two routers 
regularly.  As long as a MAC moves back and forth betwen the two GLBP 
routers more often than the MAC timeout, the issue is avoided (until STP 
topology changes come along at least).  I was forced to go back to HSRP 
though due to unrelated issues between GLBP and private vlans.

This is one case where Microsoft's chatty SMB broadcasts actually help too. 
This issue is mostly seen on traffic destined toward "well behaved" hosts 
that don't normally broadcast anything but their initial default gateway ARP 
request.