0

I have two servers running Keepalived 1.2.7 with hostnames left and right. Here are the configs:

# keepalived.conf on left
vrrp_instance VI_1 {
    state MASTER
    interface eth1
    virtual_router_id 51
    priority 160
    advert_int 1
    virtual_ipaddress {
        10.10.10.200
    }
}

# keepalived.conf on right
vrrp_instance VI_1 {
    state MASTER
    interface eth1
    virtual_router_id 51
    priority 100
    advert_int 1
    virtual_ipaddress {
        10.10.10.200
    }
}

Now I power cycle left. Here are what the syslogs look like, interleaved and annotated:

>> started servers <<
Aug 15 19:07:32 left Keepalived[4041]: Starting VRRP child process, pid=4043
Aug 15 19:07:32 right Keepalived[4041]: Starting VRRP child process, pid=4043
Aug 15 19:07:33 left Keepalived_vrrp[4043]: VRRP_Instance(VI_1) Transition to MASTER STATE
Aug 15 19:07:33 right Keepalived_vrrp[4043]: VRRP_Instance(VI_1) Transition to MASTER STATE
Aug 15 19:07:33 right Keepalived_vrrp[4043]: VRRP_Instance(VI_1) Received higher prio advert
Aug 15 19:07:33 right Keepalived_vrrp[4043]: VRRP_Instance(VI_1) Entering BACKUP STATE
Aug 15 19:07:34 left Keepalived_vrrp[4043]: VRRP_Instance(VI_1) Entering MASTER STATE
>> left has 10.10.10.200 <<

>> powered off left <<
Aug 15 19:08:25 right Keepalived_vrrp[4043]: VRRP_Instance(VI_1) Transition to MASTER STATE
Aug 15 19:08:26 right Keepalived_vrrp[4043]: VRRP_Instance(VI_1) Entering MASTER STATE
>> right has 10.10.10.200 <<

>> powered on left <<
Aug 15 19:08:58 left Keepalived[1027]: Starting VRRP child process, pid=1029
Aug 15 19:08:59 left Keepalived_vrrp[1029]: VRRP_Instance(VI_1) Transition to MASTER STATE
Aug 15 19:09:00 left Keepalived_vrrp[1029]: VRRP_Instance(VI_1) Entering MASTER STATE
Aug 15 19:09:00 right Keepalived_vrrp[4043]: VRRP_Instance(VI_1) Received higher prio advert
Aug 15 19:09:00 right Keepalived_vrrp[4043]: VRRP_Instance(VI_1) Entering BACKUP STATE
>> neither has 10.10.10.200 <<

I was expecting left to take back 10.10.10.200 when it came back up. Why doesn't it? How can I modify my keepalived.confs so that it does?

Improve this question

2 Answers 2

Reset to default
1

You want the configuration on "right" to look like this:

vrrp_instance VI_1 {
state BACKUP
interface eth1
virtual_router_id 51
priority 100
advert_int 1
virtual_ipaddress {
    10.10.10.200
}

The BACKUP keyword tells keepalived to fail back to the MASTER when available.

Improve this answer
2
  • That doesn't seem to do the trick. The first section of the logs is a little different (there's no right ... Received higher prio advert or right ... Entering BACKUP STATE), but the 2nd and 3rd sections are exactly the same, and I still end up with neither server having 10.10.10.200.
    – Snowball
    Aug 15, 2014 at 19:57
  • It runs out the issue wasn't Keepalived. I was running this in Vagrant, which does some network configuration on startup. I should have learned by now :)
    – Snowball
    Aug 17, 2014 at 19:41
0

The following configuration works, though I'm still curious as to why the one in my question doesn't.

# keepalived.conf on left
vrrp_instance VI_1 {
    state BACKUP
    interface eth1
    virtual_router_id 51
    priority 160
    advert_int 1
    preempt_delay 15
    virtual_ipaddress {
        10.10.10.200
    }
}

# keepalived.conf on right
vrrp_instance VI_1 {
    state BACKUP
    interface eth1
    virtual_router_id 51
    priority 100
    advert_int 1
    preempt_delay 15
    virtual_ipaddress {
        10.10.10.200
    }
}

This configuration says to reelect a new master 15 seconds after a higher priority machine comes online. There's an explanation of the preempt_delay option on the mailing list.

One issue with this configuration: if both machines go down, neither will claim 10.10.10.200 when they come back up. (This was due to the network autoconfiguration that Vagrant does.)

Improve this answer
2
  • 1
    One server needs to be MASTER, the other needs to be BACKUP.
    – Jim G.
    Aug 15, 2014 at 21:17
  • I have the same issue with vagrant. Setting states of both machines to BACKUP doesn't help. But adding preempt_delay can solve that.
    – Franz Wong
    Nov 3, 2015 at 2:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .