Subject: Re: [VRRP] vrrp Digest, Vol 81, Issue 3

From: Thirumavalavan Periyannan <[email-masked]>
Date: Fri, 22 Feb 2013 19:26:08 +0530

Hi Anurag,

You meant to say that when we do graceful failover on VRRP Master then traffic needs switch to VRRP backup router without waiting for Master_Down_Interval time.

Please correct me if I am wrong.

Sent from my iPhone

On 22-Feb-2013, at 5:11 PM, "[email-masked]" <[email-masked]> wrote:

> If you have received this digest without all the individual message
> attachments you will need to update your digest options in your list
> subscription.  To do so, go to
>
> https://www.ietf.org/mailman/listinfo/vrrp
>
> Click the 'Unsubscribe or edit options' button, log in, and set "Get
> MIME or Plain Text Digests?" to MIME.  You can set this option
> globally for all the list digests you receive at this point.
>
>
>
> Send vrrp mailing list submissions to
>        [email-masked]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://www.ietf.org/mailman/listinfo/vrrp
> or, via email, send a message with subject or body 'help' to
>        [email-masked]
>
> You can reach the person managing the list at
>        [email-masked]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of vrrp digest..."
>
>
> Today's Topics:
>
>   1. Re: Proposal for Maintenance Event for VRRP [RFC-5798] (sreenatha)
>   2. Re: Proposal for Maintenance Event for VRRP [RFC-5798]
>      (Anurag Kothari (ankothar))
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 22 Feb 2013 09:55:35 +0530
> From: sreenatha <[email-masked]>
> To: "Anurag Kothari (ankothar)" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
>
> Hi Anurag,
>    Your proposal is:
>
> - If a Maintenance event is received, then:
>
> + Cancel the Adver_Timer
>
> + Send an ADVERTISEMENT with Priority = 0
>
> -endif // maintenance recv
>
>
>     And you mentioned that router need to send regular ADVERTISEMENT message till it receives the ADVERTISEMENT message from the backup router.
>
> "2. How much time Master router should wait to receive ADVERTISEMENT message from any backup router?
>
> [Anurag] Master doesn't have to wait. After receiving the maintenance event it will send regular ADVERTISEMENT with Priority = 0 till some other router send back an ADVERTISEMENT message at which point it will transition to Backup."
>
> If Advert_Timer is cancelled, how regular ADVERTISEMENT messages are sent?
>
> So i am suggesting slight changes in the Proposal:
>
> - If a Maintenance event is received, then:
>
> + Change the router priority to 0
>
> + Send an ADVERTISEMENT with Priority = 0
>
> + Reset the Adver_Timer
>
>  -endif // maintenance recv
>
> This will ensure that:
> 1. ADVERTISEMENT message with priority 0 is sent  immediately on receiving Maintenance event.
> 2. Master router will send regular Advertisement message till it receives the ADVERTISEMENT message from any backup routers.
>
> Thanks,
> Sreenatha Setty
>
>
>
>
> On 02/21/2013 10:12 PM, Anurag Kothari (ankothar) wrote:
>> Hi Sreenatha
>>
>> This ideas is based on the way the priority is defined in Section 5.2.4. and 6.1. of RFC-5798.
>>
>> "
>>    The priority value zero (0) has special meaning, indicating that the
>>    current Master has stopped participating in VRRP.  This is used to
>>    trigger Backup routers to quickly transition to Master without having
>>    to wait for the current Master to time out.
>> "
>>
>> "
>>    Priority              <snip>  The value of 0 (zero) is
>>                                reserved for the Master router to
>>                                indicate it is releasing responsibility
>>                                for the virtual router.  The range 1-254
>>                                (decimal) is available for VRRP routers
>>                                backing up the virtual router. <snip>
>> "
>>
>> Please see my responses inline [Anurag]:
>>
>> Thanks
>> -Anurag
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of sreenatha
>> Sent: Thursday, February 21, 2013 11:03 AM
>> To: [email-masked]
>> Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
>>
>> Hi Anurag,
>>      Proposed idea is good. I have some queries on this proposal:
>>
>> 1. On receiving new maintenance_event, priority of the router is not changed, right? So if back-up router has less priority, even if Master receives the ADVERTISEMENT from the backup router, Master will discard.
>> So how the Master router state is going to change?
>>
>> [Anurag] On receiving the maintenance event the priority of router (or VRID) will change to 0.
>>
>> 2. How much time Master router should wait to receive ADVERTISEMENT message from any backup router?
>>
>> [Anurag] Master doesn't have to wait. After receiving the maintenance event it will send regular ADVERTISEMENT with Priority = 0 till some other router send back an ADVERTISEMENT message at which point it will transition to Backup.
>>
>> 3. Standard VRRP MIB(RFC-2787) does not allow user to configure '0' for VRRP Priority. So you are proposing to change this value also?
>>
>> [Anurag] Yes. Priority 0 will have to be made a user configurable value to indicate the intention of a router to relinquish Master Status.
>>
>> Thanks,
>> Sreenatha Setty
>>
>> On 02/21/2013 01:30 AM, [email-masked] wrote:
>>> If you have received this digest without all the individual message
>>> attachments you will need to update your digest options in your list
>>> subscription.  To do so, go to
>>>
>>> https://www.ietf.org/mailman/listinfo/vrrp
>>>
>>> Click the 'Unsubscribe or edit options' button, log in, and set "Get
>>> MIME or Plain Text Digests?" to MIME.  You can set this option
>>> globally for all the list digests you receive at this point.
>>>
>>>
>>>
>>> Send vrrp mailing list submissions to
>>>     [email-masked]
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>     https://www.ietf.org/mailman/listinfo/vrrp
>>> or, via email, send a message with subject or body 'help' to
>>>     [email-masked]
>>>
>>> You can reach the person managing the list at
>>>     [email-masked]
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of vrrp digest..."
>>>
>>>
>>> Today's Topics:
>>>
>>>     1. Proposal for Maintenance Event for VRRP [RFC-5798]
>>>        (Anurag Kothari (ankothar))
>>>
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Tue, 19 Feb 2013 22:08:41 +0000
>>> From: "Anurag Kothari (ankothar)"<[email-masked]>
>>> To:"[email-masked]"  <[email-masked]>
>>> Subject: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
>>> Message-ID:
>>>     <[email-masked]>
>>> Content-Type: text/plain; charset="us-ascii"
>>>
>>> Hi
>>>
>>> I want to propose a new Maintenance Event (modification of Shutdown Event) for VRRP (RFC-5798] which would allow to gracefully failover the VRRP Master to Redundant (Backup Router).
>>>
>>> Problem Statement:
>>> VRRP preemption is not configured on the redundant / backup router.
>>> How to initiate VRRP Traffic to failover to the redundant / backup
>>> router gracefully without modifying the configuration on the redundant
>>> / backup router (i.e. adding preemption)
>>>
>>> Proposed Solution:
>>> Addition to Section 6.4.3 of RFC-5798:
>>>
>>> - If a Maintenance event is received, then:
>>>
>>> + Cancel the Adver_Timer
>>>
>>> + Send an ADVERTISEMENT with Priority = 0
>>>
>>> -endif // maintenance recv
>>>
>>> Unlike Shutdown event the router will not "Transition to the {Initialize} state" and continue to be Master and forward traffic  till the backup router sends an ADVERTISEMENT (triggered by receiving an ADVERTISEMENT with Priority = 0) and becomes master.
>>> Here are couple of examples of how a maintenance event may be
>>> triggered
>>>
>>>
>>> 1)      By some user command e.g. "maintenance-mode" in the vrrp configuration.
>>>
>>> 2)      By setting the priority = 0 for a particular VRID.
>>>
>>> Thanks
>>> -Anurag
>>>
>>> -------------- next part -------------- An HTML attachment was
>>> scrubbed...
>>> URL:<http://www.ietf.org/mail-archive/web/vrrp/attachments/20130219/36
>>> a6571f/attachment.htm>
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> vrrp mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/vrrp
>>>
>>>
>>> End of vrrp Digest, Vol 81, Issue 1
>>> ***********************************
>> Disclaimer :
>> This email communication may contain privileged and confidential information and is intended for the use of the addressee only.If you are not an intended recipient you are requested not to reproduce, copy disseminate or in any manner distribute this email communication as the same is strictly prohibited. If you have received this email in error, please notify the sender immediately by return e-mail and delete the communication sent in error. Email communications cannot be guaranteed to be secure & error free and IB Technology is not liable for any errors in the email communication or for the proper, timely and complete transmission thereof.
>>
>> _______________________________________________
>> vrrp mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/vrrp
>
> Disclaimer :
> This email communication may contain privileged and confidential information and is intended for the use of the addressee only.If you are not an intended recipient you are requested not to reproduce, copy disseminate or in any manner distribute this email communication as the same is strictly prohibited. If you have received this email in error, please notify the sender immediately by return e-mail and delete the communication sent in error. Email communications cannot be guaranteed to be secure & error free and IB Technology is not liable for any errors in the email communication or for the proper, timely and complete transmission thereof.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.ietf.org/mail-archive/web/vrrp/attachments/20130222/a56c0714/attachment.htm>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 22 Feb 2013 11:41:47 +0000
> From: "Anurag Kothari (ankothar)" <[email-masked]>
> To: sreenatha <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
> Message-ID:
>        <[email-masked]>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi Sreenatha
>
> My bad, by cancel I meant reset the timer.
>
> I would prefer defining maintenance event itself as (or being triggered by) priority being set to 0 for a VRID. So probably we can rephrase the proposal as:
>
>
> - If a Maintenance event is received, then:
>
>
>
> + Send an ADVERTISEMENT
>
>
>
> + Reset the Adver_Timer to Advertisement_Interval
>
>
>
> -endif // maintenance recv
>
> Thanks
> -Anurag
>
> From: sreenatha [mailto:[email-masked]]
> Sent: Thursday, February 21, 2013 11:26 PM
> To: Anurag Kothari (ankothar)
> Cc: [email-masked]
> Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
>
> Hi Anurag,
>   Your proposal is:
>
>
>
> - If a Maintenance event is received, then:
>
>
>
> + Cancel the Adver_Timer
>
>
>
> + Send an ADVERTISEMENT with Priority = 0
>
>
>
> -endif // maintenance recv
>
>
>
>
>
>    And you mentioned that router need to send regular ADVERTISEMENT message till it receives the ADVERTISEMENT message from the backup router.
>
>
>
> "2. How much time Master router should wait to receive ADVERTISEMENT message from any backup router?
>
>
>
> [Anurag] Master doesn't have to wait. After receiving the maintenance event it will send regular ADVERTISEMENT with Priority = 0 till some other router send back an ADVERTISEMENT message at which point it will transition to Backup."
>
>
>
> If Advert_Timer is cancelled, how regular ADVERTISEMENT messages are sent?
>
>
>
> So i am suggesting slight changes in the Proposal:
>
>
>
> - If a Maintenance event is received, then:
>
>
>
> + Change the router priority to 0
>
>
>
> + Send an ADVERTISEMENT with Priority = 0
>
>
>
> + Reset the Adver_Timer
>
>
>
> -endif // maintenance recv
>
>
>
> This will ensure that:
>
> 1. ADVERTISEMENT message with priority 0 is sent  immediately on receiving Maintenance event.
>
> 2. Master router will send regular Advertisement message till it receives the ADVERTISEMENT message from any backup routers.
>
>
>
> Thanks,
>
> Sreenatha Setty
>
>
>
>
>
>
> On 02/21/2013 10:12 PM, Anurag Kothari (ankothar) wrote:
>
> Hi Sreenatha
>
>
>
> This ideas is based on the way the priority is defined in Section 5.2.4. and 6.1. of RFC-5798.
>
>
>
> "
>
>   The priority value zero (0) has special meaning, indicating that the
>
>   current Master has stopped participating in VRRP.  This is used to
>
>   trigger Backup routers to quickly transition to Master without having
>
>   to wait for the current Master to time out.
>
> "
>
>
>
> "
>
>   Priority              <snip>  The value of 0 (zero) is
>
>                               reserved for the Master router to
>
>                               indicate it is releasing responsibility
>
>                               for the virtual router.  The range 1-254
>
>                               (decimal) is available for VRRP routers
>
>                               backing up the virtual router. <snip>
>
> "
>
>
>
> Please see my responses inline [Anurag]:
>
>
>
> Thanks
>
> -Anurag
>
>
>
> -----Original Message-----
>
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of sreenatha
>
> Sent: Thursday, February 21, 2013 11:03 AM
>
> To: [email-masked]<mailto:[email-masked]>
>
> Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
>
>
>
> Hi Anurag,
>
>     Proposed idea is good. I have some queries on this proposal:
>
>
>
> 1. On receiving new maintenance_event, priority of the router is not changed, right? So if back-up router has less priority, even if Master receives the ADVERTISEMENT from the backup router, Master will discard.
>
> So how the Master router state is going to change?
>
>
>
> [Anurag] On receiving the maintenance event the priority of router (or VRID) will change to 0.
>
>
>
> 2. How much time Master router should wait to receive ADVERTISEMENT message from any backup router?
>
>
>
> [Anurag] Master doesn't have to wait. After receiving the maintenance event it will send regular ADVERTISEMENT with Priority = 0 till some other router send back an ADVERTISEMENT message at which point it will transition to Backup.
>
>
>
> 3. Standard VRRP MIB(RFC-2787) does not allow user to configure '0' for VRRP Priority. So you are proposing to change this value also?
>
>
>
> [Anurag] Yes. Priority 0 will have to be made a user configurable value to indicate the intention of a router to relinquish Master Status.
>
>
>
> Thanks,
>
> Sreenatha Setty
>
>
>
> On 02/21/2013 01:30 AM, [email-masked]<mailto:[email-masked]> wrote:
>
> If you have received this digest without all the individual message
>
> attachments you will need to update your digest options in your list
>
> subscription.  To do so, go to
>
>
>
> https://www.ietf.org/mailman/listinfo/vrrp
>
>
>
> Click the 'Unsubscribe or edit options' button, log in, and set "Get
>
> MIME or Plain Text Digests?" to MIME.  You can set this option
>
> globally for all the list digests you receive at this point.
>
>
>
>
>
>
>
> Send vrrp mailing list submissions to
>
>   [email-masked]<mailto:[email-masked]>
>
>
>
> To subscribe or unsubscribe via the World Wide Web, visit
>
>   https://www.ietf.org/mailman/listinfo/vrrp
>
> or, via email, send a message with subject or body 'help' to
>
>   [email-masked]<mailto:[email-masked]>
>
>
>
> You can reach the person managing the list at
>
>   [email-masked]<mailto:[email-masked]>
>
>
>
> When replying, please edit your Subject line so it is more specific
>
> than "Re: Contents of vrrp digest..."
>
>
>
>
>
> Today's Topics:
>
>
>
>    1. Proposal for Maintenance Event for VRRP [RFC-5798]
>
>       (Anurag Kothari (ankothar))
>
>
>
>
>
> ----------------------------------------------------------------------
>
>
>
> Message: 1
>
> Date: Tue, 19 Feb 2013 22:08:41 +0000
>
> From: "Anurag Kothari (ankothar)"<[email-masked]><mailto:[email-masked]>
>
> To:"[email-masked]"<mailto:[email-masked]>  <[email-masked]><mailto:[email-masked]>
>
> Subject: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
>
> Message-ID:
>
>   <[email-masked]><mailto:[email-masked]>
>
> Content-Type: text/plain; charset="us-ascii"
>
>
>
> Hi
>
>
>
> I want to propose a new Maintenance Event (modification of Shutdown Event) for VRRP (RFC-5798] which would allow to gracefully failover the VRRP Master to Redundant (Backup Router).
>
>
>
> Problem Statement:
>
> VRRP preemption is not configured on the redundant / backup router.
>
> How to initiate VRRP Traffic to failover to the redundant / backup
>
> router gracefully without modifying the configuration on the redundant
>
> / backup router (i.e. adding preemption)
>
>
>
> Proposed Solution:
>
> Addition to Section 6.4.3 of RFC-5798:
>
>
>
> - If a Maintenance event is received, then:
>
>
>
> + Cancel the Adver_Timer
>
>
>
> + Send an ADVERTISEMENT with Priority = 0
>
>
>
> -endif // maintenance recv
>
>
>
> Unlike Shutdown event the router will not "Transition to the {Initialize} state" and continue to be Master and forward traffic  till the backup router sends an ADVERTISEMENT (triggered by receiving an ADVERTISEMENT with Priority = 0) and becomes master.
>
>
>
>
>
> Here are couple of examples of how a maintenance event may be
>
> triggered
>
>
>
>
>
> 1)      By some user command e.g. "maintenance-mode" in the vrrp configuration.
>
>
>
> 2)      By setting the priority = 0 for a particular VRID.
>
>
>
> Thanks
>
> -Anurag
>
>
>
> -------------- next part -------------- An HTML attachment was
>
> scrubbed...
>
> URL:<http://www.ietf.org/mail-archive/web/vrrp/attachments/20130219/36<http://www.ietf.org/mail-archive/web/vrrp/attachments/20130219/36a6571f/attachment.htm>
>
> a6571f/attachment.htm><http://www.ietf.org/mail-archive/web/vrrp/attachments/20130219/36a6571f/attachment.htm>
>
>
>
> ------------------------------
>
>
>
> _______________________________________________
>
> vrrp mailing list
>
> [email-masked]<mailto:[email-masked]>
>
> https://www.ietf.org/mailman/listinfo/vrrp
>
>
>
>
>
> End of vrrp Digest, Vol 81, Issue 1
>
> ***********************************
>
>
>
>
>
> Disclaimer :
>
> This email communication may contain privileged and confidential information and is intended for the use of the addressee only.If you are not an intended recipient you are requested not to reproduce, copy disseminate or in any manner distribute this email communication as the same is strictly prohibited. If you have received this email in error, please notify the sender immediately by return e-mail and delete the communication sent in error. Email communications cannot be guaranteed to be secure & error free and IB Technology is not liable for any errors in the email communication or for the proper, timely and complete transmission thereof.
>
>
>
> _______________________________________________
>
> vrrp mailing list
>
> [email-masked]<mailto:[email-masked]>
>
> https://www.ietf.org/mailman/listinfo/vrrp
>
>
>
>
> Disclaimer :
> This email communication may contain privileged and confidential information and is intended for the use of the addressee only.If you are not an intended recipient you are requested not to reproduce, copy disseminate or in any manner distribute this email communication as the same is strictly prohibited. If you have received this email in error, please notify the sender immediately by return e-mail and delete the communication sent in error. Email communications cannot be guaranteed to be secure & error free and IB Technology is not liable for any errors in the email communication or for the proper, timely and complete transmission thereof.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.ietf.org/mail-archive/web/vrrp/attachments/20130222/cdd2c4c7/attachment.htm>
>
> ------------------------------
>
> _______________________________________________
> vrrp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vrrp
>
>
> End of vrrp Digest, Vol 81, Issue 3
> ***********************************

