[c-nsp] HSRP vs VRRP

[Tim Durack]

It's always worked well for us. It's such a simple protocol, I don't see
what could go wrong.
Active/Standby can toggle sometimes if the RP is under load, such as during
an ACL change.

HSRP works for us, for certain values of "work" - one of the problems
> that neither HSRP nor VRRP is ever going to solve is "split switches",
> like
>
> R1 R2
> | |
> sw1 ------ sw2
> | |
> H1 H2
>
> if the link between sw1 and sw2 breaks, both R1 and R2 assume they are
> "master", but for packets coming in from "the world", only one of the
> routers will be able to deliver, and that's not something you can control
> via HSRP/VRRP.


That's why it's preferable to design things so R1 is connected to SW1 and
SW2, same for R2.
This will avoid partitioning the network under various failure modes.

Furthermore, HSRP will necessarily lead to asymmetric traffic (packets
> entering the HSRP slave from "other" interfaces will always be sent to
> the link, even if it knows that the traffic is asymmetric) - which might
> be a problem, or might be not. I find that unelegant, something like
> "if HSRP slave, make interface invisible for IP processing" (withdraw
> static and connected routes) would be much nicer in the face of stateful
> packet filtering, and so on.


The assymetric situation has caught us out when running urpf filtering on
interfaces that are also running HSRP.
It basically means you can't always ping the interface addresses. Only
affects monitoring though, not transit.

Tim>: