Proposal for Maintenance Event for VRRP [RFC-5798]

Discussion:

Anurag Kothari (ankothar)

2013-02-19 22:08:41 UTC

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

sreenatha

2013-02-21 16:03:16 UTC

Permalink

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?

2. How much time Master router should wait to receive ADVERTISEMENT
message from any backup router?

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?

Thanks,
Sreenatha Setty

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
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
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of vrrp digest..."
1. Proposal for Maintenance Event for VRRP [RFC-5798]
(Anurag Kothari (ankothar))
----------------------------------------------------------------------
Message: 1
Date: Tue, 19 Feb 2013 22:08:41 +0000
Subject: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
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).
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)
+ 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/36a6571f/attachment.htm>
------------------------------
_______________________________________________
vrrp mailing list
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.

Anurag Kothari (ankothar)

2013-02-21 16:42:58 UTC

Permalink

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: vrrp-***@ietf.org [mailto:vrrp-***@ietf.org] On Behalf Of sreenatha
Sent: Thursday, February 21, 2013 11:03 AM
To: ***@ietf.org
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

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
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
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of vrrp digest..."
1. Proposal for Maintenance Event for VRRP [RFC-5798]
(Anurag Kothari (ankothar))
----------------------------------------------------------------------
Message: 1
Date: Tue, 19 Feb 2013 22:08:41 +0000
Subject: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
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).
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)
+ 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
https://www.ietf.org/mailman/listinfo/vrrp
End of vrrp Digest, Vol 81, Issue 1
***********************************

sreenatha

2013-02-22 04:25:35 UTC

Permalink

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

Post by Anurag Kothari (ankothar)
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>
"
Thanks
-Anurag
-----Original Message-----
Sent: Thursday, February 21, 2013 11:03 AM
Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
Hi Anurag,
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

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
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
You can reach the person managing the list at
When replying, please edit your Subject line so it is more specific
than "Re: Contents of vrrp digest..."
1. Proposal for Maintenance Event for VRRP [RFC-5798]
(Anurag Kothari (ankothar))
----------------------------------------------------------------------
Message: 1
Date: Tue, 19 Feb 2013 22:08:41 +0000
Subject: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
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).
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)
+ 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
https://www.ietf.org/mailman/listinfo/vrrp
End of vrrp Digest, Vol 81, Issue 1
***********************************

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
https://www.ietf.org/mailman/listinfo/vrrp

Anurag Kothari (ankothar)

2013-02-22 11:41:47 UTC

Permalink

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:***@ibtechnology.com]
Sent: Thursday, February 21, 2013 11:26 PM
To: Anurag Kothari (ankothar)
Cc: ***@ietf.org
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: vrrp-***@ietf.org<mailto:vrrp-***@ietf.org> [mailto:vrrp-***@ietf.org] On Behalf Of sreenatha

Sent: Thursday, February 21, 2013 11:03 AM

To: ***@ietf.org<mailto:***@ietf.org>

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, vrrp-***@ietf.org<mailto:vrrp-***@ietf.org> 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

***@ietf.org<mailto:***@ietf.org>

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

vrrp-***@ietf.org<mailto:vrrp-***@ietf.org>

You can reach the person managing the list at

vrrp-***@ietf.org<mailto:vrrp-***@ietf.org>

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)"<***@cisco.com><mailto:***@cisco.com>

To:"***@ietf.org"<mailto:***@ietf.org> <***@ietf.org><mailto:***@ietf.org>

Subject: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]

Message-ID:

<***@xmb-rcd-x05.cisco.com><mailto:***@xmb-rcd-x05.cisco.com>

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

***@ietf.org<mailto:***@ietf.org>

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

***@ietf.org<mailto:***@ietf.org>

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.

Anurag Kothari (ankothar)

2013-02-22 12:08:55 UTC

Permalink

On Further Thought:

We may want to define maintenance event (probably rename it "Priority Change Event") being triggered by a change in priority for a VRID (including dynamic changes to the priority e.g. changes due to tracking interface).

This would make it more generic. Whenever the user configures priority = 0 (which will have to be allowed) it would trigger a failover to the backup router.

Thanks
-Anurag

From: vrrp-***@ietf.org [mailto:vrrp-***@ietf.org] On Behalf Of Anurag Kothari (ankothar)
Sent: Friday, February 22, 2013 6:42 AM
To: sreenatha
Cc: ***@ietf.org
Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]

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:***@ibtechnology.com]
Sent: Thursday, February 21, 2013 11:26 PM
To: Anurag Kothari (ankothar)
Cc: ***@ietf.org<mailto:***@ietf.org>
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: vrrp-***@ietf.org<mailto:vrrp-***@ietf.org> [mailto:vrrp-***@ietf.org] On Behalf Of sreenatha

Sent: Thursday, February 21, 2013 11:03 AM

To: ***@ietf.org<mailto:***@ietf.org>

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, vrrp-***@ietf.org<mailto:vrrp-***@ietf.org> 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

***@ietf.org<mailto:***@ietf.org>

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

vrrp-***@ietf.org<mailto:vrrp-***@ietf.org>

You can reach the person managing the list at

vrrp-***@ietf.org<mailto:vrrp-***@ietf.org>

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)"<***@cisco.com><mailto:***@cisco.com>

To:"***@ietf.org"<mailto:***@ietf.org> <***@ietf.org><mailto:***@ietf.org>

Subject: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]

Message-ID:

<***@xmb-rcd-x05.cisco.com><mailto:***@xmb-rcd-x05.cisco.com>

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

***@ietf.org<mailto:***@ietf.org>

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

***@ietf.org<mailto:***@ietf.org>

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.

Anurag Kothari (ankothar)

2013-02-26 15:13:51 UTC

Permalink

Some concerns have been raised regarding the following situation / Corner Case:
Due to congestion or some other fault in the network the ADVERTISEMENTs from the Master router do not reach backup router(s). The Master_Down_timer fires and one of the back router transitions to Master State at the same time the priority of this router and the original Master is set to zero. How would the network behave in this case?

For sure the probability of this happening would be very low (as it is a double/multiple fault situation). Here is my analysis of the situation and solution for the same.

We will have two Master routers both sending ADVERTISEMENTs with Priority = 0. This will create a vicious circle of sending ADVERTISEMENTs (one router triggering the other) at a fast rate. This would also cause the Virtual MAC to shuttle continuously between two ports on the switch(es) at a fast rate. Both of these can probably cause high CPU utilization on the router and the LAN Switches.

If there is an additional backup router available then it will become master on seeing the first Advertisement with Priority = 0 and both the Masters (with priority = 0) will transition to Backup on seeing the advertisement with non-zero priority from the new Master.

For the situation where we do not have an additional backup router we can avoid this by making following modifications (Differences from RFC-5798 highlighted in RED):

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

(705) -+ If the Priority in the ADVERTISEMENT is zero,

(701) -+ and

(702) -+ Local Priority is greater than zero, then:

(710) -* Send an ADVERTISEMENT

(715) -* Reset the Adver_Timer to Advertisement_Interval

(720) -+ else // priority was non-zero or local priority was zero

(725) -* If the Priority in the ADVERTISEMENT is greater
than the local Priority,

(730) -* or

(735) -* If the Priority in the ADVERTISEMENT is equal to
the local Priority and the primary IPvX Address of the
sender is greater than the local primary IPvX Address, then:

(740) -@ Cancel Adver_Timer

(745) -@ Set Master_Adver_Interval to Adver Interval
contained in the ADVERTISEMENT

(750) -@ Recompute the Skew_Time

(755) @ Recompute the Master_Down_Interval

(760) @ Set Master_Down_Timer to Master_Down_Interval

(765) @ Transition to the {Backup} state

(770) * else // new Master logic

(775) @ Discard ADVERTISEMENT

(780) *endif // new Master detected

(785) +endif // was priority zero?

(790) -endif // advert recv

Please let me know if I have missed something.

Thanks
-Anurag

sreenatha

2013-02-28 16:38:45 UTC

Permalink

Hi Anurag,
Modification to algorithm is correct. But this modification is
taking care only when Router is in Master state.
What about if Backup router(priority value is zero) receives
ADVERTISEMENT message with priority value as zero?

Same condition we will consider, where both VRRP routers priority is set
to zero, and both sending ADVERTISEMENT messages with priority as zero.
According to new modification any one router, lets take "Router A", will
remain in Master state and other router, lets say "Router B", will
transit to Backup state.