DISCLAIMER:
This e-mail and any attachments to it may contain confidential and proprietary material and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient.  If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed.

---

From: "Anurag Kothari (ankothar)" <[email-masked]>
Date: Fri, 22 Feb 2013 15:55:47 +0000

Yes that is correct. 

The intention is to be able to switch the traffic to the backup router (with minimal traffic interruption) when preemption is not configured on the backup router without shutting down the interface or VRRP on Master.

Thanks
~Anurag

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thirumavalavan Periyannan
Sent: Friday, February 22, 2013 8:56 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [VRRP] vrrp Digest, Vol 81, Issue 3

Hi Anurag,

Sent from my iPhone

On 22-Feb-2013, at 5:11 PM, "[email-masked]" <[email-masked]> wrote:

>>> router gracefully without modifying the configuration on the 
>>> redundant / backup router (i.e. adding preemption)
>>>
>>> Proposed Solution:
> URL: 
> <http://www.ietf.org/mail-archive/web/vrrp/attachments/20130222/a56c07
> 14/attachment.htm>
>
> From: [email-masked]<mailto:[email-masked]> 
> [mailto:[email-masked]] On Behalf Of sreenatha
>
> From: "Anurag Kothari 
> (ankothar)"<[email-masked]><mailto:[email-masked]>
>
> <[email-masked]><mailt
> o:[email-masked]>
>

