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

inline

On Fri, Feb 17, 2017 at 7:55 PM, Quentin Armitage <[email protected]>
wrote:

> 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. Anway I am ready to try again.
>
> I think it's not exactly what happens. I've sent my question after
> successfully trying to configure a VIP which equals an existing IP on the
> interface. I think a new network interface is always created by keepalived
> based on the virtual MAC and then a VIP is added or removed to/from this
> new interface when entering or leaving master state respectively.
> (if you type "ifconfig -a" you will see 2 interfaces with the same IP, one
> real interface based on the real MAC and the other is virtual (vrrp.x) and
> is based on the virtual MAC...)
>
>
> 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).
>

I added my comment above.

>
>
>
> 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.
>
OK, thanks. First I will try SNMP to get the actual priority. Then we will
consider adding 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