Keepalived is a failover/monitoring daemon for LVS (linux virtual server) clusters, as well as VRRP2 (virtual router redundancy protocol) framework for director failover. This is the developers list.

lakshmi priya | 25 May 13:30

Fw: Dynamic change to keepalived.conf?

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      ff02::1

So you mean to say that I should remove "vrrp.mcast.net" from multicast group to get rid of below errors?

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 24 18:30:00 TPC-BA3-26H Keepalived_vrrp: VRRP_Instance(VI_1) Received lower prio advert, forcing new election
May 24 18:30:00 TPC-BA3-26H Keepalived_vrrp: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth1 for 2.0.0.1
May 24 18:30:00 TPC-BA3-26H Keepalived_vrrp: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth1 for 4.0.0.1
May 24 18:30:01 TPC-BA3-26H Keepalived_vrrp: VRRP_Instance(VI_1) Received lower prio advert, forcing new election

From: Pau Seglar <pseglar <at> ntrglobal.com>
To: lakshmi priya <pri_wip06 <at> yahoo.co.in>
Cc: "keepalived-devel <at> lists.sourceforge.net" <keepalived-devel <at> lists.sourceforge.net>
Sent: Friday, 25 May 2012 3:33 PM
Subject: Re: [Keepalived-devel] Dynamic change to keepalived.conf?

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 <pri_wip06 <at> yahoo.co.in>

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 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 24 18:30:00 TPC-BA3-26H Keepalived_vrrp: VRRP_Instance(VI_1) Received lower prio advert, forcing new election
May 24 18:30:00 TPC-BA3-26H Keepalived_vrrp: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth1 for 2.0.0.1
May 24 18:30:00 TPC-BA3-26H Keepalived_vrrp: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth1 for 4.0.0.1
May 24 18:30:01 TPC-BA3-26H Keepalived_vrrp: VRRP_Instance(VI_1) Received lower prio advert, forcing new election

Thanks in advance.

------------------------------------------------------------------------------
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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/keepalived-devel

------------------------------------------------------------------------------
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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/keepalived-devel

------------------------------------------------------------------------------ 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 <at> lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/keepalived-devel

--
Stephen Clark
NetWolves
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark <at> netwolves.com
http://www.netwolves.com

------------------------------------------------------------------------------
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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/keepalived-devel

------------------------------------------------------------------------------
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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/keepalived-devel

headers

lakshmi priya | 25 May 08:57

Re: Both keepalived servers comes up in MASTER state

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.

Thanks in advance.

From: Steve Clark <sclark <at> netwolves.com>
To: lakshmi priya <pri_wip06 <at> yahoo.co.in>
Cc: Graeme Fowler <graeme <at> graemef.net>; "keepalived-devel <at> lists.sourceforge.net" <keepalived-devel <at> lists.sourceforge.net>
Sent: Thursday, 24 May 2012 6:05 PM
Subject: Re: [Keepalived-devel] Both keepalived servers comes up in MASTER state

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:

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 <pri_wip06 <at> yahoo.co.in>
To: Graeme Fowler <graeme <at> graemef.net>; "keepalived-devel <at> lists.sourceforge.net" <keepalived-devel <at> lists.sourceforge.net>
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             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            state NEW tcp dpt:ssh
REJECT     all -- anywhere             anywhere            reject-with icmp-host-prohibited
ACCEPT     vrrp -- anywhere             anywhere
ACCEPT     vrrp -- anywhere             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
REJECT     all -- anywhere             anywhere            reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     vrrp -- anywhere             anywhere

Server2

[root <at> TPC-BA3-26I lthiru]# iptables -L
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            state NEW tcp dpt:ssh
REJECT     all -- anywhere             anywhere            reject-with icmp-host-prohibited
ACCEPT     vrrp -- anywhere             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
REJECT     all -- anywhere             anywhere            reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

From: Graeme Fowler <graeme <at> graemef.net>
To: keepalived-devel <at> lists.sourceforge.net
Sent: Thursday, 24 May 2012 4:30 PM
Subject: Re: [Keepalived-devel] Both keepalived servers comes up in MASTER state

On Thu, 2012-05-24 at 18:19 +0800, lakshmi priya wrote:
> If anyone have idea on how to resolve this, please let me know.

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/
_______________________________________________
Keepalived-devel mailing list
Keepalived-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/keepalived-devel

------------------------------------------------------------------------------
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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/keepalived-devel

------------------------------------------------------------------------------ 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 <at> lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/keepalived-devel

--
Stephen Clark
NetWolves
Director of Technology
Phone: 813-579-3200
Fax: 813-882-0209
Email: steve.clark <at> netwolves.com
http://www.netwolves.com

------------------------------------------------------------------------------
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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/keepalived-devel

headers

Brad Schick | 24 May 18:41

Backup takeover delay

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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/keepalived-devel

headers

lakshmi priya | 24 May 13:53

Re: Both keepalived servers comes up in MASTER state

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 <tobias.dinse <at> stegbauer.info>
To: lakshmi priya <pri_wip06 <at> yahoo.co.in>
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,

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 state in server1 and BACKUP state in server2. Since in server2, priority is less, these states should be maintained.

But when i start keepalived in server1, it comes up in MASTER state as expected. When its started in server2, it starts in BACKUP, but immediately moves to MASTER state.