> <http://www.ietf.org/mail-archive/web/vrrp/attachments/20130219/36a657
> 1f/attachment.htm>
>
> URL: 
> <http://www.ietf.org/mail-archive/web/vrrp/attachments/20130222/cdd2c4
> c7/attachment.htm>
>

DISCLAIMER:

---

From: Peter Hunt <[email-masked]>
Date: Fri, 22 Feb 2013 08:58:54 -0800

Sorry to jump in here, but I'm having trouble understanding the motivation for the maintenance event.

It seems like its behaviour is to relinquish mastership immediately to a backup if it exists, but remain master silently otherwise. Is that correct?

If so, why is that desirable behaviour? It seems to me that you would either want to take the node out of the vrrp cluster completely, or have it participate at a reduced priority. What situation makes a silent-but-active master preferable?

Peter

---

From: "Anurag Kothari (ankothar)" <[email-masked]>
Date: Fri, 22 Feb 2013 17:29:38 +0000

Hi Peter

Please See my responses inline [Anurag]

Thanks
-Anurag

-----Original Message-----
From: Peter Hunt [mailto:[email-masked]] 
Sent: Friday, February 22, 2013 11:59 AM
To: Anurag Kothari (ankothar)
Cc: Thirumavalavan Periyannan; [email-masked]
Subject: Re: [VRRP] vrrp Digest, Vol 81, Issue 3

