Owner-less VRRP?

[André Beck]

Hi,

on the K-platforms (yl & zl) HP implemented some derivative of VRRP that still resembles the insanity of XRRP in that the virtual IP (VIP) is borrowed from one of the member routers real interface IPs and that router has some special role, called the "Owner". I hate this, for a number of reasons (some of which are documented as dubious limitations or unclear warnings about dysfunction, like in "you cannot ping the VIP when it is failed-over to the backup" or "OSPF and VRRP on the same interfaces has issues").

Now the docs say that you can have more than one "Backup" router, and I expect it to do the right thing (as long as there are backup routers alive, the VIP will be bound to the highest priority member of this set). So the question arises:

What happens when I configure backups ONLY?

Leaving out the owner would make the VIP a true VIP (it would not clash with any real interface address and truly roam) and restore correct reachability behavior to the real IPs. The VIP would not be pingable, though. But OSPF may suddenly work as expected (LSAs will be injected from real IPs, not from a potentially roaming and adjaceny killing real-VIP-mixup).

Anyone tried to configure it this way already?

Given that a VRRP setup should continue to work (even with the primary backup going away as long as additional backups are available) should the configured owner break and be replaced days later, why not leave it out forever and return sanity to the VRRP business?

TIA,
Andre.

[Matt Hobbs]

I recommended this idea to someone else recently for another issue (which I can't remember the finer details of, something about a next hop failover).

Anyway, sounded fine to me in theory. I don't know of anyone though that is using it in practice just yet.

Also with the backup does not respond to ICMP, that's part of the VRRP standard. My guess is it was put in there to alert the NOC that it had failed over if a basic ping would fail.

[André Beck]

Hi Matt,

> I recommended this idea to someone else
> recently for another issue (which I can't
> remember the finer details of, something
> about a next hop failover).

Ah yep, I stumbled over several threads involving you explaining VRRP vs. VRRPe and such here in the forum.

> Anyway, sounded fine to me in theory. I
> don't know of anyone though that is using
> it in practice just yet.

If I get a chance, I'm going to try it. In the deployment I'm currently migrating, I'll stay with an owner, given the IP address plan is already implemented and based on XRRP's madness anyway. This may change should I actually hit one of those rumoured clashes of VRRP with OSPF, but that's unlikely - all my core routing is via dedicated quasi-PtP transit VLANs.

> Also with the backup does not respond to
> ICMP, that's part of the VRRP standard.

Thanks for prodding me to actually read the RFC finally instead of approximating its content from how VRRP is implemented by other vendors (the inventor of HSRP for instance, or the one hiding inside the 9xxx ProCurves). I stand corrected - HP implemented VRRP exactly like it is in the book. The "Owner" concept is from the very RFC, and that RFC doesn't even contemplate its issues. I would understand it as an additional feature (where you *can* do failover without any additional IP address in situations where they are tight), but the RFC deals with it as a fundamental concept. It doesn't talk a bit about owner-less operation, though it doesn't contradict it either - I'll have to try. Hopefully it will not flood PCM+ with a constant failure state event stream ;)

> My guess is it was put in there to alert
> the NOC that it had failed over if a basic
> ping would fail.

Actually they make it a habit to forbid *any* traffic to a non-owner master VIP from being anything but dropped. It must not be answered, and it must not be forwarded either (clause 8.4 could really be less opaque on why I would want to *forward* something addressed to one of my *local* addresses in the first place). Given the havoc XRRP regularly wreaks when management connections are suddenly hitting the wrong boxes, it makes full sense. It's just that it all wouldn't be necessary with a true VIP ;)

Thanks,
Andre.