Please check the below log.

Server1

May 24 15:05:32 TPC-BA3-26H Keepalived_vrrp: ------< VRRP Topology >------
May 24 15:05:32 TPC-BA3-26H Keepalived_vrrp: VRRP Instance = VI_1
May 24 15:05:32 TPC-BA3-26H Keepalived_vrrp:    Want State = MASTER
May 24 15:05:32 TPC-BA3-26H Keepalived_vrrp:    Runing on device = eth1
May 24 15:05:32 TPC-BA3-26H Keepalived_vrrp:    Virtual Router ID = 61
May 24 15:05:32 TPC-BA3-26H Keepalived_vrrp:    Priority = 101
May 24 15:05:32 TPC-BA3-26H Keepalived_vrrp:    Advert interval = 1sec
May 24 15:05:32 TPC-BA3-26H Keepalived_vrrp:    Virtual IP = 2
May 24 15:05:32 TPC-BA3-26H Keepalived_vrrp:      2.0.0.1/24 dev eth1 scope global
May 24 15:05:32 TPC-BA3-26H Keepalived_vrrp:      4.0.0.1/24 dev eth1 scope global
May 24 15:05:32 TPC-BA3-26H Keepalived_vrrp: Using LinkWatch kernel netlink reflector...
May 24 15:05:32 TPC-BA3-26H Keepalived_vrrp: VRRP sockpool: [ifindex(3), proto(112), fd(10,11)]
May 24 15:05:33 TPC-BA3-26H Keepalived_vrrp: VRRP_Instance(VI_1) Transition to MASTER STATE
May 24 15:05:34 TPC-BA3-26H Keepalived_vrrp: VRRP_Instance(VI_1) Entering MASTER STATE
May 24 15:05:34 TPC-BA3-26H Keepalived_vrrp: VRRP_Instance(VI_1) setting protocol VIPs.
May 24 15:05:34 TPC-BA3-26H Keepalived_vrrp: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth1 for 2.0.0.1
May 24 15:05:34 TPC-BA3-26H Keepalived_vrrp: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth1 for 4.0.0.1

Server2

May 24 15:06:28 TPC-BA3-26I Keepalived_vrrp: ------< VRRP Topology >------
May 24 15:06:28 TPC-BA3-26I Keepalived_vrrp: VRRP Instance = VI_1
May 24 15:06:28 TPC-BA3-26I Keepalived_vrrp:    Want State = BACKUP
May 24 15:06:28 TPC-BA3-26I Keepalived_vrrp:    Runing on device = eth1
May 24 15:06:28 TPC-BA3-26I Keepalived_vrrp:    Virtual Router ID = 61
May 24 15:06:28 TPC-BA3-26I Keepalived_vrrp:    Priority = 100
May 24 15:06:28 TPC-BA3-26I Keepalived_vrrp:    Advert interval = 1sec
May 24 15:06:28 TPC-BA3-26I Keepalived_vrrp:    Virtual IP = 2
May 24 15:06:28 TPC-BA3-26I Keepalived_vrrp:      2.0.0.1/24 dev eth1 scope global
May 24 15:06:28 TPC-BA3-26I Keepalived_vrrp:      4.0.0.1/24 dev eth1 scope global
May 24 15:06:28 TPC-BA3-26I Keepalived_vrrp: Using LinkWatch kernel netlink reflector...
May 24 15:06:28 TPC-BA3-26I Keepalived_vrrp: VRRP_Instance(VI_1) Entering BACKUP STATE
May 24 15:06:28 TPC-BA3-26I Keepalived_vrrp: VRRP sockpool: [ifindex(3), proto(112), fd(10,11)]
May 24 15:06:32 TPC-BA3-26I Keepalived_vrrp: VRRP_Instance(VI_1) Transition to MASTER STATE
May 24 15:06:33 TPC-BA3-26I Keepalived_vrrp: VRRP_Instance(VI_1) Entering MASTER STATE
May 24 15:06:33 TPC-BA3-26I Keepalived_vrrp: VRRP_Instance(VI_1) setting protocol VIPs.
May 24 15:06:33 TPC-BA3-26I Keepalived_vrrp: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth1 for 2.0.0.1
May 24 15:06:33 TPC-BA3-26I Keepalived_vrrp: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth1 for 4.0.0.1

I did a lot of debugging and I guess VRRP advertisement packets are not reaching keepalived application , though TCPDUMP on server2 shows as if it receives VRRP advertisements. Application enters "vrrp_dispatcher_read_to" every time, which is the function invoked on timeout.

If anyone have idea on how to resolve this, please let me know.

Thanks in advance.

------------------------------------------------------------------------------ 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 <at> lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/keepalived-devel

-- # Stegbauer Datawork # Tobias Dinse # +49 (8571) 922213 # Oberjulbachring 9, 84387 Julbach

------------------------------------------------------------------------------
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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/keepalived-devel

headers

Graeme Fowler | 24 May 13:47

Re: Both keepalived servers comes up in MASTER state

Hi Lakshmi

Please make sure you reply to the list!

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

> 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.

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/

headers

lakshmi priya | 24 May 12:19

Both keepalived servers comes up in MASTER state

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 state in server1 and BACKUP state in server2. Since in server2, priority is less, these states should be maintained.