Now according to RFC-5798:
When "Router B" is in Backup state,

(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

So this lead to Master_Down_Timer to expire soon.

Again in Backup state,
(365) - If the Master_Down_Timer fires, then:

(370) + Send an ADVERTISEMENT
|
|
...

(405) + Set the Adver_Timer to Advertisement_Interval

(410) + Transition to the {Master} state

(415) -endif // Master_Down_Timer fire

So this lead to continuous switch over from Backup to Master state and vice verse state transitions in "Router B".

To avoid this condition,
In Backup state also we need to do modification. Same as you suggested in Master state, same extra condition we need to check in Backup state also.
Modifications in Backup state as follows(Differences from RFC-5798 highlighted with Underline):

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

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

_(421) -+ and_

_(422) -+ Local Priority is greater than zero, then:_

(430) * Set the Master_Down_Timer to Skew_Time

(440) + else // priority non-zero or local-priority is zero
(Continue other logic)

This will avoid state-transition flip-flap problem in "Router B".

Thanks,
Sreenatha Setty

Post by Anurag Kothari (ankothar)
Due to congestion or some other fault in the network the ADVERTISEMENTs from the Master router do not reach backup router(s). The Master_Down_timer fires and one of the back router transitions to Master State at the same time the priority of this router and the original Master is set to zero. How would the network behave in this case?
For sure the probability of this happening would be very low (as it is a double/multiple fault situation). Here is my analysis of the situation and solution for the same.
We will have two Master routers both sending ADVERTISEMENTs with Priority = 0. This will create a vicious circle of sending ADVERTISEMENTs (one router triggering the other) at a fast rate. This would also cause the Virtual MAC to shuttle continuously between two ports on the switch(es) at a fast rate. Both of these can probably cause high CPU utilization on the router and the LAN Switches.
If there is an additional backup router available then it will become master on seeing the first Advertisement with Priority = 0 and both the Masters (with priority = 0) will transition to Backup on seeing the advertisement with non-zero priority from the new Master.
(705) -+ If the Priority in the ADVERTISEMENT is zero,
(701) -+ and
(710) -* Send an ADVERTISEMENT
(715) -* Reset the Adver_Timer to Advertisement_Interval
(720) -+ else // priority was non-zero or local priority was zero
(725) -* If the Priority in the ADVERTISEMENT is greater
than the local Priority,
(730) -* or
(735) -* If the Priority in the ADVERTISEMENT is equal to
the local Priority and the primary IPvX Address of the
contained in the ADVERTISEMENT
(770) * else // new Master logic
(780) *endif // new Master detected
(785) +endif // was priority zero?
(790) -endif // advert recv
Please let me know if I have missed something.
Thanks
-Anurag
-------------- next part --------------
An HTML attachment was scrubbed...
URL:<http://www.ietf.org/mail-archive/web/vrrp/attachments/20130226/cc6018e8/attachment.htm>
------------------------------
_______________________________________________
vrrp mailing list
https://www.ietf.org/mailman/listinfo/vrrp
End of vrrp Digest, Vol 81, Issue 10
************************************

Anurag Kothari (ankothar)

2013-02-28 20:01:29 UTC

Permalink

Hi Sreenatha

Totally agree with your observation.

Also as pointed out by some other participants the additional backup router in my original analysis will never become master on seeing the first ADVERTISEMENT with priority zero as it will keep resetting it's Master_Down_Timer to Skew_Time in the storm of ADVERTISEMENTs with zero priority and the Master_Down_Timer will never fire for the additional backup router.

Thanks
-Anurag

P.S. Noticed the typos: the additional lines in my email should be numbered 706 and 707 (instead of 701 and 702) and probably yours should be 426 and 427 (instead of 421 and 422).

From: sreenatha [mailto:***@ibtechnology.com]
Sent: Thursday, February 28, 2013 11:39 AM
To: ***@ietf.org
Cc: Anurag Kothari (ankothar)
Subject: Re: Proposal for Maintenance Event for VRRP [RFC-5798]

Hi Anurag,
Modification to algorithm is correct. But this modification is taking care only when Router is in Master state.
What about if Backup router(priority value is zero) receives ADVERTISEMENT message with priority value as zero?

Same condition we will consider, where both VRRP routers priority is set to zero, and both sending ADVERTISEMENT messages with priority as zero. According to new modification any one router, lets take "Router A", will remain in Master state and other router, lets say "Router B", will transit to Backup state.

Now according to RFC-5798:
When "Router B" is in Backup state,

(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

So this lead to Master_Down_Timer to expire soon.

Again in Backup state,

(365) - If the Master_Down_Timer fires, then:

(370) + Send an ADVERTISEMENT

|

|

...

(405) + Set the Adver_Timer to Advertisement_Interval

(410) + Transition to the {Master} state

(415) -endif // Master_Down_Timer fire

So this lead to continuous switch over from Backup to Master state and vice verse state transitions in "Router B".

To avoid this condition,

In Backup state also we need to do modification. Same as you suggested in Master state, same extra condition we need to check in Backup state also.

Modifications in Backup state as follows(Differences from RFC-5798 highlighted with Underline):

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

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

(421) -+ and

(422) -+ Local Priority is greater than zero, then:

(430) * Set the Master_Down_Timer to Skew_Time

(440) + else // priority non-zero or local-priority is zero

(Continue other logic)

This will avoid state-transition flip-flap problem in "Router B".

Thanks,

Sreenatha Setty

On 02/27/2013 01:30 AM, vrrp-***@ietf.org<mailto:vrrp-***@ietf.org> wrote:

Some concerns have been raised regarding the following situation / Corner Case:

Due to congestion or some other fault in the network the ADVERTISEMENTs from the Master router do not reach backup router(s). The Master_Down_timer fires and one of the back router transitions to Master State at the same time the priority of this router and the original Master is set to zero. How would the network behave in this case?

For sure the probability of this happening would be very low (as it is a double/multiple fault situation). Here is my analysis of the situation and solution for the same.

We will have two Master routers both sending ADVERTISEMENTs with Priority = 0. This will create a vicious circle of sending ADVERTISEMENTs (one router triggering the other) at a fast rate. This would also cause the Virtual MAC to shuttle continuously between two ports on the switch(es) at a fast rate. Both of these can probably cause high CPU utilization on the router and the LAN Switches.

If there is an additional backup router available then it will become master on seeing the first Advertisement with Priority = 0 and both the Masters (with priority = 0) will transition to Backup on seeing the advertisement with non-zero priority from the new Master.

For the situation where we do not have an additional backup router we can avoid this by making following modifications (Differences from RFC-5798 highlighted in RED):

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

(705) -+ If the Priority in the ADVERTISEMENT is zero,

(701) -+ and

(702) -+ Local Priority is greater than zero, then:

(710) -* Send an ADVERTISEMENT

(715) -* Reset the Adver_Timer to Advertisement_Interval

(720) -+ else // priority was non-zero or local priority was zero

(725) -* If the Priority in the ADVERTISEMENT is greater

than the local Priority,

(730) -* or

(735) -* If the Priority in the ADVERTISEMENT is equal to

the local Priority and the primary IPvX Address of the

sender is greater than the local primary IPvX Address, then:

(740) -@ Cancel Adver_Timer

(745) -@ Set Master_Adver_Interval to Adver Interval

contained in the ADVERTISEMENT

(750) -@ Recompute the Skew_Time

(755) @ Recompute the Master_Down_Interval

(760) @ Set Master_Down_Timer to Master_Down_Interval

(765) @ Transition to the {Backup} state

(770) * else // new Master logic

(775) @ Discard ADVERTISEMENT

(780) *endif // new Master detected

(785) +endif // was priority zero?

(790) -endif // advert recv

Please let me know if I have missed something.

Thanks

-Anurag

-------------- next part --------------

An HTML attachment was scrubbed...

URL: <http://www.ietf.org/mail-archive/web/vrrp/attachments/20130226/cc6018e8/attachment.htm><http://www.ietf.org/mail-archive/web/vrrp/attachments/20130226/cc6018e8/attachment.htm>

------------------------------

_______________________________________________

vrrp mailing list

***@ietf.org<mailto:***@ietf.org>

https://www.ietf.org/mailman/listinfo/vrrp

End of vrrp Digest, Vol 81, Issue 10

************************************

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.

sreenatha

2013-03-01 05:02:37 UTC

Permalink

Hi Anurag,
One more point on original proposal of handling Maintenance Event.

Whether "Maintenance_Event" from user is allowed only in Master state or
any other state?

If Maintenance_Event comes in other state(Init or Backup) apart from the
Master state, what would be the behaviour of the router?

This point also we need to take care.

Thanks,
Sreenatha Setty

Post by Anurag Kothari (ankothar)
Hi Sreenatha
Totally agree with your observation.
Also as pointed out by some other participants the additional backup
router in my original analysis will never become master on seeing the
first ADVERTISEMENT with priority zero as it will keep resetting it's
Master_Down_Timer to Skew_Time in the storm of ADVERTISEMENTs with
zero priority and the Master_Down_Timer will never fire for the
additional backup router.
Thanks
-Anurag
P.S. Noticed the typos: the additional lines in my email should be
numbered 706 and 707 (instead of 701 and 702) and probably yours
should be 426 and 427 (instead of 421 and 422).
*Sent:* Thursday, February 28, 2013 11:39 AM
*Cc:* Anurag Kothari (ankothar)
*Subject:* Re: Proposal for Maintenance Event for VRRP [RFC-5798]
Hi Anurag,
Modification to algorithm is correct. But this modification is
taking care only when Router is in Master state.
What about if Backup router(priority value is zero) receives
ADVERTISEMENT message with priority value as zero?
Same condition we will consider, where both VRRP routers priority is
set to zero, and both sending ADVERTISEMENT messages with priority as
zero. According to new modification any one router, lets take "Router
A", will remain in Master state and other router, lets say "Router B",
will transit to Backup state.
When "Router B" is in Backup state,
(430) * Set the Master_Down_Timer to Skew_Time
(440) + else // priority non-zero
So this lead to Master_Down_Timer to expire soon.
Again in Backup state,
(370) + Send an ADVERTISEMENT
|
|
...
(405) + Set the Adver_Timer to Advertisement_Interval
(410) + Transition to the {Master} state
(415) -endif // Master_Down_Timer fire
So this lead to continuous switch over from Backup to Master state and vice verse state transitions in "Router B".
To avoid this condition,
In Backup state also we need to do modification. Same as you suggested in Master state, same extra condition we need to check in Backup state also.
(425) + If the Priority in the ADVERTISEMENT is zero,
_(421) -+ and_
_(422) -+ Local Priority is greater than zero, then:_
(430) * Set the Master_Down_Timer to Skew_Time
(440) + else // priority non-zero or local-priority is zero
(Continue other logic)
This will avoid state-transition flip-flap problem in "Router B".
Thanks,
Sreenatha Setty
Due to congestion or some other fault in the network the ADVERTISEMENTs from the Master router do not reach backup router(s). The Master_Down_timer fires and one of the back router transitions to Master State at the same time the priority of this router and the original Master is set to zero. How would the network behave in this case?
For sure the probability of this happening would be very low (as it is a double/multiple fault situation). Here is my analysis of the situation and solution for the same.
We will have two Master routers both sending ADVERTISEMENTs with Priority = 0. This will create a vicious circle of sending ADVERTISEMENTs (one router triggering the other) at a fast rate. This would also cause the Virtual MAC to shuttle continuously between two ports on the switch(es) at a fast rate. Both of these can probably cause high CPU utilization on the router and the LAN Switches.
If there is an additional backup router available then it will become master on seeing the first Advertisement with Priority = 0 and both the Masters (with priority = 0) will transition to Backup on seeing the advertisement with non-zero priority from the new Master.
(705) -+ If the Priority in the ADVERTISEMENT is zero,
(701) -+ and
(710) -* Send an ADVERTISEMENT
(715) -* Reset the Adver_Timer to Advertisement_Interval
(720) -+ else // priority was non-zero or local priority was zero
(725) -* If the Priority in the ADVERTISEMENT is greater
than the local Priority,
(730) -* or
(735) -* If the Priority in the ADVERTISEMENT is equal to
the local Priority and the primary IPvX Address of the
contained in the ADVERTISEMENT
(770) * else // new Master logic
(780) *endif // new Master detected
(785) +endif // was priority zero?
(790) -endif // advert recv
Please let me know if I have missed something.
Thanks
-Anurag
-------------- next part --------------
An HTML attachment was scrubbed...
URL:<http://www.ietf.org/mail-archive/web/vrrp/attachments/20130226/cc6018e8/attachment.htm> <http://www.ietf.org/mail-archive/web/vrrp/attachments/20130226/cc6018e8/attachment.htm>
------------------------------
_______________________________________________
vrrp mailing list
https://www.ietf.org/mailman/listinfo/vrrp
End of vrrp Digest, Vol 81, Issue 10
************************************
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.

Anurag Kothari (ankothar)

2013-03-01 15:01:42 UTC

Permalink

Hi Sreenatha

I don't think we need to define a "Maintenance_Event" when the router is in either Init or Backup State. The intention of the "Maintenance_Event" is to trigger a failover from "Master" to a "Backup" router as soon as possible (especially when preemption is not configured).

But if you are asking if priority = 0 should be allowed (either by user configuration or dynamically) when the router is in "Init" or "Backup" state then I think the answer should be yes, It should be treated just like any other change in priority is treated when the router is in these states.

Please let me know if I am missing something.

Thanks
-Anurag

From: sreenatha [mailto:***@ibtechnology.com]
Sent: Friday, March 01, 2013 12:03 AM
To: Anurag Kothari (ankothar)
Cc: ***@ietf.org
Subject: Re: Proposal for Maintenance Event for VRRP [RFC-5798]

Hi Anurag,
    One more point on original proposal of handling Maintenance Event.

Whether "Maintenance_Event" from user is allowed only in Master state or any other state?

If Maintenance_Event comes in other state(Init or Backup) apart from the Master state, what would be the behaviour of the router?

This point also we need to take care.

Thanks,
Sreenatha Setty

On 03/01/2013 01:31 AM, Anurag Kothari (ankothar) wrote:
Hi Sreenatha

Totally agree with your observation.

Also as pointed out by some other participants the additional backup router in my original analysis will never become master on seeing the first ADVERTISEMENT with priority zero as it will keep resetting it's Master_Down_Timer to Skew_Time in the storm of ADVERTISEMENTs with zero priority and the Master_Down_Timer will never fire for the additional backup router.

Thanks
-Anurag

P.S. Noticed the typos: the additional lines in my email should be numbered 706 and 707 (instead of 701 and 702) and probably yours should be 426 and 427 (instead of 421 and 422).

From: sreenatha [mailto:***@ibtechnology.com]
Sent: Thursday, February 28, 2013 11:39 AM
To: ***@ietf.org
Cc: Anurag Kothari (ankothar)
Subject: Re: Proposal for Maintenance Event for VRRP [RFC-5798]

Hi Anurag,
    Modification to algorithm is correct. But this modification is taking care only when Router is in Master state.
What about if Backup router(priority value is zero) receives ADVERTISEMENT message with priority value as zero?

Same condition we will consider, where both VRRP routers priority is set to zero, and both sending ADVERTISEMENT messages with priority as zero. According to new modification any one router, lets take "Router A", will remain in Master state and other router, lets say "Router B", will transit to Backup state.

Now according to RFC-5798:
When "Router B" is in Backup state,
(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

So this lead to Master_Down_Timer to expire soon.

Again in Backup state,
(365) - If the Master_Down_Timer fires, then:

         (370) + Send an ADVERTISEMENT
                    |
                    |
                    ...

         (405) + Set the Adver_Timer to Advertisement_Interval

         (410) + Transition to the {Master} state

(415) -endif // Master_Down_Timer fire

So this lead to continuous switch over from Backup to Master state and vice verse state transitions in "Router B".

To avoid this condition,
In Backup state also we need to do modification. Same as you suggested in Master state, same extra condition we need to check in Backup state also.
Modifications in Backup state as follows(Differences from RFC-5798 highlighted with Underline):

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

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

         (421) -+ and

         (422) -+ Local Priority is greater than zero, then:

            (430) * Set the Master_Down_Timer to Skew_Time

         (440) + else // priority non-zero or local-priority is zero
             (Continue other logic)

This will avoid state-transition flip-flap problem in "Router B".

Thanks,
Sreenatha Setty

On 02/27/2013 01:30 AM, vrrp-***@ietf.org wrote:
Some concerns have been raised regarding the following situation / Corner Case:
Due to congestion or some other fault in the network the ADVERTISEMENTs from the Master router do not reach backup router(s). The Master_Down_timer fires and one of the back router transitions to Master State at the same time the priority of this router and the original Master is set to zero. How would the network behave in this case?

For sure the probability of this happening would be very low (as it is a double/multiple fault situation). Here is my analysis of the situation and solution for the same.

We will have two Master routers both sending ADVERTISEMENTs with Priority = 0. This will create a vicious circle of sending ADVERTISEMENTs (one router triggering the other) at a fast rate. This would also cause the Virtual MAC to shuttle continuously between two ports on the switch(es) at a fast rate. Both of these can probably cause high CPU utilization on the router and the LAN Switches.

If there is an additional backup router available then it will become master on seeing the first Advertisement with Priority = 0 and both the Masters (with priority = 0) will transition to Backup on seeing the advertisement with non-zero priority from the new Master.

For the situation where we do not have an additional backup router we can avoid this by making following modifications (Differences from RFC-5798 highlighted in RED):

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

   (705) -+ If the Priority in the ADVERTISEMENT is zero,

   (701) -+ and

   (702) -+ Local Priority is greater than zero, then:

      (710) -* Send an ADVERTISEMENT

      (715) -* Reset the Adver_Timer to Advertisement_Interval

   (720) -+ else // priority was non-zero or local priority was zero

      (725) -* If the Priority in the ADVERTISEMENT is greater
      than the local Priority,

      (730) -* or

      (735) -* If the Priority in the ADVERTISEMENT is equal to
      the local Priority and the primary IPvX Address of the
      sender is greater than the local primary IPvX Address, then:

         (740) -@ Cancel Adver_Timer

         (745) -@ Set Master_Adver_Interval to Adver Interval
         contained in the ADVERTISEMENT

         (750) -@ Recompute the Skew_Time

         (755) @ Recompute the Master_Down_Interval

         (760) @ Set Master_Down_Timer to Master_Down_Interval

         (765) @ Transition to the {Backup} state

      (770) * else // new Master logic

         (775) @ Discard ADVERTISEMENT

      (780) *endif // new Master detected

   (785) +endif // was priority zero?

(790) -endif // advert recv

Please let me know if I have missed something.

Thanks
-Anurag
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/vrrp/attachments/20130226/cc6018e8/attachment.htm>

------------------------------

_______________________________________________
vrrp mailing list
***@ietf.org
https://www.ietf.org/mailman/listinfo/vrrp

End of vrrp Digest, Vol 81, Issue 10
************************************

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.

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.

sreenatha

2013-03-02 08:17:07 UTC

Permalink

Hi Anurag,
Thanks for clarification.

If i am wrong, user is allowed to configure Priority value as
zero(i.e., Maintenance_Event), priority value will be changed. And
handling of the Maintenance_Event is done only in Master state and
ignored in Backup and Init state.

Thanks,
Sreenatha

Post by Anurag Kothari (ankothar)
Hi Sreenatha
I don't think we need to define a "Maintenance_Event" when the router is in either Init or Backup State. The intention of the "Maintenance_Event" is to trigger a failover from "Master" to a "Backup" router as soon as possible (especially when preemption is not configured).
But if you are asking if priority = 0 should be allowed (either by user configuration or dynamically) when the router is in "Init" or "Backup" state then I think the answer should be yes, It should be treated just like any other change in priority is treated when the router is in these states.
Please let me know if I am missing something.
Thanks
-Anurag

Anurag Kothari (ankothar)

2013-03-04 23:43:27 UTC

Permalink

Hi Sreenatha

If you mean "if I am not wrong" then yes what you have said below is correct.

Also I believe the objective (particularly in case of time sensitive application) is to avoid any unnecessary switch overs; as already suggested earlier let's call this a "Change Event" instead of "Maintenance Event". The "Change Event" would be triggered by change in one of the following parameters of the VRRP Packet :

1) Priority (Section 5.2.4. of RFC-5798)
2) Max Adver Int (Section 5.2.7. of RFC-5798)

And possibly:

3) IPvX Address(es) (Section 5.2.9. of RFC-5798)

