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

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 t=
o 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 =3D 0 should be allowed (either by user c=
onfiguration 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:[email protected]] =

Sent: Friday, March 01, 2013 12:03 AM
To: Anurag Kothari (ankothar)
Cc: [email protected]
Subject: Re: Proposal for Maintenance Event for VRRP [RFC-5798]

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


Whether "Maintenance_Event" from user is allowed only in Master state or an=
y other state?

If Maintenance_Event comes in other state(Init or Backup) apart from the Ma=
ster 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
=A0
Totally agree with your observation.
=A0
Also as pointed out by some other participants the additional backup router=
 in my original analysis will never become master on seeing the first ADVER=
TISEMENT with priority zero as it will keep resetting it's Master_Down_Time=
r to Skew_Time in the storm of ADVERTISEMENTs with zero priority and the Ma=
ster_Down_Timer will never fire for the additional backup router.
=A0
Thanks
-Anurag =

=A0
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).
=A0
From: sreenatha [mailto:[email protected]] =

Sent: Thursday, February 28, 2013 11:39 AM
To: [email protected]
Cc: Anurag Kothari (ankothar)
Subject: Re: Proposal for Maintenance Event for VRRP [RFC-5798]
=A0
Hi Anurag,
=A0=A0=A0 Modification to algorithm is correct. But this modification is ta=
king 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. Accor=
ding 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 Back=
up state.

Now according to RFC-5798:
When "Router B" is in Backup state,
(420) - If an ADVERTISEMENT is received, then:
=A0
=A0=A0=A0=A0=A0=A0=A0=A0 (425) + If the Priority in the ADVERTISEMENT is ze=
ro, then:
=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (430) * Set the Master_Down_Timer to Skew=
_Time
=A0
=A0=A0=A0=A0=A0=A0=A0=A0 (440) + else // priority non-zero
=A0
So this lead to Master_Down_Timer to expire soon. =

=A0
Again in Backup state,
(365) - If the Master_Down_Timer fires, then:
=A0
=A0=A0=A0=A0=A0=A0=A0=A0 (370) + Send an ADVERTISEMENT
=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0|
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ...
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =

=A0=A0=A0=A0=A0=A0=A0=A0=A0(405) + Set the Adver_Timer to Advertisement_Int=
erval
=A0
=A0=A0=A0=A0=A0=A0=A0=A0 (410) + Transition to the {Master} state
=A0
(415) -endif // Master_Down_Timer fire
=A0
So this lead to continuous switch over from Backup to Master state and vice=
 verse state transitions in "Router B".
=A0
To avoid this condition,
In Backup state also we need to do modification. Same as you suggested in M=
aster state, same extra condition we need to check in Backup state also.
Modifications in Backup state as follows(Differences from RFC-5798 highligh=
ted with Underline):
=A0
=A0
(420) - If an ADVERTISEMENT is received, then:
=A0
=A0=A0=A0=A0=A0=A0=A0=A0 (425) + If the Priority in the ADVERTISEMENT is ze=
ro, =

=A0=A0=A0=A0=A0=A0=A0=A0=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0(421) -+ and
=A0
=A0=A0=A0=A0=A0=A0=A0=A0 (422) -+ Local Priority is greater than zero, then:
=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (430) * Set the Master_Down_Timer to Skew=
_Time
=A0
=A0=A0=A0=A0=A0=A0=A0=A0 (440) + else // priority non-zero or local-priorit=
y is zero
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 (Continue other logic)
=A0
This will avoid state-transition flip-flap problem in "Router B".
=A0
Thanks,
Sreenatha Setty
=A0