But when i start keepalived in server1, it comes up in MASTER state as expected. When its started in server2, it starts in BACKUP, but immediately moves to MASTER state.

Please check the below log.

Server1

May 24 15:05:32 TPC-BA3-26H Keepalived_vrrp: ------< VRRP Topology >------
May 24 15:05:32 TPC-BA3-26H Keepalived_vrrp: VRRP Instance = VI_1
May 24 15:05:32 TPC-BA3-26H Keepalived_vrrp:    Want State = MASTER
May 24 15:05:32 TPC-BA3-26H Keepalived_vrrp:    Runing on device = eth1
May 24 15:05:32 TPC-BA3-26H Keepalived_vrrp:    Virtual Router ID = 61
May 24 15:05:32 TPC-BA3-26H Keepalived_vrrp:    Priority = 101
May 24 15:05:32 TPC-BA3-26H Keepalived_vrrp:    Advert interval = 1sec
May 24 15:05:32 TPC-BA3-26H Keepalived_vrrp:    Virtual IP = 2
May 24 15:05:32 TPC-BA3-26H Keepalived_vrrp:      2.0.0.1/24 dev eth1 scope global
May 24 15:05:32 TPC-BA3-26H Keepalived_vrrp:      4.0.0.1/24 dev eth1 scope global
May 24 15:05:32 TPC-BA3-26H Keepalived_vrrp: Using LinkWatch kernel netlink reflector...
May 24 15:05:32 TPC-BA3-26H Keepalived_vrrp: VRRP sockpool: [ifindex(3), proto(112), fd(10,11)]
May 24 15:05:33 TPC-BA3-26H Keepalived_vrrp: VRRP_Instance(VI_1) Transition to MASTER STATE
May 24 15:05:34 TPC-BA3-26H Keepalived_vrrp: VRRP_Instance(VI_1) Entering MASTER STATE
May 24 15:05:34 TPC-BA3-26H Keepalived_vrrp: VRRP_Instance(VI_1) setting protocol VIPs.
May 24 15:05:34 TPC-BA3-26H Keepalived_vrrp: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth1 for 2.0.0.1
May 24 15:05:34 TPC-BA3-26H Keepalived_vrrp: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth1 for 4.0.0.1

Server2

May 24 15:06:28 TPC-BA3-26I Keepalived_vrrp: ------< VRRP Topology >------
May 24 15:06:28 TPC-BA3-26I Keepalived_vrrp: VRRP Instance = VI_1
May 24 15:06:28 TPC-BA3-26I Keepalived_vrrp:    Want State = BACKUP
May 24 15:06:28 TPC-BA3-26I Keepalived_vrrp:    Runing on device = eth1
May 24 15:06:28 TPC-BA3-26I Keepalived_vrrp:    Virtual Router ID = 61
May 24 15:06:28 TPC-BA3-26I Keepalived_vrrp:    Priority = 100
May 24 15:06:28 TPC-BA3-26I Keepalived_vrrp:    Advert interval = 1sec
May 24 15:06:28 TPC-BA3-26I Keepalived_vrrp:    Virtual IP = 2
May 24 15:06:28 TPC-BA3-26I Keepalived_vrrp:      2.0.0.1/24 dev eth1 scope global
May 24 15:06:28 TPC-BA3-26I Keepalived_vrrp:      4.0.0.1/24 dev eth1 scope global
May 24 15:06:28 TPC-BA3-26I Keepalived_vrrp: Using LinkWatch kernel netlink reflector...
May 24 15:06:28 TPC-BA3-26I Keepalived_vrrp: VRRP_Instance(VI_1) Entering BACKUP STATE
May 24 15:06:28 TPC-BA3-26I Keepalived_vrrp: VRRP sockpool: [ifindex(3), proto(112), fd(10,11)]
May 24 15:06:32 TPC-BA3-26I Keepalived_vrrp: VRRP_Instance(VI_1) Transition to MASTER STATE
May 24 15:06:33 TPC-BA3-26I Keepalived_vrrp: VRRP_Instance(VI_1) Entering MASTER STATE
May 24 15:06:33 TPC-BA3-26I Keepalived_vrrp: VRRP_Instance(VI_1) setting protocol VIPs.
May 24 15:06:33 TPC-BA3-26I Keepalived_vrrp: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth1 for 2.0.0.1
May 24 15:06:33 TPC-BA3-26I Keepalived_vrrp: VRRP_Instance(VI_1) Sending gratuitous ARPs on eth1 for 4.0.0.1

I did a lot of debugging and I guess VRRP advertisement packets are not reaching keepalived application , though TCPDUMP on server2 shows as if it receives VRRP advertisements. Application enters "vrrp_dispatcher_read_to" every time, which is the function invoked on timeout.

If anyone have idea on how to resolve this, please let me know.

Thanks in advance.

------------------------------------------------------------------------------
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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/keepalived-devel

headers

Tobias Dinse | 24 May 10:06

curiouse state switch

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 <-> 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 Keepalived_vrrp: 
VRRP_Instance(VI_iscsi) Entering MASTER STATE
May 24 08:13:10 servername-backup Keepalived_vrrp: 
VRRP_Instance(VI_intern) Entering MASTER STATE

