[prev in list] [next in list] [prev in thread] [next in thread]
List: keepalived-devel
Subject: Re: [Keepalived-devel] VRRP owner routers - is priority asserted to max value?
From: barak adam <barak1adam () gmail ! com>
Date: 2017-02-18 5:53:45
Message-ID: CAAme7ok0Uf7D-a_ZzNcsTTOtS-AThAjaCMi0b+Ob_5rKkNawbQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
inline
On Fri, Feb 17, 2017 at 7:55 PM, Quentin Armitage <quentin@armitage.org.uk>
wrote:
> On Fri, 2017-02-17 at 18:11 +0200, barak adam wrote:
>
> On Thu, Feb 16, 2017 at 4:14 PM, Quentin Armitage <quentin@armitage.org.uk>
> 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
>
[Attachment #5 (text/html)]
<div dir="ltr"><span style="color:rgb(204,0,0)">inline</span><br><div><div \
class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 17, 2017 at 7:55 PM, \
Quentin Armitage <span dir="ltr"><<a href="mailto:quentin@armitage.org.uk" \
target="_blank">quentin@armitage.org.uk</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><u></u>
<div><span class="">
On Fri, 2017-02-17 at 18:11 +0200, barak adam wrote:
<br>
<br>
<blockquote type="CITE">
On Thu, Feb 16, 2017 at 4:14 PM, Quentin Armitage <<a \
href="mailto:quentin@armitage.org.uk" target="_blank">quentin@armitage.org.uk</a>> \
wrote: </blockquote>
<blockquote type="CITE">
<blockquote>
On Thu, 2017-02-16 at 09:26 +0200, barak adam wrote: <br>
<blockquote type="CITE">
Hi,<br>
<br>
<br>
I've got 2 questions about VRRP routers <b>ownership </b>handling \
in Keepalived:<br> <br>
<br>
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.<br> 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)."<br> <br>
1) Keepalived - it was possible for me to configure an owner VRRP router \
and assign it a value less then 255.<br> 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).<br> <br>
</blockquote>
What do you mean by <i>configure an owner VRRP router</i>? 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.<br> <br>
</blockquote>
</blockquote>
<blockquote type="CITE">
<br>
yes, that's what I mean by an owner. VIP = real IP exist on the interface. \
<br> </blockquote></span>
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.<span class=""> Anway I am ready to try again.<br> <blockquote \
type="CITE"><div> <span style="color:rgb(204,0,0)">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.</span> \
<br></div><span style="color:rgb(204,0,0)">(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...)</span><br></blockquote></span></div></blockquote><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div><span class=""><blockquote type="CITE"> \
</blockquote> <blockquote type="CITE">
<blockquote>
<blockquote type="CITE">
<br>
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?<br> <br>
</blockquote>
Yes, it is not a problem if no router has priority 255. The only problem is \
if more than one router has priority 255.<br> <br>
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.<br> <br>
</blockquote>
</blockquote>
<blockquote type="CITE">
<br>
<br>
</blockquote>
<blockquote type="CITE">
<br>
</blockquote>
<blockquote type="CITE">
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.<br> <br>
</blockquote>
<blockquote type="CITE">
(it is stated as "MUST" in RFC)<br>
</blockquote></span>
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).<span class=""> <br></span></div></blockquote><div><br><span \
style="color:rgb(204,0,0)">I added my comment above. </span><br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div><span class=""> <blockquote type="CITE">
<br>
<br>
</blockquote>
<blockquote type="CITE">
<blockquote>
<br>
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.<br> <br>
<blockquote type="CITE">
2) Should Keepalived update VRRP routers ownership automatically?<br>
<br>
<br>
For example:<br>
<br>
2.1) IP addition:<br>
Assuming a non-owner VRRP router is configured on a link.<br>
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.<br>
Would that router will be updated automatically with a priority value of \
255?<br> </blockquote>
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.<br> <br>
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.<br> <br>
</blockquote>
</blockquote>
<blockquote type="CITE">
<br>
<br>
</blockquote>
<blockquote type="CITE">
OK. got it. Since in VRRP advertisements priority is set one value for all VIPs, \
this really might be a problem. <br> <br>
</blockquote>
<blockquote type="CITE">
<blockquote>
<br>
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.<br> <br>
</blockquote>
</blockquote>
<blockquote type="CITE">
<br>
<br>
</blockquote>
<blockquote type="CITE">
Yes... <br>
<br>
</blockquote>
<blockquote type="CITE">
<blockquote>
<blockquote type="CITE">
<br>
2.2) IP deletion:<br>
Assuming an owner VRRP router is configured on a link.<br>
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.<br>
Would a priority value of 255 be released, in case it was previously \
asserted to 255 for ownership?<br> <br>
</blockquote>
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.<br> <br>
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.<br> <br>
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. <br> <br>
</blockquote>
</blockquote>
<blockquote type="CITE">
<br>
No I don't have. I just had been thinking if I have to handle it \
myself...<br> <br>
</blockquote>
<blockquote type="CITE">
<br>
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...<br> <br>
</blockquote>
<blockquote type="CITE">
<br>
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?<br> \
</blockquote></span> 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.<span \
class=""><br> <blockquote type="CITE">
<br>
</blockquote>
<blockquote type="CITE">
<br>
<br>
</blockquote>
<blockquote type="CITE">
<blockquote>
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.<br> <br>
</blockquote>
</blockquote>
<blockquote type="CITE">
<br>
<br>
</blockquote>
<blockquote type="CITE">
Another question about priority:<br>
=======================<br>
<br>
</blockquote>
<blockquote type="CITE">
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?<br> <br>
</blockquote>
<blockquote type="CITE">
I am just interested in monitoring the real priority value advertised by \
keepalived...<br> <br>
</blockquote></span>
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.<span class="HOEnZb"><font \
color="#888888"><br></font></span></div></blockquote><div><span \
style="color:rgb(204,0,0)">OK, thanks. First I will try SNMP to get the actual \
priority. Then we will consider adding it.. <br></span></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div><span class="HOEnZb"><font \
color="#888888"><span style="color:rgb(204,0,0)"> </span><br>
Quentin Armitage
<br>
</font></span></div>
</blockquote></div><br></div></div></div>
------------------------------------------------------------------------------
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
Keepalived-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/keepalived-devel
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic