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

Many thanks for your detailed explanation about the Keepalived states.
-- To be on the safe side, I will remove this option from the configuration
file on production.
-- I will use the priority settings "enable" or "disable" a node...

Thanks again
Barak

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

> 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