[Anurag] The master will not remain silent it will keep sending Advertisements with Priority = 0 until some backup router takes over as Master.

[Anurag] Many mobile service providers disable preemption for VRRP as they do not like the idea of unplanned traffic switch when a router with higher priority comes up. They only want traffic to switch in the event of a failure or as part of a planned activity in a maintenance window.
Now here is an example: A site has PE1 and PE2 configured to backup each other. Now if I want to perform any maintenance work on the say PE1 (Code upgrade / HW upgrade etc.) I want to take it out of the traffic path gracefully. Now the only way to Gracefully failover the traffic to PE2 is to configure preemption on it and reduce the priority on PE1 (or increase it on PE2) and remove it at the end of the maintenance work. But most service providers do not like the idea of touching (making changes to configuration) on both the boxes within the same maintenance window. So the idea here is to be able to failover the traffic to the backup router without enabling preemption on the Backup router.  If the backup router exists it will take over immediately if it doesn't exist the existing Master will continue to provide service. A lack of failover will indicate to the operator that backup is missing / not working and he will have to troubleshoot the situation. 

Peter

On Feb 22, 2013, at 7:55 AM, "Anurag Kothari (ankothar)" <[email-masked]> wrote:

>>  1. Re: Proposal for Maintenance Event for VRRP [RFC-5798] 
>> (sreenatha)  2. Re: Proposal for Maintenance Event for VRRP [RFC-5798]
>>>> attachments you will need to update your digest options in your 
>>>> list subscription.  To do so, go to
>>>> 
>>>> Click the 'Unsubscribe or edit options' button, log in, and set 
>>>> "Get MIME or Plain Text Digests?" to MIME.  You can set this option 
>>>> -------------------------------------------------------------------
>>>> -
>>>> --
>>>> 
>>>> Message: 1
>>>> URL:<http://www.ietf.org/mail-archive/web/vrrp/attachments/20130219
>>>> /
>>>> 36
>>>> a6571f/attachment.htm>
>>>> 
>> <[email-masked]><mail
>> t o:[email-masked]>
>> 
>> redundant
>> a6571f/attachment.htm><http://www.ietf.org/mail-archive/web/vrrp/atta
>> c hments/20130219/36a6571f/attachment.htm>
>> 
>> 
>>