The "Change Event" would only be handled in Master State and ignored in other state as the VRRP Packets are only supposed to be sent by the Master.

So to rephrase the proposal:

- If a Change event is received, then:

+ Send an ADVERTISEMENT

+ Reset the Adver_Timer to Advertisement_Interval

-endif // Change recv

To cover the failover scenario (in the absence of preemption) Priority = 0 will now have to be allowed along with the previously discussed modifications to avoid a storm of Priority = 0 Advertisements from two masters.

Please Share your thoughts.

Thanks
-Anurag

-----Original Message-----
From: sreenatha [mailto:***@ibtechnology.com]
Sent: Saturday, March 02, 2013 3:17 AM
To: Anurag Kothari (ankothar)
Cc: ***@ietf.org
Subject: Re: Proposal for Maintenance Event for VRRP [RFC-5798]

Hi Anurag,
Thanks for clarification.

If i am wrong, user is allowed to configure Priority value as zero(i.e., Maintenance_Event), priority value will be changed. And handling of the Maintenance_Event is done only in Master state and ignored in Backup and Init state.

Thanks,
Sreenatha

Adrian Farrel

2013-05-22 16:12:05 UTC

Permalink

Hi,

If you are wondering how to progress this in the IETF, the answer is...

- write an I-D
- discuss it (here)
- polish it
- ask me to sponsor it for publication as an RFC.

Cheers,
Adrian

Post by Anurag Kothari (ankothar)
-----Original Message-----
Anurag Kothari (ankothar)
Sent: 04 March 2013 23:43
Cc: fhrp-team(mailer list)
Subject: Re: [VRRP] Proposal for Maintenance Event for VRRP [RFC-5798]
Hi Sreenatha
If you mean "if I am not wrong" then yes what you have said below is correct.
Also I believe the objective (particularly in case of time sensitive

application) is to

Post by Anurag Kothari (ankothar)
avoid any unnecessary switch overs; as already suggested earlier let's call

this a

Post by Anurag Kothari (ankothar)
"Change Event" instead of "Maintenance Event". The "Change Event" would be
1) Priority (Section 5.2.4. of RFC-5798)
2) Max Adver Int (Section 5.2.7. of RFC-5798)
3) IPvX Address(es) (Section 5.2.9. of RFC-5798)
The "Change Event" would only be handled in Master State and ignored in other
state as the VRRP Packets are only supposed to be sent by the Master.
+ Send an ADVERTISEMENT
+ Reset the Adver_Timer to Advertisement_Interval
-endif // Change recv
To cover the failover scenario (in the absence of preemption) Priority = 0

will now

Post by Anurag Kothari (ankothar)
have to be allowed along with the previously discussed modifications to avoid

