Topics

Adding a track_script makes keepalived transition right away to fault mode

Aki Ketolainen
 

Hi,

I have a setup with 3 VMs in an IaaS cloud. I can set the IP address of eth2 interface
to any public IP address in my subscription. I'm using 10.255.255.1 as the virtual_ipaddress and
then setup eth2 with the floating IP address when transitioning to the master mode.
The eth1 interfaces are in the same vlan on the three VMs.

I've setup keepalived 1.3.5 on CentOS 7.7 with this configuration:

global_defs {
enable_script_security
script_user root
}

vrrp_script ping-vip {
script "/etc/keepalived/scripts/ping-vip"
interval 15
fall 2
rise 2
}

vrrp_instance vip {
state MASTER
interface eth1
virtual_router_id 1
priority 3
advert_int 1
virtual_ipaddress {
10.255.255.1/8 dev eth1
}
track_script {
ping-vip
}
notify_master "/etc/keepalived/scripts/activate-vip INSTANCE vip MASTER"
notify_backup "/etc/keepalived/scripts/activate-vip INSTANCE vip BACKUP"
notify_fault "/etc/keepalived/scripts/activate-vip INSTANCE vip FAULT"
}

The contents of /etc/keepalived/scripts/ping-vip are:

#!/bin/bash

/usr/bin/ping -W 1 -c 1 10.0.0.1 >/dev/null 2>/dev/null
#/usr/bin/ping -W 1 -c 1 vip-address >/dev/null 2>/dev/null

if [ $? -ne 0 ]
then
exit 1
else
exit 0
fi

If i try to run "ping -W 1 -c 1 vip-address" in ping-vip, keepalived goes
straight to fault mode on startup, that's why I'm pinging 10.0.0.1 for now, it's
a local interface address.

The vip-address is managed by the master mode of keepalived so it's not available
right away, but should be up before 15 seconds I set for interval.

If I don't add the track_script into the keepalived.conf, keepalived starts into the master mode.

Could somebody show me what I'm doing wrong?

Best regards,

Aki

Quentin Armitage
 

On Tue, 2019-10-15 at 17:06 +0300, Aki Ketolainen wrote:
Hi,

I have a setup with 3 VMs in an IaaS cloud. I can set the IP address of 
eth2 interface
to any public IP address in my subscription. I'm using 10.255.255.1 as 
the virtual_ipaddress and
then setup eth2 with the floating IP address when transitioning to the 
master mode.
The eth1 interfaces are in the same vlan on the three VMs.

I've setup keepalived 1.3.5 on CentOS 7.7 with this configuration:

global_defs {
     enable_script_security
     script_user root
}

vrrp_script ping-vip {
     script       "/etc/keepalived/scripts/ping-vip"
     interval 15
     fall 2
     rise 2
}

vrrp_instance vip {
     state MASTER
     interface eth1
     virtual_router_id 1
     priority 3
     advert_int 1
     virtual_ipaddress {
         10.255.255.1/8 dev eth1
     }
     track_script {
         ping-vip
     }
     notify_master "/etc/keepalived/scripts/activate-vip INSTANCE vip 
MASTER"
     notify_backup "/etc/keepalived/scripts/activate-vip INSTANCE vip 
BACKUP"
     notify_fault "/etc/keepalived/scripts/activate-vip INSTANCE vip 
FAULT"
}

The contents of /etc/keepalived/scripts/ping-vip are:

#!/bin/bash

/usr/bin/ping -W 1 -c 1 10.0.0.1 >/dev/null 2>/dev/null
#/usr/bin/ping -W 1 -c 1 vip-address >/dev/null 2>/dev/null

if [ $? -ne 0 ]
then
     exit 1
else
     exit 0
fi

If i try to run "ping -W 1 -c 1 vip-address" in ping-vip, keepalived 
goes
straight to fault mode on startup, that's why I'm pinging 10.0.0.1 for 
now, it's
a local interface address.