---

From: Thirumavalavan Periyannan <[email-masked]>
Date: Fri, 22 Feb 2013 23:10:54 +0530

Hi Anurag,

If customer wants to do any maintenance work then they can do "disable vrrp" on MASTER Router which will generate VRRP Advertisement with "priority 0" and one among the backup router will become master based on the priority or higher interface IP addres.

Sent from my iPhone

DISCLAIMER:

---

From: "Anurag Kothari (ankothar)" <[email-masked]>
Date: Fri, 22 Feb 2013 19:26:35 +0000

Hi Thirumavalavan

Here are couple of points:

1) With something like "disable vrrp" or "shutdown vrrp" it will not be graceful as the router will treat it as a shutdown event (which is a break before you make approach) and the router will "Transition to the {Initialize} state". The backup router will wait for "Skew_Time" before it becomes master; So we probably will have traffic loss for a period approximately equal to "Skew_Time". Even with Default configuration this will be close to 609 ms which would be a duration long enough for to impact time sensitive applications (e.g. voice calls). For sure the actual failover time will depend upon the size of the Network and the switches in between but with the method proposed below we can try to improve that time.

2) This will also improve convergence in scenarios where we want the failover to trigger because of up uplink interface from the router going down (tracking interface and decrementing the priority).

I am not sure if you saw the modified proposal which was sent out today early morning. Here is the link to it in case you need it http://www.ietf.org/mail-archive/web/vrrp/current/msg01489.html