May 24 08:13:11 servername-backup Keepalived_vrrp: 
VRRP_Instance(VI_intern) Entering BACKUP STATE
May 24 08:13:11 servername-backup Keepalived_vrrp: 
VRRP_Instance(VI_extern) Entering BACKUP STATE
May 24 08:13:11 servername-backup Keepalived_vrrp: 
VRRP_Instance(VI_iscsi) Entering BACKUP STATE

May 24 08:13:12 servername-backup Keepalived_vrrp: 
VRRP_Instance(VI_iscsi) Entering BACKUP STATE
May 24 08:13:12 servername-backup Keepalived_vrrp: 
VRRP_Instance(VI_intern) Entering BACKUP STATE
May 24 08:13:12 servername-backup Keepalived_vrrp: 
VRRP_Instance(VI_extern) Entering BACKUP STATE

Master Log(full on attach):

May 24 08:13:14 servername-master Keepalived_vrrp: 
VRRP_Instance(VI_iscsi) Received lower prio advert, forcing new election
May 24 08:13:14 servername-master Keepalived_vrrp: 
VRRP_Instance(VI_intern) Received lower prio advert, forcing new election
May 24 08:13:14 servername-master Keepalived_vrrp: 
VRRP_Instance(VI_iscsi) Received lower prio advert, forcing new election
May 24 08:13:14 servername-master Keepalived_vrrp: 
VRRP_Instance(VI_intern) Received lower prio advert, forcing new election
May 24 08:13:14 servername-master Keepalived_vrrp: 
VRRP_Instance(VI_iscsi) Received lower prio advert, forcing new election
May 24 08:13:14 servername-master Keepalived_vrrp: 
VRRP_Instance(VI_intern) Received lower prio advert, forcing new election
May 24 08:13:15 servername-master Keepalived_vrrp: 
VRRP_Instance(VI_iscsi) Received lower prio advert, forcing new election
May 24 08:13:15 servername-master Keepalived_vrrp: 
VRRP_Instance(VI_intern) Received lower prio advert, forcing new election

After rebooting the Backup Server the Problem was gone.

thanks in advance

Tobias

# Simple script for primary-backup setups
#
global_defs {
notification_email {
tech-role <at> xxx.info
info <at> xxx.de
}
notification_email_from keepalived-gw1 <at> xxx.info
smtp_server 192.168.43.3
smtp_connect_timeout 30
}

vrrp_sync_group G1 {   # must be before vrrp_instance declaration
  group {
    VI_intern
    VI_extern
    VI_iscsi
  }
  notify_master "/etc/conntrackd/primary-backup.sh primary"
  notify_backup "/etc/conntrackd/primary-backup.sh backup"
  notify_fault "/etc/conntrackd/primary-backup.sh fault"
}

vrrp_instance VI_intern {
    interface eth0
    state MASTER
    virtual_router_id 61
    priority 150
    advert_int 1
    smtp_alert
    authentication {
      auth_type PASS
      auth_pass top-secret
    }
    virtual_ipaddress {
        192.168.43.1/24   # default CIDR mask is /32
    }
}

vrrp_instance VI_extern {
    interface eth1
    state MASTER
    virtual_router_id 62
    priority 150
    advert_int 1
    smtp_alert
    authentication {
      auth_type PASS
      auth_pass top-secret
    }
    virtual_ipaddress {
        xxx.30.210.242/28
        xxx.30.210.243/28
        xxx.30.210.244/28
        xxx.30.210.245/28
        xxx.30.210.246/28
        xxx.30.210.247/28
        xxx.30.210.248/28
    }
notify_master "/etc/conntrackd/racoon.sh start"
notify_backup "/etc/conntrackd/racoon.sh stop"
notify_fault "/etc/conntrackd/racoon.sh stop"  
}

vrrp_instance VI_iscsi {
    interface eth2
    state MASTER
    virtual_router_id 63
    priority 150
    advert_int 1
    smtp_alert  
    authentication {
      auth_type PASS
      auth_pass top-secret
    }
    virtual_ipaddress {
        192.168.130.1/24
    }
}

# Simple script for primary-backup setups
#
global_defs {
notification_email {
tech-role <at> xxx.info
info <at> xxx.info
}
notification_email_from keepalived-gw2 <at> xxx.info
smtp_server 192.168.43.3
smtp_connect_timeout 30
}

vrrp_sync_group G1 {   # must be before vrrp_instance declaration
  group {
    VI_intern
    VI_extern
    VI_iscsi
  }
  notify_master "/etc/conntrackd/primary-backup.sh primary"
  notify_backup "/etc/conntrackd/primary-backup.sh backup"
  notify_fault "/etc/conntrackd/primary-backup.sh fault"
}

vrrp_instance VI_intern {
    interface eth0
    state BACKUP
    virtual_router_id 61
    priority 100
    advert_int 1
    smtp_alert
    authentication {
      auth_type PASS
      auth_pass top-secret
    }
    virtual_ipaddress {
        192.168.43.1/24   # default CIDR mask is /32
    }
}
vrrp_instance VI_extern {
    interface eth1
    state BACKUP
    virtual_router_id 62
    priority 100
    advert_int 1
    smtp_alert
    authentication {
      auth_type PASS
      auth_pass top-secret
    }
    virtual_ipaddress {
         xxx.30.210.242/28
         xxx.30.210.243/28
         xxx.30.210.244/28
         xxx.30.210.245/28
         xxx.30.210.246/28
         xxx.30.210.247/28
         xxx.30.210.248/28
    }
notify_master "/etc/conntrackd/racoon.sh start"
notify_backup "/etc/conntrackd/racoon.sh stop"
notify_fault "/etc/conntrackd/racoon.sh stop"
}
vrrp_instance VI_iscsi {
    interface eth2
    state BACKUP
    virtual_router_id 63
    priority 100
    advert_int 1
    smtp_alert
    authentication {
      auth_type PASS
      auth_pass top-secret
    }
    virtual_ipaddress {
        192.168.130.1/24
    }
}