On 02/27/2013 01:30 AM, [email protected] wrote:
Some concerns have been raised regarding the following situation / Corner C=
ase:
Due to congestion or some other fault in the network the ADVERTISEMENTs fro=
m the Master router do not reach backup router(s). The Master_Down_timer fi=
res 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 wo=
uld the network behave in this case?
=A0
For sure the probability of this happening would be very low (as it is a do=
uble/multiple fault situation). Here is my analysis of the situation and so=
lution for the same.
=A0
We will have two Master routers both sending ADVERTISEMENTs with Priority =
=3D 0. This will create a vicious circle of sending ADVERTISEMENTs (one rou=
ter 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 a=
nd the LAN Switches.
=A0
If there is an additional backup router available then it will become maste=
r on seeing the first Advertisement with Priority =3D 0 and both the Master=
s (with priority =3D 0) will transition to Backup on seeing the advertiseme=
nt with non-zero priority from the new Master.
=A0
For the situation where we do not have an additional backup router we can a=
void this by making following modifications (Differences from RFC-5798 high=
lighted in RED):
=A0
(700) - If an ADVERTISEMENT is received, then:
=A0
=A0=A0 (705) -+ If the Priority in the ADVERTISEMENT is zero,
=A0
=A0=A0 (701) -+ and
=A0
=A0=A0 (702) -+ Local Priority is greater than zero, then:
=A0
=A0=A0=A0=A0=A0 (710) -* Send an ADVERTISEMENT
=A0
=A0=A0=A0=A0=A0 (715) -* Reset the Adver_Timer to Advertisement_Interval
=A0
=A0=A0 (720) -+ else // priority was non-zero or local priority was zero
=A0
=A0=A0=A0=A0=A0 (725) -* If the Priority in the ADVERTISEMENT is greater
=A0=A0=A0=A0=A0 than the local Priority,
=A0
=A0=A0=A0=A0=A0 (730) -* or
=A0
=A0=A0=A0=A0=A0 (735) -* If the Priority in the ADVERTISEMENT is equal to
=A0=A0=A0=A0=A0 the local Priority and the primary IPvX Address of the
=A0=A0=A0=A0=A0 sender is greater than the local primary IPvX Address, then:
=A0
=A0=A0=A0=A0=A0=A0=A0=A0 (740) -@ Cancel Adver_Timer
=A0
=A0=A0=A0=A0=A0=A0=A0=A0 (745) -@ Set Master_Adver_Interval to Adver Interv=
al
=A0=A0=A0=A0=A0=A0=A0=A0 contained in the ADVERTISEMENT
=A0
=A0=A0=A0=A0=A0=A0=A0=A0 (750) -@ Recompute the Skew_Time
=A0
=A0=A0=A0=A0=A0=A0=A0=A0 (755) @ Recompute the Master_Down_Interval
=A0
=A0=A0=A0=A0=A0=A0=A0=A0 (760) @ Set Master_Down_Timer to Master_Down_Inter=
val
=A0
=A0=A0=A0=A0=A0=A0=A0=A0 (765) @ Transition to the {Backup} state
=A0
=A0=A0=A0=A0=A0 (770) * else // new Master logic
=A0
=A0=A0=A0=A0=A0=A0=A0=A0 (775) @ Discard ADVERTISEMENT
=A0
=A0=A0=A0=A0=A0 (780) *endif // new Master detected
=A0
=A0=A0 (785) +endif // was priority zero?
=A0
(790) -endif // advert recv
=A0
=A0
Please let me know if I have missed something.
=A0
Thanks
-Anurag
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/vrrp/attachments/20130226/cc6018=
e8/attachment.htm>
=A0
------------------------------
=A0
_______________________________________________
vrrp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/vrrp
=A0
=A0
End of vrrp Digest, Vol 81, Issue 10
************************************
=A0
=A0
Disclaimer : =

This email communication may contain privileged and confidential informatio=
n and is intended for the use of the addressee only.If you are not an inten=
ded recipient you are requested not to reproduce, copy disseminate or in an=
y manner distribute this email communication as the same is strictly prohib=
ited. If you have received this email in error, please notify the sender im=
mediately by return e-mail and delete the communication sent in error. Emai=
l communications cannot be guaranteed to be secure & error free and IB Tech=
nology is not liable for any errors in the email communication or for the p=
roper, timely and complete transmission thereof.

Disclaimer : =

This email communication may contain privileged and confidential informatio=
n and is intended for the use of the addressee only.If you are not an inten=
ded recipient you are requested not to reproduce, copy disseminate or in an=
y manner distribute this email communication as the same is strictly prohib=
ited. If you have received this email in error, please notify the sender im=
mediately by return e-mail and delete the communication sent in error. Emai=
l communications cannot be guaranteed to be secure & error free and IB Tech=
nology is not liable for any errors in the email communication or for the p=
roper, timely and complete transmission thereof.
_______________________________________________
vrrp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/vrrp