Thanks
~Anurag

-----Original Message-----
From: Thirumavalavan Periyannan [mailto:[email-masked]] 
Sent: Friday, February 22, 2013 12:41 PM
To: Anurag Kothari (ankothar)
Cc: Peter Hunt; [email-masked]
Subject: Re: [VRRP] vrrp Digest, Vol 81, Issue 3

Hi Anurag,

Sent from my iPhone

On 22-Feb-2013, at 10:59 PM, "Anurag Kothari (ankothar)" <[email-masked]> wrote:

>>> --------------------------------------------------------------------
>>> -
>>> -
>>>
>>> Message: 1
>>>>  The priority value zero (0) has special meaning, indicating that 
>>>> the  current Master has stopped participating in VRRP.  This is 
>>>> used to  trigger Backup routers to quickly transition to Master 
>>>> without having  to wait for the current Master to time out.
>>>> "
>>>>
>>>> "
>>>>> If you have received this digest without all the individual 
>>>>> message attachments you will need to update your digest options in 
>>>>> your list subscription.  To do so, go to
>>>>>
>>>>> "Get MIME or Plain Text Digests?" to MIME.  You can set this 
>>>>> option globally for all the list digests you receive at this point.
>>>>>
>>>>>
>>>>>
>>>>> When replying, please edit your Subject line so it is more 
>>>>> specific than "Re: Contents of vrrp digest..."
>>>>>
>>>>>
>>>>> Today's Topics:
>>>>>
>>> <http://www.ietf.org/mail-archive/web/vrrp/attachments/20130222/a56c
>>> 0
>>> 7
>>> 14/attachment.htm>
>>>
>>> --------------------------------------------------------------------
>>> -
>>> -
>>>
>>>
>>>
>>> Message: 1
>>>
>>> <[email-masked]><mai
>>> l t 
>>> URL:<http://www.ietf.org/mail-archive/web/vrrp/attachments/20130219/
>>> 3
>>> 6
>>> <http://www.ietf.org/mail-archive/web/vrrp/attachments/20130219/36a6
>>> 5
>>> 7
>>> 1f/attachment.htm>
>>>
>>> a6571f/attachment.htm><http://www.ietf.org/mail-archive/web/vrrp/att
>>> a c hments/20130219/36a6571f/attachment.htm>
>>>
>>>
>>>
>>> <http://www.ietf.org/mail-archive/web/vrrp/attachments/20130222/cdd2
>>> c
>>> 4
>>> c7/attachment.htm>
>>>