May 24 08:13:10 servername-backup Keepalived_vrrp: VRRP_Instance(VI_extern) Transition to MASTER STATE
May 24 08:13:10 servername-backup Keepalived_vrrp: VRRP_Group(G1) Syncing instances to MASTER state
May 24 08:13:10 servername-backup Keepalived_vrrp: VRRP_Instance(VI_intern) Transition to MASTER STATE
May 24 08:13:10 servername-backup Keepalived_vrrp: VRRP_Instance(VI_iscsi) Transition to MASTER STATE
May 24 08:13:10 servername-backup Keepalived_vrrp: Opening script file /etc/conntrackd/primary-backup.sh
May 24 08:13:10 servername-backup Keepalived_vrrp: VRRP_Instance(VI_iscsi) Entering MASTER STATE
May 24 08:13:10 servername-backup Keepalived_vrrp: Remote SMTP server [192.168.43.3:25] connected.
May 24 08:13:10 servername-backup Keepalived_vrrp: VRRP_Instance(VI_intern) Entering MASTER STATE
May 24 08:13:10 servername-backup Keepalived_vrrp: Remote SMTP server [192.168.43.3:25] connected.
May 24 08:13:10 servername-backup Keepalived_vrrp: SMTP alert successfully sent.
May 24 08:13:10 servername-backup Keepalived_vrrp: SMTP alert successfully sent.
May 24 08:13:11 servername-backup Keepalived_vrrp: VRRP_Instance(VI_extern) Entering MASTER STATE
May 24 08:13:11 servername-backup Keepalived_vrrp: Opening script file /etc/conntrackd/racoon.sh
May 24 08:13:11 servername-backup Keepalived_vrrp: Remote SMTP server [192.168.43.3:25] connected.
May 24 08:13:11 servername-backup Keepalived_vrrp: SMTP alert successfully sent.
May 24 08:13:11 servername-backup Keepalived_vrrp: VRRP_Instance(VI_iscsi) Received higher prio advert
May 24 08:13:11 servername-backup Keepalived_vrrp: VRRP_Instance(VI_iscsi) Entering BACKUP STATE
May 24 08:13:11 servername-backup Keepalived_vrrp: VRRP_Group(G1) Syncing instances to BACKUP state
May 24 08:13:11 servername-backup Keepalived_vrrp: VRRP_Instance(VI_intern) Entering BACKUP STATE
May 24 08:13:11 servername-backup Keepalived_vrrp: VRRP_Instance(VI_extern) Entering BACKUP STATE
May 24 08:13:11 servername-backup Keepalived_vrrp: Opening script file /etc/conntrackd/racoon.sh
May 24 08:13:11 servername-backup Keepalived_vrrp: Opening script file /etc/conntrackd/primary-backup.sh
May 24 08:13:11 servername-backup Keepalived_vrrp: Remote SMTP server [192.168.43.3:25] connected.
May 24 08:13:11 servername-backup Keepalived_vrrp: SMTP alert successfully sent.
May 24 08:13:12 servername-backup Keepalived_vrrp: VRRP_Instance(VI_extern) Transition to MASTER STATE
May 24 08:13:12 servername-backup Keepalived_vrrp: VRRP_Group(G1) Syncing instances to MASTER state
May 24 08:13:12 servername-backup Keepalived_vrrp: VRRP_Instance(VI_intern) Transition to MASTER STATE
May 24 08:13:12 servername-backup Keepalived_vrrp: VRRP_Instance(VI_iscsi) Transition to MASTER STATE
May 24 08:13:12 servername-backup Keepalived_vrrp: Opening script file /etc/conntrackd/primary-backup.sh
May 24 08:13:12 servername-backup Keepalived_vrrp: VRRP_Instance(VI_iscsi) Received higher prio advert
May 24 08:13:12 servername-backup Keepalived_vrrp: VRRP_Instance(VI_iscsi) Entering BACKUP STATE
May 24 08:13:12 servername-backup Keepalived_vrrp: VRRP_Group(G1) Syncing instances to BACKUP state
May 24 08:13:12 servername-backup Keepalived_vrrp: VRRP_Instance(VI_intern) Entering BACKUP STATE
May 24 08:13:12 servername-backup Keepalived_vrrp: VRRP_Instance(VI_extern) Entering BACKUP STATE
May 24 08:13:12 servername-backup Keepalived_vrrp: Opening script file /etc/conntrackd/racoon.sh
May 24 08:13:12 servername-backup Keepalived_vrrp: Opening script file /etc/conntrackd/primary-backup.sh
May 24 08:13:12 servername-backup Keepalived_vrrp: Remote SMTP server [192.168.43.3:25] connected.
May 24 08:13:12 servername-backup Keepalived_vrrp: SMTP alert successfully sent.
May 24 08:40:28 servername-backup Keepalived_vrrp: Terminating VRRP child process on signal
May 24 08:43:34 servername-backup Keepalived_vrrp: Registering Kernel netlink reflector
May 24 08:43:34 servername-backup Keepalived_vrrp: Registering Kernel netlink command channel
May 24 08:43:34 servername-backup Keepalived_vrrp: Registering gratutious ARP shared channel
May 24 08:43:34 servername-backup Keepalived_vrrp: Initializing ipvs 2.6
May 24 08:43:34 servername-backup Keepalived_vrrp: IPVS: Can't initialize ipvs: Protocol not available
May 24 08:43:34 servername-backup Keepalived_vrrp: Opening file '/etc/keepalived/keepalived.conf'.
May 24 08:43:34 servername-backup Keepalived_vrrp: Configuration is using : 74944 Bytes
May 24 08:43:34 servername-backup Keepalived_vrrp: Using LinkWatch kernel netlink reflector...
May 24 08:43:34 servername-backup Keepalived_vrrp: VRRP_Instance(VI_intern) Entering BACKUP STATE
May 24 08:43:34 servername-backup Keepalived_vrrp: Opening script file /etc/conntrackd/primary-backup.sh
May 24 08:43:34 servername-backup Keepalived_vrrp: VRRP_Instance(VI_extern) Entering BACKUP STATE
May 24 08:43:34 servername-backup Keepalived_vrrp: Opening script file /etc/conntrackd/racoon.sh
May 24 08:43:34 servername-backup Keepalived_vrrp: VRRP_Instance(VI_iscsi) Entering BACKUP STATE
May 24 08:43:34 servername-backup Keepalived_vrrp: Remote SMTP server [192.168.43.3:25] connected.
May 24 08:43:34 servername-backup Keepalived_vrrp: Remote SMTP server [192.168.43.3:25] connected.
May 24 08:43:34 servername-backup Keepalived_vrrp: Remote SMTP server [192.168.43.3:25] connected.