The vip-address is managed by the master mode of keepalived so it's not 
available
right away, but should be up before 15 seconds I set for interval.

If I don't add the track_script into the keepalived.conf, keepalived 
starts into the master mode.

Could somebody show me what I'm doing wrong?

Best regards,

Aki


The track script has to run successfully before the VRRP instance can come up. Since initially the address is not configured, the script cannot be successful, and so the VRRP instance will not be able to transition out of fault state.

I'm not clear what you are trying to protect against with the track script. The only thing I can see that the script could be doing is detecting if someone deletes the 10.255.255.1 address, and the script then forces the VRRP instance into fault state until another VRRP instance takes over as master and so the ping is successful again. If that is what you want to achieve, then upgrade to a recent version of keepalived which detects the deletion of VIPs and they get automatically get reinstated.

I hope that helps,

Quentin Armitage

Aki Ketolainen
 

On 2019-10-15 19:19, Quentin Armitage wrote:

On Tue, 2019-10-15 at 17:06 +0300, Aki Ketolainen wrote:
Hi,

I have a setup with 3 VMs in an IaaS cloud. I can set the IP address of 
eth2 interface
to any public IP address in my subscription. I'm using 10.255.255.1 as 
the virtual_ipaddress and
then setup eth2 with the floating IP address when transitioning to the 
master mode.
The eth1 interfaces are in the same vlan on the three VMs.

I've setup keepalived 1.3.5 on CentOS 7.7 with this configuration:

global_defs {
     enable_script_security
     script_user root
}

vrrp_script ping-vip {
     script       "/etc/keepalived/scripts/ping-vip"
     interval 15
     fall 2
     rise 2
}

vrrp_instance vip {
     state MASTER
     interface eth1
     virtual_router_id 1
     priority 3
     advert_int 1
     virtual_ipaddress {
         10.255.255.1/8 dev eth1
     }
     track_script {
         ping-vip
     }
     notify_master "/etc/keepalived/scripts/activate-vip INSTANCE vip 
MASTER"
     notify_backup "/etc/keepalived/scripts/activate-vip INSTANCE vip 
BACKUP"
     notify_fault "/etc/keepalived/scripts/activate-vip INSTANCE vip 
FAULT"
}

The contents of /etc/keepalived/scripts/ping-vip are:

#!/bin/bash

/usr/bin/ping -W 1 -c 1 10.0.0.1 >/dev/null 2>/dev/null
#/usr/bin/ping -W 1 -c 1 vip-address >/dev/null 2>/dev/null

if [ $? -ne 0 ]
then
     exit 1
else
     exit 0
fi

If i try to run "ping -W 1 -c 1 vip-address" in ping-vip, keepalived 
goes
straight to fault mode on startup, that's why I'm pinging 10.0.0.1 for 
now, it's
a local interface address.

The vip-address is managed by the master mode of keepalived so it's not 
available
right away, but should be up before 15 seconds I set for interval.

If I don't add the track_script into the keepalived.conf, keepalived 
starts into the master mode.

Could somebody show me what I'm doing wrong?

Best regards,

Aki


The track script has to run successfully before the VRRP instance can come up. Since initially the address is not configured, the script cannot be successful, and so the VRRP instance will not be able to transition out of fault state.
 
I'm not clear what you are trying to protect against with the track script. The only thing I can see that the script could be doing is detecting if someone deletes the 10.255.255.1 address, and the script then forces the VRRP instance into fault state until another VRRP instance takes over as master and so the ping is successful again. If that is what you want to achieve, then upgrade to a recent version of keepalived which detects the deletion of VIPs and they get automatically get reinstated.
 
I hope that helps,
 
Quentin Armitage

Hi,

So I can run keepalived without the track_script and let keepalived move the vip to a keepalived backup node
if the master node goes away?

I also tested compiling a recent version of keepalived but would like to use the distro packaged version.

Thanks,

Aki


Quentin Armitage
 