DISCLAIMER:

---

From: Thirumavalavan Periyannan <[email-masked]>
Date: Mon, 25 Feb 2013 20:37:37 +0530

Hi Anurag,

Sorry for the late response.

See the inline [Thiru]

Here, I have a question,

1.Do We have to configure priority Zero on Master router to do graceful failover?

Thanks & Regards,
Thirumavalavan Periyannan
Associate SQA Engineer  - VRRP Module Owner

-----Original Message-----
From: Anurag Kothari (ankothar) [mailto:[email-masked]]
Sent: Saturday, February 23, 2013 12:57 AM
To: Thirumavalavan Periyannan; [email-masked]
Cc: Peter Hunt
Subject: RE: [VRRP] vrrp Digest, Vol 81, Issue 3

Hi Thirumavalavan

1) With something like "disable vrrp" or "shutdown vrrp" it will not be graceful as the router will treat it as a shutdown event (which is a break before you make approach) and the router will "Transition to the {Initialize} state". The backup router will wait for "Skew_Time"[Thiru]I think, it's Master_Down_interval time. before it becomes master; So we probably will have traffic loss for a period approximately equal to "Skew_Time"[Thiru]I think, it's Master_Down_interval time. Even with Default configuration this will be close to 609 ms which would be a duration long enough for to impact time sensitive applications (e.g. voice calls). For sure the actual failover time will depend upon the size of the Network and the switches in between but with the method proposed below we can try to improve that time.

Thanks

~Anurag

________________________________
DISCLAIMER:
This e-mail and any attachments to it may contain confidential and proprietary material and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed.

---

