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? _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
