Re: VRRP owner routers - is priority asserted to max value?

Hi,

Thanks a lot for the kindly answers.
I am sorry for the late response.

my comments are in-line your text.

Thanks
Barak

On Thu, Feb 16, 2017 at 4:14 PM, Quentin Armitage <[email protected]>
wrote:

> On Thu, 2017-02-16 at 09:26 +0200, barak adam wrote:
>
>  Hi,
>
>
>
> I've got 2 questions about VRRP routers *ownership *handling in
> Keepalived:
>
>
> According to the VRRP RFCs, an owner router must assert its priority to
> 255 in order to preemt and become the Master as soon as it is up.
> RFC 5798, section 5.2.4: "The priority value for the VRRP router that owns
> the IPvX address associated with the virtual router MUST be 255 (decimal)."
>
> 1) Keepalived - it was possible for me to configure an owner VRRP router
> and assign it a value less then 255.
> When the router was up, a priority value of 255 was not asserted
> automatically and it was not elected as a MASTER (of course preemption was
> enabled).
>
> What do you mean by *configure an owner VRRP router*? Do you mean that
> the VIP configured for the VRRP instance already existed on the interface?
> If so, that could cause all sorts of issues.
>

yes, that's what I mean by an owner. VIP = real IP exist on the interface.

>
> Is it OK to successfully load a configuration in which a VRRP owner router
> has a priority less then 255? Is it OK that priority value of 255 is not
> asserted on run-time for VRRP owners?
>
> Yes, it is not a problem if no router has priority 255. The only problem
> is if more than one router has priority 255.
>
> The issue of an address owner doesn't really apply to keepalived. A VRRP
> instance simply has a priority, and if that priority is 255, then the VRRP
> instance will act as though it is the address owner.
>

I agree. but I still think we should comply the RFC and assert a priority
value of 255 in case of our VRRP router is an owner.
(it is stated as "MUST" in RFC)

>
> The concept of address owner really applies where you have a physical
> "black box" router that is always running VRRP, and the address that VRRP
> is protecting is an address configured on an interface of that router. If
> that router is up, then it must be the master; if the router disappears
> then another (backup) router should take over that address.
>
> 2) Should Keepalived update VRRP routers ownership automatically?
>
>
> For example:
>
> 2.1) IP addition:
> Assuming a non-owner VRRP router is configured on a link.
> A new real IP is added on the link and this IP equals one of the
> VIPs assigned to the VRRP router on that link.
> Would that router will be updated automatically with a priority value of
> 255?
>
> keepalived doesn't handle dynamic changes of system or network
> configuration. When keepalived becomes master it adds the VIP addresses
> (and eVIPs) to the relevant interface(s), and when it transitions to backup
> it removes those addresses. It doesn't expect VIPs that it has configured
> to be added by another process.
>
> There could be a problem here if, for example, there were two VIPs
> configured in a VRRP instance, and one of those addresses were added to one
> router, and the other added to another router, since they would then both
> be updated to priority 255.
>

OK. got it. Since in VRRP advertisements priority is set one value for all
VIPs, this really might be a problem.

>
> Also, if a VRRP instance were already master, but running with a priority
> less than 255, it wouldn't be possible to add a VIP to a link, since it
> would already be configured.
>

Yes...

>
> 2.2) IP deletion:
> Assuming an owner VRRP router is configured on a link.
> A real IP which is the last one owned by a VRRP router is removed on a
> link and makes the router a NON owner router.
> Would a priority value of 255 be released, in case it was previously
> asserted to 255 for ownership?
>
>
> keepalived doesn't anticipate VIPs that it has added being removed, and it
> could cause problems since it would be advertising an address even though
> it didn't have it configured on a link. It could be argued that the address
> should no longer be advertised, but if the backup routers are checking the
> count of IP addresses and/or the addresses themselves, they would consider
> that there had been a misconfiguration.
>
> In fact, my thinking had been that if a VIP were removed by another
> process, then the VRRP instance should revert to backup mode (probably
> sending a priority 0 advert), and then if it became master again, it would
> re-add the VIPs.
>
> Do you have a use case for the IP addition and IP deletion scenarios? If
> so it would be helpful if you could describe it, and then perhaps a
> solution can be suggested.
>

No I don't have. I just had been thinking if I have to handle it myself...

Regarding IP additions - I now recall that in our routers - setting
multiple IPs on the same subnet are not allowed on the same physical link,
so I don't think I will get into a case where a new IP is added and equals
a running VIP...

Regarding VIP removal by another process - I agree, just a small question:
as far as I know priority 0 is used by the virtual router to get out of the
election game, means get into FAULT state and not BACKUP, and this is
already done by keepalived when the underlying interface is down or the VIP
is removed - isn't it?

You questions above raise some interesting thoughts, such as being able to
> dynamically change the priority of a VRRP instance. This could be done via
> SNMP or D-BUS, or even an api could be exposed to do it.
>

Another question about priority:
=======================
Using keepalived option of track-interface + weight: Is it possible to get
a notification (like calling any notification script as possible upon state
change) from keepalived when it is detecting that the tracked interface is
down and advertising a new priority value according to my weight setting?
I am just interested in monitoring the real priority value advertised by
keepalived...


>
> Quentin Armitage
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

_______________________________________________
Keepalived-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/keepalived-devel