From: "Anurag Kothari (ankothar)" <[email-masked]>
Date: Mon, 25 Feb 2013 15:13:40 +0000

Hi Thirumavalavan

The Master_Down_Timer is set to Skew_Time by the backup router on receiving an ADVERTISEMENT with Priority = 0. That is why I said will have to wait Skew_Time in the thread below. I am copy pasting the relevant section from the RFC for easy reference:

(420) - If an ADVERTISEMENT is received, then:

   (425) + If the Priority in the ADVERTISEMENT is zero, then:

      (430) * Set the Master_Down_Timer to Skew_Time

   (440) + else // priority non-zero

Yes the Priority on the Master router will have to be set to zero to initiate a graceful failover.

Thanks
-Anurag

From: Thirumavalavan Periyannan [mailto:[email-masked]]
Sent: Monday, February 25, 2013 10:08 AM
To: Anurag Kothari (ankothar); [email-masked]
Subject: RE: [VRRP] vrrp Digest, Vol 81, Issue 3

Hi Anurag,

See the inline [Thiru]

Here, I have a question,

Thanks & Regards,

[Description: Description: Description: Description: Description: Description: Description: Description: cid:[email-masked]]

-----Original Message-----
From: Anurag Kothari (ankothar) [mailto:[email-masked]]
Sent: Saturday, February 23, 2013 12:57 AM
To: Thirumavalavan Periyannan; [email-masked]<mailto:[email-masked]>
Cc: Peter Hunt
Subject: RE: [VRRP] vrrp Digest, Vol 81, Issue 3

Hi Thirumavalavan

Thanks

~Anurag

---

From: Thirumavalavan Periyannan <[email-masked]>
Date: Mon, 25 Feb 2013 21:49:21 +0530

Yes Anurag, I agree that backup router will reset Master_Down_timer value as Skew_Time and
It will be become master when Master_Down_timer fired and will send VRRP Advertisements with their own priority.

After VRRP Master elected, What could be the VRRP state of priority ZERO configured router? Is it Backup?

Thanks & Regards,

From: Anurag Kothari (ankothar) [mailto:[email-masked]]
Sent: Monday, February 25, 2013 8:44 PM
To: Thirumavalavan Periyannan; [email-masked]
Subject: RE: [VRRP] vrrp Digest, Vol 81, Issue 3

Hi Thirumavalavan

Thanks
-Anurag

Hi Anurag,

See the inline [Thiru]

Here, I have a question,

Thanks & Regards,

-----Original Message-----
From: Anurag Kothari (ankothar) [mailto:[email-masked]]
Sent: Saturday, February 23, 2013 12:57 AM
To: Thirumavalavan Periyannan; [email-masked]<mailto:[email-masked]>
Cc: Peter Hunt
Subject: RE: [VRRP] vrrp Digest, Vol 81, Issue 3

Hi Thirumavalavan

Thanks

~Anurag

---

From: "Anurag Kothari (ankothar)" <[email-masked]>
Date: Mon, 25 Feb 2013 16:24:44 +0000

Hi Thirumavalavan

Yes the priority zero router will become backup on receiving the ADVERTISEMENT from other router which would have transitioned to Master.

Thanks
-Anurag

From: Thirumavalavan Periyannan [mailto:[email-masked]]
Sent: Monday, February 25, 2013 11:19 AM
To: Anurag Kothari (ankothar); [email-masked]
Subject: RE: [VRRP] vrrp Digest, Vol 81, Issue 3

Thanks & Regards,

Hi Thirumavalavan

Thanks
-Anurag

From: Thirumavalavan Periyannan [mailto:[email-masked]]
Sent: Monday, February 25, 2013 10:08 AM
To: Anurag Kothari (ankothar); [email-masked]<mailto:[email-masked]>
Subject: RE: [VRRP] vrrp Digest, Vol 81, Issue 3

Hi Anurag,

See the inline [Thiru]

Here, I have a question,

Thanks & Regards,

-----Original Message-----
From: Anurag Kothari (ankothar) [mailto:[email-masked]]
Sent: Saturday, February 23, 2013 12:57 AM
To: Thirumavalavan Periyannan; [email-masked]<mailto:[email-masked]>
Cc: Peter Hunt
Subject: RE: [VRRP] vrrp Digest, Vol 81, Issue 3

Hi Thirumavalavan

Thanks

~Anurag