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

Dear Paul,

I'm sorry for asking again, but using a check script for each VRRP instance
I'd like to enable/disable seems inefficient to me.
In addition I don't like my own suggestion of removing / adding the
complete instance from the config file.

Any other simple idea ?

Thanks!
Barak

On Tue, Jan 17, 2017 at 6:50 PM, Paul Robert Marino <[email protected]>
wrote:

> dont set it to 0 in the config use a vrrp check script to do it.
>
> On Tue, Jan 17, 2017 at 9:34 AM, barak adam <[email protected]> wrote:
>
>> 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