Re: Proposal for Maintenance Event for VRRP [RFC-5798]
sreenatha <[email protected]> Thu, 28 Feb 2013 22:08:45 +0530
| Newsgroups | gmane.ietf.vrrp |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============7874873084280729366==
Content-Type: multipart/alternative;
boundary="------------090500060409030003070204"
This is a multi-part message in MIME format.
--------------090500060409030003070204
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
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 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):
(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, [email protected] wrote:
> Some concerns have been raised regarding the following situation / Corner=
Case:
> Due to congestion or some other fault in the network the ADVERTISEMENTs f=
rom 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 ti=
me 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=
=3D 0. This will create a vicious circle of sending ADVERTISEMENTs (one ro=
uter triggering the other) at a fast rate. This would also cause the Virtua=
l 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 mas=
ter on seeing the first Advertisement with Priority =3D 0 and both the Mast=
ers (with priority =3D 0) will transition to Backup on seeing the advertise=
ment 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 hi=
ghlighted 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/cc601=
8e8/attachment.htm>
>
> ------------------------------
>
> _______________________________________________
> vrrp mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/vrrp
>
>
> End of vrrp Digest, Vol 81, Issue 10
> ************************************
>
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.
--------------090500060409030003070204
MIME-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"content-type" content=3D"text/html; charset=3DISO-8=
859-1">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
<div class=3D"moz-text-html" lang=3D"x-western">
<div class=3D"moz-cite-prefix"><tt>Hi Anurag,</tt><tt><br>
</tt><tt> Modification to algorithm is correct. =
But this
modification is taking care only when Router is in Master
state.</tt><tt><br>
</tt><tt> What about if Backup router(priority value is zero)
receives ADVERTISEMENT message with priority value as zero?</tt><=
tt><br>
</tt><tt> </tt><tt><br>
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.</tt><tt><br>
</tt><tt> </tt><tt><br>
</tt><tt> Now according to RFC-5798:</tt><tt><br>
</tt><tt> When "Router B" is in Backup state,</tt><br>
<pre class=3D"newpage">(420) - If an ADVERTISEMENT is received, the=
n:
(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 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):
(420) - If an ADVERTISEMENT is received, then:
(425) + If the Priority in the ADVERTISEMENT is zero, =
=
<u>(421) -+ and</u>
<u>(422) -+ Local Priority is greater than zero, then:</u>
(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
</pre>
<br>
On 02/27/2013 01:30 AM, <a class=3D"moz-txt-link-abbreviated"
href=3D"mailto:[email protected]">[email protected]</a>
wrote:<br>
</div>
<blockquote cite=3D"mid:[email protected]"
type=3D"cite">
<pre wrap=3D"">Some concerns have been raised regarding the followi=
ng situation / Corner Case:
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?
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.
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.
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.
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):
(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: <a class=3D"moz-txt-link-rfc2396E" href=3D"http://www.ietf.org/mail-ar=
chive/web/vrrp/attachments/20130226/cc6018e8/attachment.htm"><http://www=
.ietf.org/mail-archive/web/vrrp/attachments/20130226/cc6018e8/attachment.ht=
m></a>
------------------------------
_______________________________________________
vrrp mailing list
<a class=3D"moz-txt-link-abbreviated" href=3D"mailto:[email protected]">vrrp@ie=
tf.org</a>
<a class=3D"moz-txt-link-freetext" href=3D"https://www.ietf.org/mailman/lis=
tinfo/vrrp">https://www.ietf.org/mailman/listinfo/vrrp</a>
End of vrrp Digest, Vol 81, Issue 10
************************************
</pre>
</blockquote>
<br>
</div>
<P><font style=3D"FONT-SIZE: 11px; FONT-FAMILY: ">Disclaimer : <br>This e=
mail communication may contain privileged and confidential information and =
is intended for the use of the addressee only.If you are not an intended re=
cipient you are requested not to reproduce, copy disseminate or in any mann=
er distribute this email communication as the same is strictly prohibited. =
If you have received this email in error, please notify the sender immediat=
ely by return e-mail and delete the communication sent in error. Email comm=
unications cannot be guaranteed to be secure & error free and IB Techno=
logy is not liable for any errors in the email communication or for the pro=
per, timely and complete transmission thereof.</font></P></body>
</html>
--------------090500060409030003070204--
--===============7874873084280729366==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
vrrp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/vrrp
--===============7874873084280729366==--