On Tue, 2019-10-15 at 20:25 +0300, Aki Ketolainen wrote:

On 2019-10-15 19:19, Quentin Armitage wrote:

On Tue, 2019-10-15 at 17:06 +0300, Aki Ketolainen wrote:
Hi,

I have a setup with 3 VMs in an IaaS cloud. I can set the IP address of 
eth2 interface
to any public IP address in my subscription. I'm using 10.255.255.1 as 
the virtual_ipaddress and
then setup eth2 with the floating IP address when transitioning to the 
master mode.
The eth1 interfaces are in the same vlan on the three VMs.

I've setup keepalived 1.3.5 on CentOS 7.7 with this configuration:

global_defs {
     enable_script_security
     script_user root
}

vrrp_script ping-vip {
     script       "/etc/keepalived/scripts/ping-vip"
     interval 15
     fall 2
     rise 2
}

vrrp_instance vip {
     state MASTER
     interface eth1
     virtual_router_id 1
     priority 3
     advert_int 1
     virtual_ipaddress {
         10.255.255.1/8 dev eth1
     }
     track_script {
         ping-vip
     }
     notify_master "/etc/keepalived/scripts/activate-vip INSTANCE vip 
MASTER"
     notify_backup "/etc/keepalived/scripts/activate-vip INSTANCE vip 
BACKUP"
     notify_fault "/etc/keepalived/scripts/activate-vip INSTANCE vip 
FAULT"
}

The contents of /etc/keepalived/scripts/ping-vip are:

#!/bin/bash

/usr/bin/ping -W 1 -c 1 10.0.0.1 >/dev/null 2>/dev/null
#/usr/bin/ping -W 1 -c 1 vip-address >/dev/null 2>/dev/null

if [ $? -ne 0 ]
then
     exit 1
else
     exit 0
fi

If i try to run "ping -W 1 -c 1 vip-address" in ping-vip, keepalived 
goes
straight to fault mode on startup, that's why I'm pinging 10.0.0.1 for 
now, it's
a local interface address.

The vip-address is managed by the master mode of keepalived so it's not 
available
right away, but should be up before 15 seconds I set for interval.

If I don't add the track_script into the keepalived.conf, keepalived 
starts into the master mode.

Could somebody show me what I'm doing wrong?

Best regards,

Aki


The track script has to run successfully before the VRRP instance can come up. Since initially the address is not configured, the script cannot be successful, and so the VRRP instance will not be able to transition out of fault state.
 
I'm not clear what you are trying to protect against with the track script. The only thing I can see that the script could be doing is detecting if someone deletes the 10.255.255.1 address, and the script then forces the VRRP instance into fault state until another VRRP instance takes over as master and so the ping is successful again. If that is what you want to achieve, then upgrade to a recent version of keepalived which detects the deletion of VIPs and they get automatically get reinstated.
 
I hope that helps,
 
Quentin Armitage

Hi,

So I can run keepalived without the track_script and let keepalived move the vip to a keepalived backup node
if the master node goes away?

I also tested compiling a recent version of keepalived but would like to use the distro packaged version.

Thanks,

Aki


Aki,

Yes indeed, you don't need the track script; keepalived handles the adding and removing of the VIPs adding them
when a VRRP instance is master, and removing them when it is backup or in fault state.

Quentin

Aki Ketolainen
 

On 2019-10-15 20:32, Quentin Armitage wrote:

On Tue, 2019-10-15 at 20:25 +0300, Aki Ketolainen wrote:

On 2019-10-15 19:19, Quentin Armitage wrote:

On Tue, 2019-10-15 at 17:06 +0300, Aki Ketolainen wrote:
Hi,

I have a setup with 3 VMs in an IaaS cloud. I can set the IP address of 
eth2 interface
to any public IP address in my subscription. I'm using 10.255.255.1 as 
the virtual_ipaddress and
then setup eth2 with the floating IP address when transitioning to the 
master mode.
The eth1 interfaces are in the same vlan on the three VMs.

