<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://permalink.gmane.org/gmane.linux.keepalived.devel">
    <title>gmane.linux.keepalived.devel</title>
    <link>http://permalink.gmane.org/gmane.linux.keepalived.devel</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.keepalived.devel/3871"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.keepalived.devel/3870"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.keepalived.devel/3869"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.keepalived.devel/3868"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.keepalived.devel/3867"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.keepalived.devel/3866"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.keepalived.devel/3865"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.keepalived.devel/3864"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.keepalived.devel/3863"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.keepalived.devel/3862"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.keepalived.devel/3861"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.keepalived.devel/3860"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.keepalived.devel/3859"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.keepalived.devel/3858"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.keepalived.devel/3857"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.keepalived.devel/3856"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.keepalived.devel/3855"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.keepalived.devel/3854"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.keepalived.devel/3853"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.linux.keepalived.devel/3852"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.keepalived.devel/3871">
    <title>Re: Dynamic change to keepalived.conf?</title>
    <link>http://permalink.gmane.org/gmane.linux.keepalived.devel/3871</link>
    <description>&lt;pre&gt;One thing to be aware of with this particular type of issue is there are numerous possible causes - and they are almost always outside of the keepalived code/application itself. But rather, something misbehaving in the network stack or topology - e.g. firewall rules, packet loss, inter switch link failure, 100% CPU utilization, etc.

-T

On May 25, 2012, at 7:45 AM, Ryan O'Hara wrote:



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>Todd Fleisher</dc:creator>
    <dc:date>2012-05-25T16:52:09</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.keepalived.devel/3870">
    <title>Re: Fw:  Dynamic change to keepalived.conf?</title>
    <link>http://permalink.gmane.org/gmane.linux.keepalived.devel/3870</link>
    <description>&lt;pre&gt;For your first question, you don't need to restart keepalived, but rather reload (SIGHUP) it to change its configuration.

Sent from the fleishpad

On May 25, 2012, at 5:50, lakshmi priya &amp;lt;pri_wip06&amp;lt; at &amp;gt;yahoo.co.in&amp;gt; wrote:

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
Keepalived-devel mailing list
Keepalived-devel&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/keepalived-devel
&lt;/pre&gt;</description>
    <dc:creator>Todd Fleisher</dc:creator>
    <dc:date>2012-05-25T16:22:18</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.keepalived.devel/3869">
    <title>Re: Dynamic change to keepalived.conf?</title>
    <link>http://permalink.gmane.org/gmane.linux.keepalived.devel/3869</link>
    <description>&lt;pre&gt;

This seems the be the same issue I reported here:

http://marc.info/?l=keepalived-devel&amp;amp;m=133234586317562&amp;amp;w=2

Ryan




------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>Ryan O'Hara</dc:creator>
    <dc:date>2012-05-25T14:45:58</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.keepalived.devel/3868">
    <title>Re: Fw:  Dynamic change to keepalived.conf?</title>
    <link>http://permalink.gmane.org/gmane.linux.keepalived.devel/3868</link>
    <description>&lt;pre&gt;Hi,
 
I am facing the issue again, when I try different configurations. 2 Instance in each server with one in MASTER state and other in BACKUP state. Just the reverse in second server.
 
Server1
 
vrrp_instance VI_1 {
        interface eth1
        state MASTER
        virtual_router_id 61
        priority 101
        advert_int 1
        virtual_ipaddress {
                2.0.0.11/24 dev eth1
                2.0.0.12/24 dev eth1
        }
}
vrrp_instance VI_2 {
        interface eth1
        state BACKUP
        virtual_router_id 62
        priority 100
        advert_int 1
        virtual_ipaddress {
                2.0.0.13/24 dev eth1
                2.0.0.14/24 dev eth1
        }
}
 
Server2
 
