[c-nsp] HSRP issues on Cisco3550

[Sam Stickland]

Tom Sands wrote:
> We've seen this type of scenario for years, which is why we opted to 
> not have ECP with OSPF.  We did raise the cost on the standby.
>
> I would first as what your STP setting are in relation to the 
> Active/Stanby router and dual homed access switch (where are you 
> blocking).
>
> While not everything seems that it works the way you would expect it 
> to, in our setup the secondary uplink going from the access switch to 
> the standby router was in blocking on the access switch side.  And, 
> since the standby router was never used for an active return path for 
> forwarding, it would never have MAC's stored in it's CAM table, and in 
> some cases not even ARP's.  The standby router ends up having to 
> unicast broadcast out the traffic to all ports (to include the 
> secondary uplink that is blocking on the other side).  The active 
> router should (and does since you know ping works) forward this on to 
> the destination port that the MAC is seen on.  Why you don't get a 
> response on a traceroute, is just a "feature".  Maybe something to do 
> with the TTL, though I would doubt it since it's all L2 at that 
> point.  If you have access to the remote systems, I would run 
> tcpdump/ethereal on it to see if you receive the traceroute packet, 
> and what the response is from the system.
>
> Due to the inefficientness of the routing (flooding) of the stanby 
> router, we've just avoided setting it up this way, and changed the cost.
>
I'm not sure I understand this - wouldn't the standby router populate 
it's CAM table from the ARP replies? And it has to send out and ARP 
reply (and get a response), or the router can't populate the destination 
MAC address in frame.

S