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

Dear Paul

Unfortunately set the priority to '0', didn't cause a VRRP instance to go
into FAULT state, but caused the priority to have a default value of 100.
Unless I will have some other 'trick', I'll just add/remove a VRRP instance
in/out of the configuration file in order to totally enable/disable an
instance.
(I've also thought of using a check script that will return KO for
disabling and OK for enabling, but it seems to me inefficient and make no
sense to do it that way instead of just add/remove it out of the config
file).

Thanks,
Barak


On Thu, Jan 12, 2017 at 6:32 AM, barak adam <[email protected]> wrote:

> 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
>>>
>>>
>>
>>
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot

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