vrrp_instance VI_1 {
    interface eth1
    state BACKUP
    virtual_router_id 61
    priority 100
    advert_int 1
    virtual_ipad&lt;/pre&gt;</description>
    <dc:creator>lakshmi priya</dc:creator>
    <dc:date>2012-05-25T12:50:18</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.keepalived.devel/3867">
    <title>Fw:  Dynamic change to keepalived.conf?</title>
    <link>http://permalink.gmane.org/gmane.linux.keepalived.devel/3867</link>
    <description>&lt;pre&gt;Hi Pau,
 
Thank you for the reply. Now I tried to install keepalived in different machines and its working fine now. I didn't face this issue again. 
But still I would like to know a solution to this issue, as I might come across it in future.
 
In current enviroment (where I dont find this issue), output of netstat -g is
 
#netstat -g
IPv6/IPv4 Group Memberships
Interface       RefCnt Group
--------------- ------ ---------------------
lo              1      all-systems.mcast.net
eth0            1      all-systems.mcast.net
eth1            1      vrrp.mcast.net
eth1            1      all-systems.mcast.net
lo              1      ff02::1
eth0            1      ff02::202
eth0            1      ff02::1:ff0b:393
eth0            1      ff02::1
eth1            1      ff02::202
eth1            1      ff02::1:ff0b:394
eth1            1&lt;/pre&gt;</description>
    <dc:creator>lakshmi priya</dc:creator>
    <dc:date>2012-05-25T11:30:30</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.keepalived.devel/3866">
    <title>Re: Dynamic change to keepalived.conf?</title>
    <link>http://permalink.gmane.org/gmane.linux.keepalived.devel/3866</link>
    <description>&lt;pre&gt;Hi,

Multicast communication is working between the two nodes?
check it using "netstat -g" and look for vrrp.mcast.net
also check witch tcpdump.

Depending on the switch configuration, multicast can be blocked. (IGMP
snooping)

Pau Seglar--






















--



2012/5/25 lakshmi priya &amp;lt;pri_wip06&amp;lt; at &amp;gt;yahoo.co.in&amp;gt;

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
Keepalived-devel mailing list
Keepalived-devel&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/keepalived-devel
&lt;/pre&gt;</description>
    <dc:creator>Pau Seglar</dc:creator>
    <dc:date>2012-05-25T10:03:22</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.keepalived.devel/3865">
    <title>Dynamic change to keepalived.conf?</title>
    <link>http://permalink.gmane.org/gmane.linux.keepalived.devel/3865</link>
    <description>&lt;pre&gt;Hi all,
 
I am new to keepalived code. So it would be great if someone could help me. 
I have a couple of questions .

1) Is there a way for dynamic configuration of Virtual Ip addresses ie) Adding a new virtual IP address to existing instance (or) new vrrp_instance with new set of virtual Ip addresses and bringing it into effect without restarting keepalived application.

2) My setup is working as expected, Initially vrrp_instance1 comes up in MASTER state in server1, and BACKUP state in server2 . The states are maintained since priority of instance in server2 is lesser.
But after some time, I can see below messages in server1. Now both server1 and server2 owns the IP addresses. I searched through internet on this issue. Some of them have faced same problem, but I didn't get a proper solution to this.

May 24 18:29:59 TPC-BA3-26H Keepalived_vrrp: VRRP_Instance(VI_1) Received lower prio advert, forcing new election
May 24 18:29:59 TPC-BA3-26H Keepalived_vrrp: VRRP_Instance(VI_1) Sending gratuitous ARP&lt;/pre&gt;</description>
    <dc:creator>lakshmi priya</dc:creator>
    <dc:date>2012-05-25T09:17:32</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.keepalived.devel/3864">
    <title>Re: Both keepalived servers comes up in MASTERstate</title>
    <link>http://permalink.gmane.org/gmane.linux.keepalived.devel/3864</link>
    <description>&lt;pre&gt;Yes, that should solve some of the issues. 
Thank you for the suggestion.
 
I have a couple of questions here.
 
1) Is there a way for dynamic configuration of Virtual Ip addresses ie) Adding a new virtual IP address to existing instance (or) new vrrp_instance with new set of virtual Ip addresses and bringing it into effect without restarting keepalived application.
 
2) My setup is working as expected, Initially vrrp instance in server1 comes up in MASTER state, server2 in BACKUP state and states are maintained since priority of instance in server2 is lesser.
But after some time, I can see below messages in server1. Now both server1 and server2 owns the IP addresses. 
 
