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

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.

> 
> 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.

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.

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.

> 
> 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.

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.

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