May 24 08:13:14 servername-master Keepalived_vrrp: VRRP_Instance(VI_iscsi) Received lower prio
advert, forcing new election
May 24 08:13:14 servername-master Keepalived_vrrp: VRRP_Instance(VI_intern) Received lower prio
advert, forcing new election
May 24 08:13:14 servername-master Keepalived_vrrp: VRRP_Instance(VI_iscsi) Received lower prio
advert, forcing new election
May 24 08:13:14 servername-master Keepalived_vrrp: VRRP_Instance(VI_intern) Received lower prio
advert, forcing new election
May 24 08:13:14 servername-master Keepalived_vrrp: VRRP_Instance(VI_iscsi) Received lower prio
advert, forcing new election
May 24 08:13:14 servername-master Keepalived_vrrp: VRRP_Instance(VI_intern) Received lower prio
advert, forcing new election
May 24 08:13:15 servername-master Keepalived_vrrp: VRRP_Instance(VI_iscsi) Received lower prio
advert, forcing new election
May 24 08:13:15 servername-master Keepalived_vrrp: VRRP_Instance(VI_intern) Received lower prio
advert, forcing new election

------------------------------------------------------------------------------
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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/keepalived-devel

headers

Tom van Leeuwen | 7 May 08:10

backup keepalived responds to neighbor sollication for vrrp ipv6 address

Hey guys,

I'm running Keepalived v1.2.2 (12/23,2011) on 2 ubuntu12.04 servers and 
I'm having ipv6 problems. (ipv4 runs perfectly)
Box2 is answering neighbor sollicitations for the vrrp ipv6 address 
living on box1 although the ip is not configured on box2 and keepalived 
is in backup state there.

box1 keepalived:
vrrp_instance vlan123 {
         state BACKUP
         interface vlan123
         virtual_router_id 40
         priority 250
         preempt_delay 90

         authentication {
                 auth_type PASS
                 auth_pass secretpass
         }

         virtual_ipaddress {
                 1.2.3.49/32
                 2001:1234:ffff::10/124
         }
}

box2 keepalived:
vrrp_instance vlan123 {
         state BACKUP
         interface vlan123
         virtual_router_id 40
         priority 200
         preempt_delay 90

         authentication {
                 auth_type PASS
                 auth_pass secretpass
         }

         virtual_ipaddress {
                 1.2.3.49/32
                 2001:1234:ffff::10/124
         }
}

The current state of the vlan123 interface on box1:
box01 ~ # ip addr show dev vlan123
11: vlan123 <at> bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc 
noqueue state UP
     link/ether 00:9c:02:3c:c9:70 brd ff:ff:ff:ff:ff:ff
     inet 1.2.3.50/28 brd 1.2.3.63 scope global vlan123
     inet 1.2.3.49/32 scope global vlan123
     inet6 2001:1234:ffff::10/124 scope global tentative dadfailed
        valid_lft forever preferred_lft forever
     inet6 2001:1234:ffff::11/124 scope global
        valid_lft forever preferred_lft forever
     inet6 fe80::29c:2ff:fe3c:c970/64 scope link
        valid_lft forever preferred_lft forever

