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

On Fri, 2017-02-17 at 18:11 +0200, barak adam wrote:


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

I don't think this will work with keepalived. When it becomes master it
will attempt to add the VIPs to the interface, which in the case of an
IP address already existing will fail. However, when keepalived
terminates (or if it should become a backup), then it will remove the
VIPs, which will include the previously existing IP address.

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

I think the answer to this is to configure the priority in the config
file (but note comment above that using an IP address already configured
won't really work).

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

Priority 0 is used to notify other virtual routers that the current
master router is ceasing to operate. It then causes a faster re-election
process than if the router silently went away. keepalived will send a
priority 0 advert if it is shutting down or if a VRRP instance goes into
fault state.

> 
> 
> 
>         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...
> 
keepalived doesn't currently support this functionality, although it
would be possible to add it in if really needed. You should be able to
access the current priority using SNMP though.

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