May 24 18:29:59 TPC-BA3-26H Keepalived_vrrp: VRRP_Instance(VI_1) Received lower prio advert, forcing new election
May 24 18:29:59 TPC-BA3-26H Keepalived_vrrp: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth1 for 2.0.0.1
May 24 18:29:59 TPC-BA3-26H Keepalived_vrrp: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth1 for 4.0.0.1
May &lt;/pre&gt;</description>
    <dc:creator>lakshmi priya</dc:creator>
    <dc:date>2012-05-25T06:57:29</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.keepalived.devel/3863">
    <title>Re: Backup takeover delay</title>
    <link>http://permalink.gmane.org/gmane.linux.keepalived.devel/3863</link>
    <description>&lt;pre&gt;

Ugh, I see that now. Thanks. That seems ok in an environment


I see that VRRPv3 has Master_Adver_Interval that is used to calculate
the Master_Down_Interval (and skew). Assuming Master_Adver_Interval is
configurable, this looks like a way to control the down interval.
Would be nice to have.

-Brad

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>Brad Schick</dc:creator>
    <dc:date>2012-05-24T18:02:32</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.keepalived.devel/3862">
    <title>Re: Backup takeover delay</title>
    <link>http://permalink.gmane.org/gmane.linux.keepalived.devel/3862</link>
    <description>&lt;pre&gt;No, that is part of the VRRP standard.

However, in VRRPv3 there is support for sub-second (0.1, 0.2, 0.3 sec)
resolution in the interval timer. I know there is support for that
brewing already, and we also have an implementation of our own at
Westermo we could share if there is interest.

Regards
 /Joachim

On Thu, May 24, 2012 at 6:41 PM, Brad Schick &amp;lt;schickb&amp;lt; at &amp;gt;gmail.com&amp;gt; wrote:

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>Joachim Nilsson</dc:creator>
    <dc:date>2012-05-24T16:46:34</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.keepalived.devel/3861">
    <title>Backup takeover delay</title>
    <link>http://permalink.gmane.org/gmane.linux.keepalived.devel/3861</link>
    <description>&lt;pre&gt;Is there a way to control the number of missed adverts that will cause a
backup to transition to a master? I've looked through the source a bit, and
it looks like it may be hardcoded to 3 * advert plus a skew, but I didn't
study the code enough to be sure.

Is that correct? Is there a way to control the number of missed adverts the
causes a backup to transition to a master?

-Brad
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
Keepalived-devel mailing list
Keepalived-devel&amp;lt; at &amp;gt;lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/keepalived-devel
&lt;/pre&gt;</description>
    <dc:creator>Brad Schick</dc:creator>
    <dc:date>2012-05-24T16:41:30</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.keepalived.devel/3860">
    <title>Re: Both keepalived servers comes up in MASTERstate</title>
    <link>http://permalink.gmane.org/gmane.linux.keepalived.devel/3860</link>
    <description>&lt;pre&gt;Hi,

I found that it is always best if possible to turn off the firewall and see if it works,
then turn on the firewall.

On 05/24/2012 08:16 AM, lakshmi priya wrote:


&lt;/pre&gt;</description>
    <dc:creator>Steve Clark</dc:creator>
    <dc:date>2012-05-24T12:35:41</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.keepalived.devel/3859">
    <title>Re: Both keepalived servers comes up in MASTERstate</title>
    <link>http://permalink.gmane.org/gmane.linux.keepalived.devel/3859</link>
    <description>&lt;pre&gt;Hi Graeme,
 
Sorry. The order of iptables rule was wrong. I corrected it and its working fine now. I was debugging this issue for past two days.
Thank you again for your help 
 
 
 
 
 

________________________________
From: lakshmi priya &amp;lt;pri_wip06&amp;lt; at &amp;gt;yahoo.co.in&amp;gt;
To: Graeme Fowler &amp;lt;graeme&amp;lt; at &amp;gt;graemef.net&amp;gt;; "keepalived-devel&amp;lt; at &amp;gt;lists.sourceforge.net" &amp;lt;keepalived-devel&amp;lt; at &amp;gt;lists.sourceforge.net&amp;gt; 
Sent: Thursday, 24 May 2012 5:18 PM
Subject: Re: [Keepalived-devel] Both keepalived servers comes up in MASTER state


Hi Graeme,
 
Thank you very much for your immediate reply.
 
I added iptables rule and below is the output of "iptables -L". But still I am facing same issue. Server2 starts up in BACKUP and immediately moves to MASTER state.

