Re: Keepalived-devel Digest, Vol 107, Issue 2

Alexandre Cassen <[email protected]>
Newsgroups gmane.linux.keepalived.devel
Message-ID <[email protected]> 
please provide feedback here tomorrow, otherwise I will revert this commit… which anyway seems strange reading the code, since it breaks some use-cases… VRRP FSM is very sensitive stuff, most of the time trying to optimise stuff is ending on breaking stuff :/ 

regs,
Alexandre


> On 17 Jun 2015, at 21:13, David Stapleton <[email protected]> wrote:
> 
> Hi Ryan,
> 
> I am also seeing this issue. I work with the person who's commit you suspect is the root cause (mlittlej-brcd) so I will speak to him about this tomorrow. Also, the person who signed off on the commit (cdochert) will be off work for a while, so please feel free to CC Anthony ([email protected] <mailto:[email protected]>) and myself ([email protected] <mailto:[email protected]>) on any other issues regarding keepalived.
> 
> In the meantime, there seems to be two workarounds to this problem. 1) Instead of setting each instance's initial state to master, when you set them to backup the issue is not observed. 2) If you add one instance at a time to the config and then do a reload, the issue doesn't seem to happen. Of course, this isn't very practical, especially if you want to configure multiple groups on the one interface.
> 
> Once again, I'll have a chat with mlittlej tomorrow and will let you know what he says.
> 
> Thanks,
> David
> 
> On 17 June 2015 at 17:39, <[email protected] <mailto:[email protected]>> wrote:
> Send Keepalived-devel mailing list submissions to
>         [email protected] <mailto:[email protected]>
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.sourceforge.net/lists/listinfo/keepalived-devel <https://lists.sourceforge.net/lists/listinfo/keepalived-devel>
> or, via email, send a message with subject or body 'help' to
>         [email protected] <mailto:[email protected]>
> 
> You can reach the person managing the list at
>         [email protected] <mailto:[email protected]>
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Keepalived-devel digest..."
> 
> 
> Today's Topics:
> 
>    1. [acassen/keepalived] d80c17: Fix vrrp removes incorrect IPv4
>       address when VIPs ... (Alexandre Cassen)
>    2. Multiple VRRP instances with 1.2.17 (Ryan O'Hara)
>    3. Re: Multiple VRRP instances with 1.2.17 (Ryan O'Hara)
>    4. Re: Multiple VRRP instances with 1.2.17 (Ryan O'Hara)
>    5. Re: Multiple VRRP instances with 1.2.17 (Alexandre Cassen)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Tue, 16 Jun 2015 03:00:37 -0700
> From: Alexandre Cassen <[email protected] <mailto:[email protected]>>
> Subject: [Keepalived-devel] [acassen/keepalived] d80c17: Fix vrrp
>         removes incorrect IPv4 address when VIPs ...
> To: [email protected] <mailto:[email protected]>
> Message-ID:
>         <557ff3c5d85cb_6ec3fea9710d29c1002b0@hookshot-fe5-cp1-prd.iad.github.net.mail>
> 
> Content-Type: text/plain; charset="utf-8"
> 
>   Branch: refs/heads/master
>   Home:   https://github.com/acassen/keepalived <https://github.com/acassen/keepalived>
>   Commit: d80c171e7e8fe7fb4e0878a15027ac80c23b0a14
>       https://github.com/acassen/keepalived/commit/d80c171e7e8fe7fb4e0878a15027ac80c23b0a14 <https://github.com/acassen/keepalived/commit/d80c171e7e8fe7fb4e0878a15027ac80c23b0a14>
>   Author: David Stapleton <[email protected] <mailto:[email protected]>>
>   Date:   2015-06-15 (Mon, 15 Jun 2015)
> 
>   Changed paths:
>     M keepalived/vrrp/vrrp_ipaddress.c
> 
>   Log Message:
>   -----------
>   Fix vrrp removes incorrect IPv4 address when VIPs are removed
> 
> When vrrp has an IPv4 VIP that matches the primary interface
> address, when the VIP is removed from the interface, the original
> address ends up getting removed instead of the VIP.
> 
> The kernel receives a netlink message instructing it to remove
> address x from a particular interface. For IPv4, address x can
> be configured multiple times providing the prefix lengths differ.
> If the IFA_ADDRESS attribute is not specified in a RTM_DELADDR
> message, the kernel will delete the first address it finds a
> match on, prefix length is not taken into account.
> 
> This fix therefore adds the IFA_ADDRESS attribute when deleting
> IPv4 addresses so that the address removed is actually the VIP.
> 
> 
>   Commit: e104ba5b5b576eb624db69605ab0ecfacbf45857
>       https://github.com/acassen/keepalived/commit/e104ba5b5b576eb624db69605ab0ecfacbf45857 <https://github.com/acassen/keepalived/commit/e104ba5b5b576eb624db69605ab0ecfacbf45857>
>   Author: Alexandre Cassen <[email protected] <mailto:[email protected]>>
>   Date:   2015-06-16 (Tue, 16 Jun 2015)
> 
>   Changed paths:
>     M keepalived/vrrp/vrrp_ipaddress.c
> 
>   Log Message:
>   -----------
>   Merge pull request #155 from DStape/fix-vrrp-removes-primary-addr
> 
> Fix vrrp removes incorrect IPv4 address when VIPs are removed
> 
> 
> Compare: https://github.com/acassen/keepalived/compare/18ee593dac25...e104ba5b5b57 <https://github.com/acassen/keepalived/compare/18ee593dac25...e104ba5b5b57>
> 
> ------------------------------
> 
> Message: 2
> Date: Tue, 16 Jun 2015 14:15:21 -0500
> From: "Ryan O'Hara" <[email protected] <mailto:[email protected]>>
> Subject: [Keepalived-devel] Multiple VRRP instances with 1.2.17
> To: [email protected] <mailto:[email protected]>
> Message-ID: <[email protected] <mailto:[email protected]>>
> Content-Type: text/plain; charset=us-ascii
> 
> 
> I was informed today about a problem with keepalived 1.2.17 when using
> multiple VRRP instances [1]. Consider the following keepalived.conf:
> 
> vrrp_instance VRRP_51 {
>     virtual_router_id 51
>     advert_int 1
>     priority 101
>     state MASTER
>     interface eth0
> 
>     virtual_ipaddress {
>         192.168.1.1
>     }
> }
> 
> vrrp_instance VRRP_52 {
>     virtual_router_id 52
>     advert_int 1
>     priority 101
>     state MASTER
>     interface eth0
> 
>     virtual_ipaddress {
>         192.168.1.2
>     }
> }
> 
> Note that both instances use the same interface but have unique VRIDs
> and VIPs. This works in 1.2.16 and earlier, but in 1.2.17 only the
> first VIP is added to the interface. There are no other nodes running
> keepalived.
> 
> Any ideas on what changed? I've been digging through the code for a
> while now and have no found the change that caused this
> regression. Both instances get parsed correct as evidence of the
> configuration dump (-d option).
> 
> Ryan
> 
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1232408 <https://bugzilla.redhat.com/show_bug.cgi?id=1232408>
> 
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Tue, 16 Jun 2015 14:21:12 -0500
> From: "Ryan O'Hara" <[email protected] <mailto:[email protected]>>
> Subject: Re: [Keepalived-devel] Multiple VRRP instances with 1.2.17
> To: [email protected] <mailto:[email protected]>
> Message-ID: <[email protected] <mailto:[email protected]>>
> Content-Type: text/plain; charset=us-ascii
> 
> On Tue, Jun 16, 2015 at 02:15:21PM -0500, Ryan O'Hara wrote:
> >
> > I was informed today about a problem with keepalived 1.2.17 when using
> > multiple VRRP instances [1]. Consider the following keepalived.conf:
> >
> > vrrp_instance VRRP_51 {
> >     virtual_router_id 51
> >     advert_int 1
> >     priority 101
> >     state MASTER
> >     interface eth0
> >
> >     virtual_ipaddress {
> >         192.168.1.1
> >     }
> > }
> >
> > vrrp_instance VRRP_52 {
> >     virtual_router_id 52
> >     advert_int 1
> >     priority 101
> >     state MASTER
> >     interface eth0
> >
> >     virtual_ipaddress {
> >         192.168.1.2
> >     }
> > }
> >
> > Note that both instances use the same interface but have unique VRIDs
> > and VIPs. This works in 1.2.16 and earlier, but in 1.2.17 only the
> > first VIP is added to the interface. There are no other nodes running
> > keepalived.
> 
> Sorry, I was mistaken. Only the second VIP (192.168.1.2) is added to
> the interface:
> 
> VRRP_Instance(VRRP_52) Transition to MASTER STATE
> VRRP_Instance(VRRP_52) Entering MASTER STATE
> VRRP_Instance(VRRP_52) setting protocol VIPs.
> VRRP_Instance(VRRP_52) Sending gratuitous ARPs on eth0 for 192.168.1.2
> 
> There is nothing at all in the logs about VRRP instance "VRRP_51".
> 
> Ryan
> 
> 
> > Any ideas on what changed? I've been digging through the code for a
> > while now and have no found the change that caused this
> > regression. Both instances get parsed correct as evidence of the
> > configuration dump (-d option).
> >
> > Ryan
> >
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1232408 <https://bugzilla.redhat.com/show_bug.cgi?id=1232408>
> >
> >
> > ------------------------------------------------------------------------------
> > _______________________________________________
> > Keepalived-devel mailing list
> > [email protected] <mailto:[email protected]>
> > https://lists.sourceforge.net/lists/listinfo/keepalived-devel <https://lists.sourceforge.net/lists/listinfo/keepalived-devel>
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Wed, 17 Jun 2015 11:03:44 -0500
> From: "Ryan O'Hara" <[email protected] <mailto:[email protected]>>
> Subject: Re: [Keepalived-devel] Multiple VRRP instances with 1.2.17
> To: [email protected] <mailto:[email protected]>
> Cc: [email protected] <mailto:[email protected]>
> Message-ID: <[email protected] <mailto:[email protected]>>
> Content-Type: text/plain; charset=us-ascii
> 
> On Tue, Jun 16, 2015 at 02:21:12PM -0500, Ryan O'Hara wrote:
> > On Tue, Jun 16, 2015 at 02:15:21PM -0500, Ryan O'Hara wrote:
> > >
> > > I was informed today about a problem with keepalived 1.2.17 when using
> > > multiple VRRP instances [1]. Consider the following keepalived.conf:
> > >
> > > vrrp_instance VRRP_51 {
> > >     virtual_router_id 51
> > >     advert_int 1
> > >     priority 101
> > >     state MASTER
> > >     interface eth0
> > >
> > >     virtual_ipaddress {
> > >         192.168.1.1
> > >     }
> > > }
> > >
> > > vrrp_instance VRRP_52 {
> > >     virtual_router_id 52
> > >     advert_int 1
> > >     priority 101
> > >     state MASTER
> > >     interface eth0
> > >
> > >     virtual_ipaddress {
> > >         192.168.1.2
> > >     }
> > > }
> > >
> > > Note that both instances use the same interface but have unique VRIDs
> > > and VIPs. This works in 1.2.16 and earlier, but in 1.2.17 only the
> > > first VIP is added to the interface. There are no other nodes running
> > > keepalived.
> >
> > Sorry, I was mistaken. Only the second VIP (192.168.1.2) is added to
> > the interface:
> >
> > VRRP_Instance(VRRP_52) Transition to MASTER STATE
> > VRRP_Instance(VRRP_52) Entering MASTER STATE
> > VRRP_Instance(VRRP_52) setting protocol VIPs.
> > VRRP_Instance(VRRP_52) Sending gratuitous ARPs on eth0 for 192.168.1.2
> >
> > There is nothing at all in the logs about VRRP instance "VRRP_51".
> 
> I found the commit that causes this regression.
> 
> https://github.com/acassen/keepalived/commit/76f9ce36ae389983b48a83a933182739786908c9 <https://github.com/acassen/keepalived/commit/76f9ce36ae389983b48a83a933182739786908c9>
> 
> Specifically the changes to vrrp_init_instance_sands in
> vrrp_sync.c. Reverting the code in this function fixes the problems,
> but I'm not yet sure why.
> 
> Ryan
> 
> > > Any ideas on what changed? I've been digging through the code for a
> > > while now and have no found the change that caused this
> > > regression. Both instances get parsed correct as evidence of the
> > > configuration dump (-d option).
> > >
> > > Ryan
> > >
> > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1232408 <https://bugzilla.redhat.com/show_bug.cgi?id=1232408>
> > >
> > >
> > > ------------------------------------------------------------------------------
> > > _______________________________________________
> > > Keepalived-devel mailing list
> > > [email protected] <mailto:[email protected]>
> > > https://lists.sourceforge.net/lists/listinfo/keepalived-devel <https://lists.sourceforge.net/lists/listinfo/keepalived-devel>
> >
> > ------------------------------------------------------------------------------
> > _______________________________________________
> > Keepalived-devel mailing list
> > [email protected] <mailto:[email protected]>
> > https://lists.sourceforge.net/lists/listinfo/keepalived-devel <https://lists.sourceforge.net/lists/listinfo/keepalived-devel>
> 
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Wed, 17 Jun 2015 18:39:35 +0200
> From: Alexandre Cassen <[email protected] <mailto:[email protected]>>
> Subject: Re: [Keepalived-devel] Multiple VRRP instances with 1.2.17
> To: "Ryan O'Hara" <[email protected] <mailto:[email protected]>>
> Cc: [email protected] <mailto:[email protected]>, "[email protected] <mailto:[email protected]>"
>         <[email protected] <mailto:[email protected]>>
> Message-ID:
>         <CAONz4a2Txxa=xceAroVUZ0KYP9KLvCXuzN1DMhpj8tMFHJr_Jw@mail.gmail.com <mailto:[email protected]>>
> Content-Type: text/plain; charset="utf-8"
> 
> Agreed, this patch need to be reverted... but your runing different VRID
> which is not related to preempt... will have a look at that... thanks for
> reporting...
> 
> regs,
> Alexandre
> 
> On Wed, Jun 17, 2015 at 6:03 PM, Ryan O'Hara <[email protected] <mailto:[email protected]>> wrote:
> 
> > On Tue, Jun 16, 2015 at 02:21:12PM -0500, Ryan O'Hara wrote:
> > > On Tue, Jun 16, 2015 at 02:15:21PM -0500, Ryan O'Hara wrote:
> > > >
> > > > I was informed today about a problem with keepalived 1.2.17 when using
> > > > multiple VRRP instances [1]. Consider the following keepalived.conf:
> > > >
> > > > vrrp_instance VRRP_51 {
> > > >     virtual_router_id 51
> > > >     advert_int 1
> > > >     priority 101
> > > >     state MASTER
> > > >     interface eth0
> > > >
> > > >     virtual_ipaddress {
> > > >         192.168.1.1
> > > >     }
> > > > }
> > > >
> > > > vrrp_instance VRRP_52 {
> > > >     virtual_router_id 52
> > > >     advert_int 1
> > > >     priority 101
> > > >     state MASTER
> > > >     interface eth0
> > > >
> > > >     virtual_ipaddress {
> > > >         192.168.1.2
> > > >     }
> > > > }
> > > >
> > > > Note that both instances use the same interface but have unique VRIDs
> > > > and VIPs. This works in 1.2.16 and earlier, but in 1.2.17 only the
> > > > first VIP is added to the interface. There are no other nodes running
> > > > keepalived.
> > >
> > > Sorry, I was mistaken. Only the second VIP (192.168.1.2) is added to
> > > the interface:
> > >
> > > VRRP_Instance(VRRP_52) Transition to MASTER STATE
> > > VRRP_Instance(VRRP_52) Entering MASTER STATE
> > > VRRP_Instance(VRRP_52) setting protocol VIPs.
> > > VRRP_Instance(VRRP_52) Sending gratuitous ARPs on eth0 for 192.168.1.2
> > >
> > > There is nothing at all in the logs about VRRP instance "VRRP_51".
> >
> > I found the commit that causes this regression.
> >
> >
> > https://github.com/acassen/keepalived/commit/76f9ce36ae389983b48a83a933182739786908c9 <https://github.com/acassen/keepalived/commit/76f9ce36ae389983b48a83a933182739786908c9>
> >
> > Specifically the changes to vrrp_init_instance_sands in
> > vrrp_sync.c. Reverting the code in this function fixes the problems,
> > but I'm not yet sure why.
> >
> > Ryan
> >
> > > > Any ideas on what changed? I've been digging through the code for a
> > > > while now and have no found the change that caused this
> > > > regression. Both instances get parsed correct as evidence of the
> > > > configuration dump (-d option).
> > > >
> > > > Ryan
> > > >
> > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1232408 <https://bugzilla.redhat.com/show_bug.cgi?id=1232408>
> > > >
> > > >
> > > >
> > ------------------------------------------------------------------------------
> > > > _______________________________________________
> > > > Keepalived-devel mailing list
> > > > [email protected] <mailto:[email protected]>
> > > > https://lists.sourceforge.net/lists/listinfo/keepalived-devel <https://lists.sourceforge.net/lists/listinfo/keepalived-devel>
> > >
> > >
> > ------------------------------------------------------------------------------
> > > _______________________________________________
> > > Keepalived-devel mailing list
> > > [email protected] <mailto:[email protected]>
> > > https://lists.sourceforge.net/lists/listinfo/keepalived-devel <https://lists.sourceforge.net/lists/listinfo/keepalived-devel>
> >
> >
> > ------------------------------------------------------------------------------
> > _______________________________________________
> > Keepalived-devel mailing list
> > [email protected] <mailto:[email protected]>
> > https://lists.sourceforge.net/lists/listinfo/keepalived-devel <https://lists.sourceforge.net/lists/listinfo/keepalived-devel>
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> 
> ------------------------------
> 
> ------------------------------------------------------------------------------
> 
> 
> ------------------------------
> 
> _______________________________________________
> Keepalived-devel mailing list
> [email protected] <mailto:[email protected]>
> https://lists.sourceforge.net/lists/listinfo/keepalived-devel <https://lists.sourceforge.net/lists/listinfo/keepalived-devel>
> 
> 
> End of Keepalived-devel Digest, Vol 107, Issue 2
> ************************************************
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Keepalived-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/keepalived-devel

------------------------------------------------------------------------------

_______________________________________________
Keepalived-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/keepalived-devel
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.