Post by Anurag Kothari (ankothar)
storm of Priority = 0 Advertisements from two masters.
Please Share your thoughts.
Thanks
-Anurag
-----Original Message-----
Sent: Saturday, March 02, 2013 3:17 AM
To: Anurag Kothari (ankothar)
Subject: Re: Proposal for Maintenance Event for VRRP [RFC-5798]
Hi Anurag,
Thanks for clarification.
If i am wrong, user is allowed to configure Priority value as zero(i.e.,
Maintenance_Event), priority value will be changed. And handling of the
Maintenance_Event is done only in Master state and ignored in Backup and Init
state.
Thanks,
Sreenatha

Post by Anurag Kothari (ankothar)
Hi Sreenatha
I don't think we need to define a "Maintenance_Event" when the router is in

either Init or Backup State. The intention of the "Maintenance_Event" is to
trigger a failover from "Master" to a "Backup" router as soon as possible
(especially when preemption is not configured).

Post by Anurag Kothari (ankothar)
But if you are asking if priority = 0 should be allowed (either by user

configuration or dynamically) when the router is in "Init" or "Backup" state

then I

Post by Anurag Kothari (ankothar)
think the answer should be yes, It should be treated just like any other

change in

Post by Anurag Kothari (ankothar)
priority is treated when the router is in these states.

Post by Anurag Kothari (ankothar)
Please let me know if I am missing something.
Thanks
-Anurag

manner

Post by Anurag Kothari (ankothar)
distribute this email communication as the same is strictly prohibited. If you

have

Post by Anurag Kothari (ankothar)
received this email in error, please notify the sender immediately by return

Post by Anurag Kothari (ankothar)
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

Post by Anurag Kothari (ankothar)
errors in the email communication or for the proper, timely and complete
transmission thereof.
_______________________________________________
vrrp mailing list
https://www.ietf.org/mailman/listinfo/vrrp