Server1
 
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:tcl-slave
ACCEPT     tcp  --  anywhere             anywh&lt;/pre&gt;</description>
    <dc:creator>lakshmi priya</dc:creator>
    <dc:date>2012-05-24T12:16:59</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.keepalived.devel/3858">
    <title>Re: Both keepalived servers comes up in MASTERstate</title>
    <link>http://permalink.gmane.org/gmane.linux.keepalived.devel/3858</link>
    <description>&lt;pre&gt;Hi Tobias,
 
Thank you very much for the reply. 
I tried  changing the priority to 150 on server1 and 100 on server2. Still it doesn't work.
 
 


________________________________
From: Tobias Dinse &amp;lt;tobias.dinse&amp;lt; at &amp;gt;stegbauer.info&amp;gt;
To: lakshmi priya &amp;lt;pri_wip06&amp;lt; at &amp;gt;yahoo.co.in&amp;gt; 
Sent: Thursday, 24 May 2012 4:16 PM
Subject: Re: [Keepalived-devel] Both keepalived servers comes up in MASTER state


Hi,

I took a look on the manpage. Master server must have an priority 50 higher than the backup Server. You can try that.


Am 24.05.2012 12:19, schrieb lakshmi priya: 
Hi all,


&lt;/pre&gt;</description>
    <dc:creator>lakshmi priya</dc:creator>
    <dc:date>2012-05-24T11:53:31</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.keepalived.devel/3857">
    <title>Re: Both keepalived servers comes up in MASTERstate</title>
    <link>http://permalink.gmane.org/gmane.linux.keepalived.devel/3857</link>
    <description>&lt;pre&gt;Hi Graeme,
 
Thank you very much for your immediate reply.
 
I added iptables rule and below is the output of "iptables -L". But still I am facing same issue. Server2 starts up in BACKUP and immediately moves to MASTER state.

Server1
 
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:tcl-slave
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:tcl-slave-nothread
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:tcl-known-slave
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
ACCEPT     icmp --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     tcp  --  anywhere             anywhere            stat&lt;/pre&gt;</description>
    <dc:creator>lakshmi priya</dc:creator>
    <dc:date>2012-05-24T11:48:54</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.keepalived.devel/3856">
    <title>Re: Both keepalived servers comes up in MASTER state</title>
    <link>http://permalink.gmane.org/gmane.linux.keepalived.devel/3856</link>
    <description>&lt;pre&gt;Hi Lakshmi

Please make sure you reply to the list!

On Thu, 2012-05-24 at 19:43 +0800, lakshmi priya wrote:
 

That because you ADDED (-A) the accept rule rather than INSERTing (-I).
If you did this in /etc/sysconfig/iptables (or your distribution's local
variant), make sure your ACCEPT line is before the default REJECT at the
end of the INPUT chain.

Regards

Graeme



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>Graeme Fowler</dc:creator>
    <dc:date>2012-05-24T11:47:06</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.keepalived.devel/3855">
    <title>Re: Both keepalived servers comes up in MASTER state</title>
    <link>http://permalink.gmane.org/gmane.linux.keepalived.devel/3855</link>
    <description>&lt;pre&gt;
Ensure both of your servers have an iptables rule to permit VRRP traffic
inbound.

Graeme


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
&lt;/pre&gt;</description>
    <dc:creator>Graeme Fowler</dc:creator>
    <dc:date>2012-05-24T11:00:06</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.keepalived.devel/3854">
    <title>Both keepalived servers comes up in MASTER state</title>
    <link>http://permalink.gmane.org/gmane.linux.keepalived.devel/3854</link>
    <description>&lt;pre&gt;Hi all,


Sorry for the spam. But I dont find any other way to get this resolved. I searched a lot through internet, but couldnt find a solution.

I am using keepalived(version 1.2.2) to manage failover between 2 linux servers. And my configuration on the servers is shown below.

! Configuration File for keepalived (server1)
vrrp_instance VI_1 {
        interface eth1
        state MASTER
        virtual_router_id 61
        priority 101
        advert_int 1
        virtual_ipaddress {
                2.0.0.1/24 dev eth1
                4.0.0.1/24 dev eth1
        }
}
 