I've setup keepalived 1.3.5 on CentOS 7.7 with this configuration:

global_defs {
     enable_script_security
     script_user root
}

vrrp_script ping-vip {
     script       "/etc/keepalived/scripts/ping-vip"
     interval 15
     fall 2
     rise 2
}

vrrp_instance vip {
     state MASTER
     interface eth1
     virtual_router_id 1
     priority 3
     advert_int 1
     virtual_ipaddress {
         10.255.255.1/8 dev eth1
     }
     track_script {
         ping-vip
     }
     notify_master "/etc/keepalived/scripts/activate-vip INSTANCE vip 
MASTER"
     notify_backup "/etc/keepalived/scripts/activate-vip INSTANCE vip 
BACKUP"
     notify_fault "/etc/keepalived/scripts/activate-vip INSTANCE vip 
FAULT"
}

The contents of /etc/keepalived/scripts/ping-vip are:

#!/bin/bash

/usr/bin/ping -W 1 -c 1 10.0.0.1 >/dev/null 2>/dev/null
#/usr/bin/ping -W 1 -c 1 vip-address >/dev/null 2>/dev/null

if [ $? -ne 0 ]
then
     exit 1
else
     exit 0
fi

If i try to run "ping -W 1 -c 1 vip-address" in ping-vip, keepalived 
goes
straight to fault mode on startup, that's why I'm pinging 10.0.0.1 for 
now, it's
a local interface address.

The vip-address is managed by the master mode of keepalived so it's not 
available
right away, but should be up before 15 seconds I set for interval.

If I don't add the track_script into the keepalived.conf, keepalived 
starts into the master mode.

Could somebody show me what I'm doing wrong?

Best regards,

Aki


The track script has to run successfully before the VRRP instance can come up. Since initially the address is not configured, the script cannot be successful, and so the VRRP instance will not be able to transition out of fault state.
 
I'm not clear what you are trying to protect against with the track script. The only thing I can see that the script could be doing is detecting if someone deletes the 10.255.255.1 address, and the script then forces the VRRP instance into fault state until another VRRP instance takes over as master and so the ping is successful again. If that is what you want to achieve, then upgrade to a recent version of keepalived which detects the deletion of VIPs and they get automatically get reinstated.
 
I hope that helps,
 
Quentin Armitage

Hi,

So I can run keepalived without the track_script and let keepalived move the vip to a keepalived backup node
if the master node goes away?

I also tested compiling a recent version of keepalived but would like to use the distro packaged version.

Thanks,

Aki


Aki,
 
Yes indeed, you don't need the track script; keepalived handles the adding and removing of the VIPs adding them
when a VRRP instance is master, and removing them when it is backup or in fault state.
 
Quentin

Hi,

Is it possible to make keepalived move to the fault mode when I stop it with "systemctl stop keepalived" ?

I'm probably doing this wrong but I assign the eth2 VIP address through notify_master and now when I stop
keepalived, the eth2 VIP address doesn't get removed (I have the logic in notify_fault to put back the DHCP IP
for eth0 and remove the VIP address from eth2).

My eth0 interface is the default interface with DHCP but when I want to use the eth2 interface for the VIP,
I need to shut down eth0. This is some restriction from the IaaS cloud.

Thanks,

Aki


Quentin Armitage
 

On Tue, 2019-10-15 at 20:49 +0300, Aki Ketolainen wrote:

On 2019-10-15 20:32, Quentin Armitage wrote:

On Tue, 2019-10-15 at 20:25 +0300, Aki Ketolainen wrote:

On 2019-10-15 19:19, Quentin Armitage wrote:

On Tue, 2019-10-15 at 17:06 +0300, Aki Ketolainen wrote:
Hi,

I have a setup with 3 VMs in an IaaS cloud. I can set the IP address of 
eth2 interface
to any public IP address in my subscription. I'm using 10.255.255.1 as 
the virtual_ipaddress and
then setup eth2 with the floating IP address when transitioning to the 
master mode.
The eth1 interfaces are in the same vlan on the three VMs.