box2:
box02 ~ # ip addr show dev vlan123
11: vlan123 <at> bond0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc 
noqueue state UP
     link/ether 00:9c:02:3c:c9:dc brd ff:ff:ff:ff:ff:ff
     inet 1.2.3.51/28 brd 1.2.3.63 scope global vlan123
     inet6 2001:1234:ffff::12/124 scope global
        valid_lft forever preferred_lft forever
     inet6 fe80::29c:2ff:fe3c:c9dc/64 scope link
        valid_lft forever preferred_lft forever

As you can see, the vrrp address 2001:1234:ffff::10 is living on box1 
but is dadfailed (dup address detection).
So who is responding to it then? A ping from the upstream router shows 
box2 is answering:

Upstream:
asa# clear ipv6 neighbors
asa# ping inside 2001:1234:ffff::10 repeat 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 2001:1234:ffff::10, timeout is 2 seconds:
!
Success rate is 100 percent (1/1), round-trip min/avg/max = 560/560/560 ms
asa# sh ipv6 neigh
IPv6 Address                              Age Link-layer Addr State 
Interface
2001:1234:ffff::10                          0 009c.023c.c9dc  REACH inside
asa#

Box1:
box01 ~ # tcpdump -i vlan123 -nn -e ip6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vlan123, link-type EN10MB (Ethernet), capture size 65535 bytes
07:19:26.527821 00:22:55:97:98:c1 > 33:33:ff:00:00:10, ethertype IPv6 
(0x86dd), length 86: 2001:1234:ffff::14 > ff02::1:ff00:10: ICMP6, 
neighbor solicitation, who has 2001:1234:ffff::10, length 32
^C
1 packet captured
11 packets received by filter
0 packets dropped by kernel

Box2:
box02 ~ # tcpdump -i vlan123 -nn -e ip6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vlan123, link-type EN10MB (Ethernet), capture size 65535 bytes
07:19:25.096120 00:22:55:97:98:c1 > 33:33:ff:00:00:10, ethertype IPv6 
(0x86dd), length 86: 2001:1234:ffff::14 > ff02::1:ff00:10: ICMP6, 
neighbor solicitation, who has 2001:1234:ffff::10, length 32
07:19:25.650105 00:9c:02:3c:c9:dc > 00:22:55:97:98:c1, ethertype IPv6 
(0x86dd), length 86: 2001:1234:ffff::12 > 2001:1234:ffff::14: ICMP6, 
neighbor advertisement, tgt is 2001:1234:ffff::10, length 32
07:19:25.650441 00:22:55:97:98:c1 > 00:9c:02:3c:c9:dc, ethertype IPv6 
(0x86dd), length 114: 2001:1234:ffff::14 > 2001:1234:ffff::10: ICMP6, 
echo request, seq 11135, length 60
07:19:25.650570 00:9c:02:3c:c9:dc > 00:22:55:97:98:c1, ethertype IPv6 
(0x86dd), length 114: 2001:1234:ffff::12 > 2001:1234:ffff::14: ICMP6, 
echo reply, seq 11135, length 60
^C
4 packets captured
11 packets received by filter
0 packets dropped by kernel

I don't understand why box2 is responding to the neighbor sollicitation.
Obviously box2 thinks it should respond for ip 2001:1234:ffff::10 and it 
does! The icmp reply however is sent from 2001:1234:ffff::14.

With kind regards,
Tom van Leeuwen

------------------------------------------------------------------------------
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/

headers

Anton Melser | 2 May 15:41

Getting around an ARP cache with a very long refresh

Hi,
I have a very basic setup where I just move IPs and a few routes
between two machines. I though I could get away with just keepalived -
it works beautifully, or at least it did in my test environment... One
of our link providers has some insane ARP cache refresh (several
hours) and so my lovely keepalived system moves the IPs in seconds
only for the IPs to remain unavailable for hours . Of course they
aren't updating with gratuitous ARPs (which keepalived does also,
right? Anyway, even manual arping doesn't change things) I didn't want
to introduce any other pieces into the system but if I am going to
have a virtual MAC that gets transferred then I'll need something more
right? Is that the best way to go?
Any ideas?
Thanks
Anton

--

-- 
echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlbxq' | dc
This will help you for 99.9% of your problems ...

------------------------------------------------------------------------------
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/

headers

Bar Ziony | 29 Apr 12:53

Failover takes 3-5 seconds

Hi,

I've setup keepalived in a MASTER/BACKUP configuration on 2 servers. I'll paste the configuration of both at the end of the message.

Everything is working perfectly - When the check fails on MASTER, the virtual IP is swapped and the failover happens. When I kill keepalived on the MASTER, it happens too. When I bring keepalived or the check passes on the lower priority server, the failover happens.

However, This failover takes 3-5 seconds, during which I can see 3-4 packets lost on a regular 'ping VIRTUAL_IP' (1-sec interval ICMP). Is this normal? Can this be lower? in 5 seconds I can lose quite a bit of HTTP requests from users, since we have a pretty high-volume website.

Note: I'm using keepalived 1.1.20 with Willy Tarreau (haproxy author) unicast patch: http://1wt.eu/keepalived/keepalived-1.1.19-unicast.patch . It works great.

Here are the configurations:

MASTER:

