Re: How to configure / disable / enable a specific single VRRP instance

That's an interesting question‎, because it has an answer you wouldn't expect.

The name of the STATE parameter is a little misleading because it is overridden by the checks and VRRP elections. AssumedState would probably be a better name for it.

In production you should always have the state parameter set to BACKUP‎ on all nodes and allow VRRP elections to decide the state or you will get strange behavior on failovers (most commonly what I call the VIP YoYo effect where the VIP fails over where a node declaires itself MASTER in a heartbeat, takes over the VIP, then imitated the VIP goes back to where it was less than a second later due to the results of an election), in fact I believe it should be removed from the configuration entirely or at least ignored unless it's started in some sort of debuging mode. The state parameter is useful for testing election logic but not for any thing else, and can be very harmful if set by a user who doesn't know how it actually works. In template driven tools I've written in the past to manage keepalived configurations, I've always hidden that option from the user. Most switches I've seen do not present the option either because it can become a major support issue. I don't think the writers of the RFC ever intended any implementation to present it as a user configurable option either.

Instead what you should use is a VRRP check script and have it drop the priority by more than 50 ( - recommend 50 + nodes count +1) on failure.‎ The reason for this is that a differential of more than 50 in the priority of a node forces that node to backup regardless of the nopreempt option. Also a priority of 0 is a FAULT state in VRRP. This is all very clearly layed out in the RFC's which describe VRRP.

From: barak adam

Sent: Tuesday, January 10, 2017 09:22

To: [email protected]

Cc: [email protected]

Subject: Re: [Keepalived-devel] How to configure / disable / enable a specific single VRRP instance

1) Regarding the exception you have mentioned of reload the master first for adds and the backup first for removes - I am wondering how can I control it while programming our router SW? I mean, I can't force / control a user to make a reload on another router in case my router should not be the first...

2) Anyway, I am still not sure how to disable a specific virtual router instance. Simply set its state to FAULT in the config file and reload (pkill -HUP)?

Thanks!

Barak

On Tue, Jan 10, 2017 at 2:23 PM, <[email protected] > wrote:

Send the keepalived process a HUP signal that will reload the configuration, and in most cases will not effect the state.

"

pkill -HUP keepalived

"

‎The exception is when you add or remove items from a group such as a VRRP group (multiple VRRP instances that failover together) you have to be careful about the order in which you reload nodes or you can cause an accidental failover. On adds always reload the master node first, on removes always reload the backup node first

From: barak adam

Sent: Tuesday, January 10, 2017 03:11

To: [email protected]

Subject: [Keepalived-devel] How to configure / disable / enable a specific single VRRP instance

Guys,

My question is on VRRP only.

How can I set the configuration file and reload it, so it will affect only one VRRP instance and without affecting the other running VRRP instances ?

Does any Keepalived configuration reloading affect all instances ?

Thanks!

Barak

------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi

_______________________________________________
Keepalived-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/keepalived-devel