! Configuration File for keepalived (server2)
vrrp_instance VI_1 {
    interface eth1
    state BACKUP
    virtual_router_id 61
    priority 100
    advert_int 1
    virtual_ipaddress {
        2.0.0.1/24 dev eth1
        4.0.0.1/24 dev eth1
    }
}
 
Once I start keepalived on both the servers, VI_1 is supposed to be in MASTER &lt;/pre&gt;</description>
    <dc:creator>lakshmi priya</dc:creator>
    <dc:date>2012-05-24T10:19:23</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.keepalived.devel/3853">
    <title>curiouse state switch</title>
    <link>http://permalink.gmane.org/gmane.linux.keepalived.devel/3853</link>
    <description>&lt;pre&gt;Hi,

sry for posting in the developement Mailing List. I hope that its ok. I 
have a realy strange Problem with our 2 Firewalls which runs under 
Debian Squeeze x64 with keepalived and conntrackd.

The Backup Server gos into the Master state for a few seconds without 
any inteface down Reports on Syslog / Snmp or else. On the Master Server 
I can only see some Received lower prio advert, forcing new election 
entrys. The Master server never lost the virtuell IP Adresses. At 
08:13:12 the Backup Server stopps with switching Backup &amp;lt;-&amp;gt; Master and 
was on the correct State "BACKUP".

All internal traffic goes to the correct Gateway IP Adress 192.168.43.1. 
But all the external Traffic was on the Backup Server which had no  
virtuell Adresses! Its also curiouse that the new election was only on 2 
of our 3 VRRP Interfaces as you can see below.

Backup Log(full on attach):

May 24 08:13:10 servername-backup Keepalived_vrrp: 
VRRP_Instance(VI_extern) Transition to MASTER STATE
May 24 08:13:10 servername-backup Kee&lt;/pre&gt;</description>
    <dc:creator>Tobias Dinse</dc:creator>
    <dc:date>2012-05-24T08:06:18</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.keepalived.devel/3852">
    <title>Re:  [bug?] keepalived-1.2.2：sockaddr_storage compare</title>
    <link>http://permalink.gmane.org/gmane.linux.keepalived.devel/3852</link>
    <description>&lt;pre&gt;OoO Peu  avant le début de  l'après-midi du mardi 28  février 2012, vers
13:41, Jiajun Chen &amp;lt;ylchenjj&amp;lt; at &amp;gt;gmail.com&amp;gt; disait :


Hi!

Thanks for the patch. I am a bit  late but I have applied it to my fixes
branch:
 https://github.com/vincentbernat/keepalived/commit/d9f51d125a248893e84d93c0da94ba8d28207a5f

The first  part of the  patch has already  been reported a while  ago by
Ronie Gilberto Henrich:
 https://github.com/vincentbernat/keepalived/commit/bc49a469
&lt;/pre&gt;</description>
    <dc:creator>Vincent Bernat</dc:creator>
    <dc:date>2012-05-19T08:28:37</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.linux.keepalived.devel/3851">
    <title>Re: Both VIDs share same physical interface asmaster/backup and we get a race</title>
    <link>http://permalink.gmane.org/gmane.linux.keepalived.devel/3851</link>
    <description>&lt;pre&gt;
to have two different sync groups, sharing one of the physical network 
interfaces in both of the sync groups.basically sharing the load using 
keepalived - where
addresses).Imagine a single firewall, with 3 nics in it.on the external nic, 
there are 5 IP addresses.2 of those addresses NAT through to the DMZ interface - 
and make up one sync group.
the other sync group.the problem is that when the first firewall is master for 
both groups (eg the backup box is turned off), everything is fine.
groups, and then, it takes over for the other for no apparent reason.im guessing 
it is because they are sharing the same physical interface - eth0 - and when it 
kicks in to backup mode, it tells the other groups using that eth0 interface - 
that something has gone wrong and it now fails.i am using the config key: 
dont_track_primaryso hopefully it doesn't track eth0 - but it seems too.the 
result - a non stop race for master/backup.eg:vrrp_sync_group ONE {
dont_track_primary    garp_master_delay 10    virtual_r&lt;/pre&gt;</description>
    <dc:creator>Yaroslav</dc:creator>
    <dc:date>2012-05-16T16:13:11</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.linux.keepalived.devel">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.linux.keepalived.devel</link>
  </textinput>
</rdf:RDF>

