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

[Phil Mayers]

On Sat, 2007-10-27 at 14:12 -0800, Christopher E. Brown wrote:
> Phil Mayers wrote:
> > On Fri, 2007-10-26 at 12:10 -0800, Christopher E. Brown wrote:
> >> Phil Mayers wrote:
> >>> On Fri, 2007-10-26 at 13:08 -0500, Justin Shore wrote:
> >>>> Phil Mayers wrote:
> >>>>>> Is there a HSRP option to tell the standby router to only route traffic 
> >>>>>> when it's active?  VRRP and GLBP would have the same problem I imagine. 
> >>>>> No. This is a frequently requested feature.
> >>>> I think I'll ping my account team to add my voice to the list.  This 
> >>>> seems like an awfully easy feature addition to me.  I can't think of any 
> >>> At first hearing it does indeed seem easy. Having put some thought into
> >>> why Cisco don't offer this (fairly obvious) feature, I've concluded
> >>> there are some non-trivial difficulties doing it in the fully general
> >>> cases that HSRP can support, and on some forwarding architectures.
> >>>
> >>>
> >>>> downside to doing it either.
> >>>>
> >>>> Justin
> >>
> >> I think a more useful HSRP feature would be
> >>
> >> standby 116 gratuitous arp 240
> >>
> >> in order to solve the longstanding issues with MAC table aging v.s. ARP
> >> table aging w/ HSRP.
> > 
> > As I understand it, the "longstanding" arp/mac aging mismatch issue
> > occurs when traffic is returning via the standby and the standby ages
> > out the mac entry because it isn't seeing the outbound packets.
> > 
> > The hsrp master doing grat. arps for itself doesn't address that, does
> > it?
> > 
> >> I wouldn't think that generating grat arps for the HSRP address with the
> >> HSRP MAC would be that hard.
> > 
> > It wouldn't. I don't see how it would solve the problem though.
> 
> 
> No, the issue is that the HSRP master never *sends* traffic using the
> HSRP virtual MAC address.  It will respond to ARPs, and accept traffic,
> but but all traffic put on the wire has a src MAC from the physical
> interface.
> 

Ok, we're talking about different issues.

"The issue" I was referring to is the oft-referenced document:

http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080094afd.shtml#t8

i.e. return path traffic hits HSRP standby, standby has an active ARP
entry for the destination but the FDB entry has timed out.


> So, machines ARP for the GW address.
> 
> The HSRP master responds with the virtual MAC.
> 
> Virtual MAC now in mac table of switches and ARP table of routers.
> 
> 5 min later, the MAC entry times out, but the ARP entries are there for
> another 4hr 55min...  Now we have our layer2 network with no target for
> that MAC and flooding everywhere.

I do not see that problem at all, across hundreds of different
HSRP-protected subnets. In fact, I see the HSRP master emitting its HSRP
hello packets (which are of course, pretty frequent) with the source of
the vmac:

19:03:26.873306 00:00:0c:07:ac:00 > 01:00:5e:00:00:02, ethertype IPv4
(0x0800), length 62: 192.168.51.254.hsrp > 224.0.0.2.hsrp: HSRPv0-hello
20: state=active group=0 addr=192.168.51.1

They are of course emitted to a multicast layer2 group address, but
still; every single one of the switches on my network has a valid FDB
entry for the HSRP vmac, at all times

What platforms/topologies are you seeing this problem in?