Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am having this strange issue where my vip is being removed from my interface when I receive a new DHCP renewal request. The logs shows the following:

Jun  1 17:00:06 lb1 dhclient: DHCPREQUEST of 10.0.0.2 on eth0 to 10.0.0.3 port 67 (xid=0x6deab016)
Jun  1 17:00:06 lb1 dhclient: DHCPNAK from 10.0.0.3 (xid=0x6deab016)
Jun  1 17:00:06 lb1 dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3 (xid=0x37e1db6a)
Jun  1 17:00:06 lb1 dhclient: DHCPREQUEST of 10.0.0.2 on eth0 to 255.255.255.255 port 67 (xid=0x37e1db6a)
Jun  1 17:00:06 lb1 dhclient: DHCPOFFER of 10.0.0.2 from 10.0.0.3
Jun  1 17:00:06 lb1 dhclient: DHCPACK of 10.0.0.2 from 10.0.0.3
Jun  1 17:00:06 lb1 dhclient: bound to 10.0.0.2 -- renewal in 38223 seconds.
Jun  1 17:00:07 lb1 ntpd[1321]: Deleting interface #8 eth0, 10.0.255.254#123, interface stats: received=7, sent=0, dropped=0, active_time=145198 secs
Jun  1 17:00:07 lb1 ntpd[1321]: peers refreshed

At this point the vip ip (10.0.255.254) is removed from the interface and is not being failed over to the other keepalived instance.

The working ip a command output:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether fa:16:3e:cf:35:ac brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.2/16 brd 10.0.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 10.0.255.254/32 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fecf:35ac/64 scope link
       valid_lft forever preferred_lft forever

and when the dhcp renewal has ran:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether fa:16:3e:cf:35:ac brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.2/16 brd 10.0.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::f816:3eff:fecf:35ac/64 scope link
       valid_lft forever preferred_lft forever

the interfaces file:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet dhcp

When I restart keepalived on the instance the vip is added back to the interface again. So the question is why is dhcp removing the vip?

share|improve this question

1 Answer 1

I have also recently encountered this same issue. I'm running two OpenStack instances with keepalived. I noticed that when the instance renewed its IP address sometimes keepalived thought the IP address was removed and then re-added it moments later. That was enough for it to release the VIPs, but did not re-add them to the primary keepalived instance nor was it enough for the standby instance to take over the VIPs.

After looking over keepalived's docs I found an option called dont_track_primary that can be added to the vrrp instance. I added that option to all of my vrrp instances and haven't had the issue since.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.