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

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