global_defs {

notification_email {

email <at> example.com

}

notification_email_from "Keepalived <keepalived <at> lb-01.example.com>"

smtp_server 192.168.100.100

smtp_connect_timeout 30

}

vrrp_script chk_haproxy {

script "kill -0 `cat /var/run/haproxy.pid`"

interval 2 # check every 2 seconds

weight 2 # add 2 points of priority if OK

}

vrrp_instance VI_1 {

state MASTER

interface eth0

virtual_router_id 51

advert_int 1

priority 101 # 101 on master, 100 on backup

vrrp_unicast_bind 192.168.1.1 # Internal IP of this machine

vrrp_unicast_peer 192.168.1.2 # Internal IP of peer

smtp_alert

authentication {

auth_type PASS

auth_pass my_pass

}

virtual_ipaddress {

50.1.1.1

}

track_script {

chk_haproxy

}

BACKUP:

global_defs {

notification_email {

email <at> example.com

}

notification_email_from "Keepalived <keepalived <at> lb-02.example.com>"

smtp_server 192.168.100.100

smtp_connect_timeout 30

}

vrrp_script chk_haproxy {

script "kill -0 `cat /var/run/haproxy.pid`"

interval 2 # check every 2 seconds

weight 2 # add 2 points of priority if OK

}

vrrp_instance VI_1 {

state BACKUP

interface eth0

virtual_router_id 51

advert_int 1

priority 100 # 101 on master, 100 on backup

vrrp_unicast_bind 192.168.1.2 # Internal IP of this machine

vrrp_unicast_peer 192.168.1.1 # Internal IP of peer

smtp_alert

authentication {

auth_type PASS

auth_pass my_pass

}

virtual_ipaddress {

50.1.1.1

}

track_script {

chk_haproxy

}

Thanks,

Bar.

------------------------------------------------------------------------------
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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/keepalived-devel

headers

Ken Price | 23 Apr 18:51

Keepalived 1.2.2, IPV6 & fwmarks

It's been awhile since I've posted to this list, which reflects my dive into Keepalived with IPv6. Does anyone have a solution for a Keepalived config using fwmarks with both IPv4/IPv6 and UDP/TCP services? I've already tried the following patch

https://github.com/vincentbernat/keepalived/commit/479bb39cb94e602e8e8891d84538b2f67de14f04

with limited success. It fixes my IPv6 issues, but breaks my IPv4 UDP regardless of my use of fwmarks. I'm using DNS as the initial test service. Using ipvsadm all services appear up and ready on dual stack servers, but I get response timeouts with IPv6 without patch, and IPv4 with patch. Without patch, IPv6 works great using the traditional IP:port config - but in my environment that's a hell of a high maintenance config. Fwmarks makes everything simple. I'd like to keep it that way if at all possible. I'm using CentOS 6.2 (i386), LVS-DR, IPv6/IPv4 port 53 (TCP/UDP), and the latest Keepalived 1.2.2-3 from EPEL rebuilt using the source RPM.

Any ideas?

Thanks in advance for your feedback. Best regards,

Ken Price

------------------------------------------------------------------------------
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 <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/keepalived-devel

31	May 2012
15	April 2012
22	March 2012
27	February 2012
15	January 2012
93	December 2011
19	November 2011
36	October 2011
10	September 2011
9	August 2011
22	July 2011
32	June 2011
38	May 2011
27	April 2011
19	March 2011
35	February 2011
32	January 2011
18	December 2010
26	November 2010
75	October 2010
58	September 2010
27	August 2010
25	July 2010
28	June 2010
34	May 2010
20	April 2010
42	March 2010
24	February 2010
2	January 2010
13	December 2009
64	November 2009
35	October 2009
51	September 2009
60	August 2009
8	July 2009
37	June 2009
11	May 2009
49	April 2009
55	March 2009
35	February 2009
7	January 2009
15	December 2008
17	November 2008
19	October 2008
33	September 2008
17	August 2008
46	July 2008
45	June 2008
2	May 2008
15	April 2008
15	March 2008
15	February 2008
60	January 2008
10	December 2007
30	November 2007
20	October 2007
48	September 2007
9	August 2007
48	July 2007
51	June 2007
26	May 2007
21	April 2007
38	March 2007
21	February 2007
28	January 2007
22	December 2006
17	November 2006
6	October 2006
11	September 2006
25	August 2006
9	July 2006
2	June 2006
19	May 2006
20	April 2006
30	March 2006
12	February 2006
33	January 2006
16	December 2005
8	November 2005
26	October 2005
53	September 2005
16	August 2005
22	July 2005
32	June 2005
27	May 2005
25	April 2005
42	March 2005
98	February 2005
45	January 2005
6	December 2004
7	November 2004
32	October 2004
17	September 2004
40	August 2004
47	July 2004
53	June 2004
77	May 2004
55	April 2004
92	March 2004
77	February 2004
36	January 2004
28	December 2003
39	November 2003
61	October 2003
77	September 2003
71	August 2003
80	July 2003
74	June 2003
56	May 2003
54	April 2003
66	March 2003
50	February 2003
66	January 2003
27	December 2002
4	November 2002
1	May 2001

Mon	Tue	Wed	Thu	Fri	Sat	Sun

	1	2	3	4	5	6
7	8	9	10	11	12	13
14	15	16	17	18	19	20
21	22	23	24	25	26	27
28	29	30	31