[prev in list] [next in list] [prev in thread] [next in thread] 

List:       keepalived-devel
Subject:    Re: [Keepalived-devel] keepalived continuously forcing new election
From:       "Ryan O'Hara" <rohara () redhat ! com>
Date:       2012-04-09 17:02:21
Message-ID: 4F83161D.3060303 () redhat ! com
[Download RAW message or body]

Thanks for all the advice. Sorry for not replying sooner, but I was 
distracted by other issues. I thought it would be worthwhile to respond 
with my progress on this issue.

I was running the test on Fedora 16, which has a 3.x version kernel. I 
ran into some problem with the ipvs code in this kernel, so I ran the 
same test on RHEL6 using the same version of keepalived (v1.2.2) from 
EPEL. In this configuration I don't hit the problem with vrrp election. 
I cannot say definitely what is at fault, only report my observations.

Ryan

On 03/26/2012 01:47 AM, Tom van Leeuwen wrote:
> First step is to check whether packets really do arrive.
> If they do: check with "iptables -vnL INPUT" to see if there are any
> entries dropping/rejecting the VRRP packets.
>
> I'm not a fan of just doing stuff and crossing fingers to see if "it" is
> solved...
>
> Regards,
> Tom
>
> On 03/22/2012 12:22 PM, Paul Robert Marino wrote:
>>
>> Well fitrst I would flush iptables on both nodes iptables -F because
>> its the easiest to eliminate
>> On Mar 22, 2012 6:47 AM, "Tom van Leeuwen"
>> <tom.van.leeuwen@saasplaza.com <mailto:tom.van.leeuwen@saasplaza.com>>
>> wrote:
>> >
>> > I would stop keepalived on node A and start tcpdump on node A to see if
>> > both interfaces receive VRRP packets.
>> > Then the other way around to confirm this is not a networking issue.
>> >
>> > Regards,
>> > Tom
>> >
>> > On 03/22/2012 11:15 AM, Marco Corte wrote:
>> > > Hi.
>> > >
>> > > The configuration seems fine even if I would use a different
>> router_id
>> > > on each node.
>> > > I would also check if there is anything strange on the network,
>> such as
>> > > a duplicate MAC address.
>> > >
>> > > .marcoc
>> > >
>> > >
>> > >
>> ------------------------------------------------------------------------------
>>
>> > > This SF email is sponsosred by:
>> > > Try Windows Azure free for 90 days Click Here
>> > > http://p.sf.net/sfu/sfd2d-msazure
>> > > _______________________________________________
>> > > Keepalived-devel mailing list
>> > > Keepalived-devel@lists.sourceforge.net
>> <mailto:Keepalived-devel@lists.sourceforge.net>
>> > > https://lists.sourceforge.net/lists/listinfo/keepalived-devel
>> >
>> >
>> ------------------------------------------------------------------------------
>>
>> > This SF email is sponsosred by:
>> > Try Windows Azure free for 90 days Click Here
>> > http://p.sf.net/sfu/sfd2d-msazure
>> > _______________________________________________
>> > Keepalived-devel mailing list
>> > Keepalived-devel@lists.sourceforge.net
>> <mailto:Keepalived-devel@lists.sourceforge.net>
>> > https://lists.sourceforge.net/lists/listinfo/keepalived-devel
>>
>
>
>
> ------------------------------------------------------------------------------
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here
> http://p.sf.net/sfu/sfd2d-msazure
>
>
>
> _______________________________________________
> Keepalived-devel mailing list
> Keepalived-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/keepalived-devel


------------------------------------------------------------------------------
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
_______________________________________________
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]