I've setup keepalived 1.3.5 on CentOS 7.7 with this configuration:

global_defs {
     enable_script_security
     script_user root
}

vrrp_script ping-vip {
     script       "/etc/keepalived/scripts/ping-vip"
     interval 15
     fall 2
     rise 2
}

vrrp_instance vip {
     state MASTER
     interface eth1
     virtual_router_id 1
     priority 3
     advert_int 1
     virtual_ipaddress {
         10.255.255.1/8 dev eth1
     }
     track_script {
         ping-vip
     }
     notify_master "/etc/keepalived/scripts/activate-vip INSTANCE vip 
MASTER"
     notify_backup "/etc/keepalived/scripts/activate-vip INSTANCE vip 
BACKUP"
     notify_fault "/etc/keepalived/scripts/activate-vip INSTANCE vip 
FAULT"
}

The contents of /etc/keepalived/scripts/ping-vip are:

#!/bin/bash

/usr/bin/ping -W 1 -c 1 10.0.0.1 >/dev/null 2>/dev/null
#/usr/bin/ping -W 1 -c 1 vip-address >/dev/null 2>/dev/null

if [ $? -ne 0 ]
then
     exit 1
else
     exit 0
fi

If i try to run "ping -W 1 -c 1 vip-address" in ping-vip, keepalived 
goes
straight to fault mode on startup, that's why I'm pinging 10.0.0.1 for 
now, it's
a local interface address.

The vip-address is managed by the master mode of keepalived so it's not 
available
right away, but should be up before 15 seconds I set for interval.

If I don't add the track_script into the keepalived.conf, keepalived 
starts into the master mode.

Could somebody show me what I'm doing wrong?

Best regards,

Aki


The track script has to run successfully before the VRRP instance can come up. Since initially the address is not configured, the script cannot be successful, and so the VRRP instance will not be able to transition out of fault state.
 
I'm not clear what you are trying to protect against with the track script. The only thing I can see that the script could be doing is detecting if someone deletes the 10.255.255.1 address, and the script then forces the VRRP instance into fault state until another VRRP instance takes over as master and so the ping is successful again. If that is what you want to achieve, then upgrade to a recent version of keepalived which detects the deletion of VIPs and they get automatically get reinstated.
 
I hope that helps,
 
Quentin Armitage

Hi,

So I can run keepalived without the track_script and let keepalived move the vip to a keepalived backup node
if the master node goes away?

I also tested compiling a recent version of keepalived but would like to use the distro packaged version.

Thanks,

Aki


Aki,
 
Yes indeed, you don't need the track script; keepalived handles the adding and removing of the VIPs adding them
when a VRRP instance is master, and removing them when it is backup or in fault state.
 
Quentin

Hi,

Is it possible to make keepalived move to the fault mode when I stop it with "systemctl stop keepalived" ?

I'm probably doing this wrong but I assign the eth2 VIP address through notify_master and now when I stop
keepalived, the eth2 VIP address doesn't get removed (I have the logic in notify_fault to put back the DHCP IP
for eth0 and remove the VIP address from eth2).

My eth0 interface is the default interface with DHCP but when I want to use the eth2 interface for the VIP,
I need to shut down eth0. This is some restriction from the IaaS cloud.

Thanks,

Aki


It isn't possible to transition via fault state when keepalived terminates, it would affect too many other users of keepalived. However using a notify_stop script will probably achieve what you want (see the man page keepalived.conf(5)).

Using scripts to assign/deassign VIPs isn't going to work reliably; after all it is keepalived's job to add and remove VIPs. The proper way to add a VIP on eth2 would be to specify it against the address:
vrrp_instance vrrp2 {
     interface eth1
     virtual_router_id 1
     priority 3
     advert_int 1
     virtual_ipaddress {
         10.11.12.13 dev eth2
     }

Quentin