[prev in list] [next in list] [prev in thread] [next in thread]
List: ietf-vrrp
Subject: RE: [VRRP] RE: Specifying 'Adver Int' in milli seconds...
From: Vikram Pendharkar <philosopher203 () yahoo ! com>
Date: 2002-09-27 23:20:02
Message-ID: 20020927232002.32682.qmail () web10503 ! mail ! yahoo ! com
[Download RAW message or body]
"No, we never neglect to check this field. We check only the seconds part, because \
milli seconds cannot be conveyed by the Master in that field. So, if backup is \
configured with value 2700 msecs, then it will accept Advertisement with value = 2. \
The value 2 in the advt. means that Master could be configured with any value between \
2000 and 2999 msecs." I can immediately thnk of one scenario wherein this can result \
in incorrect behavior:
M: 2000 ms & IPx, B1: 2000ms & IP1, B2: 2999 ms (misconfig) & IP2
B1 (secondary backup), B2 (primary backup) are backup for M. IP1 < IP2
at t1 sec: M goes down
at 3*(adver int of B1)sec: B1 becomes master (and sends advt. out) ==> B2 stays as \
Backup when it should have become master ( and thus know that there is some kinda \
misconfiguration!!!) RFC compliant behavior would be as follows:
at t1: M goes down
at 3*t1: B1 & B2 become master (and send advt. out). If B2 was configured as 3 sec, \
then having 2 masters would tell us there is some misconfiguration. "We would \
inter-operate with anyone who deals with just in seconds. For milli-seconds, we don't \
have anything specified in RFC and there can be interoperability issues. Still, \
Juniper did the same thing as what we have implemented." So inter-op in such cases \
with other RFC complaint products fail even though they were configured in secs. \
Probably far-fetched, but still a valid scenario!! Vikram
p.s. (I missed doin a reply all earlier, adding back vrrp mailing list)
Mathur Sonum-CSM109 wrote: No, we never neglect to check this field. We check only \
the seconds part, because milli seconds cannot be conveyed by the Master in that \
field. So, if backup is configured with value 2700 msecs, then it will accept \
Advertisement with value = 2. The value 2 in the advt. means that Master could be \
configured with any value between 2000 and 2999 msecs. We would inter-operate with \
anyone who deals with just in seconds. For milli-seconds, we don't have anything \
specified in RFC and there can be interoperability issues. Still, Juniper did the \
same thing as what we have implemented. --Sonum-----Original \
Message-----
From: Vikram Pendharkar [mailto:philosopher203@yahoo.com]
Sent: Friday, September 27, 2002 12:22 PM
To: Mathur Sonum-CSM109
Subject: RE: [VRRP] RE: Specifying 'Adver Int' in milli seconds...
Well, if I understood it corretly then whenever the backup is configured with an \
adver int which is not a multiple of 1 sec then you will just neglect to check this \
field. I would recommend this solution only if your product doesnt wish/intend to \
inter-operate with other RFC compliant routers/switches. Vikram
Mathur Sonum-CSM109 wrote: That's how our implementation is. At the receiving end, \
check for milli seconds granularity cannot be made. So, if Master and Backup are \
configured with values 500 msecs and 700 msecs respectively, the receiver will not \
discard the packet. But if configured values are 500 msecs and 1700 msecs, then it \
will be discarded. If the values configured are in whole seconds, then behavior will \
be exactly as what RFC mandates. This is the best we could think of, if we were to \
live with 8 bit field and also need configurations in milli seconds. \
--Sonum-----Original Message-----
From: Fernandes, Flavio [mailto:ffernandes@juniper.net]
Sent: Thursday, September 26, 2002 8:26 AM
To: 'Vikram Pendharkar'; 'Mathur Sonum-CSM109'; vrrp@ietf.org
Subject: RE: [VRRP] RE: Specifying 'Adver Int' in milli seconds...
I agree. We do not expect Juniper's ERX to interop with anything other than another \
ERXwhile using sub-second intervals.... However, if user configures whole second \
values,the advertisement value in the VRRP payload will be exactly as the RFC \
mandates. -- Flavio Fernandes -----Original Message-----
From: Vikram Pendharkar [mailto:philosopher203@yahoo.com]
Sent: Thursday, September 26, 2002 11:10 AM
To: Fernandes, Flavio; 'Mathur Sonum-CSM109'; 'vrrp@ietf.org'
Subject: Re: [VRRP] RE: Specifying 'Adver Int' in milli seconds...
RFC states clearly in section 7.1 that:
"While recv. pkts:
- MUST verify that the Adver Interval in the packet is the same as the locally \
configured for this virtual router
If the above check fails, the receiver MUST discard the packet, SHOULD log the event \
and MAY indicate via network management that a misconfiguration was detected. "
So if internally configured value in millisec cannot be retrived exactly then this \
mechanism is essentially non-compliant behavior of RFC.
Since 'discard the packet' is preceded with MUST, I am not sure if that field is \
there just for debugging purposes (discarding a packet for non-compliant behavior is \
as good as no pkt sent out by master!!)
Vikram
"Fernandes, Flavio" wrote:
unit. When populating the VRRP payload, the code simply divides the value
by 1000 (1573 milliseconds, for instance, would map into the value of 1).
Note that the 'Adver Int' in the VRRP packet is mainly there for debugging
purposes. The fact that we only have 8 bits for storing the 'Adver Int'
makes
is a bit challenging for storing the potentially large values we would have
if using milliseconds as the unit.
----
NO sense being pessimistic. It wouldnt work anyway
---------------------------------
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
----
NO sense being pessimistic. It wouldnt work anyway
---------------------------------
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
----
NO sense being pessimistic. It wouldnt work anyway
---------------------------------
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!
[Attachment #3 (text/html)]
<DIV><SPAN class=778513921-27092002><FONT color=#0000ff face="Book Antiqua">"No, we \
never neglect to check this field. We check only the seconds part, because milli \
seconds cannot be conveyed by the Master in that field. So, if backup is \
configured with value 2700 msecs, then it will accept Advertisement with value = 2. \
The value 2 in the advt. means that Master could be configured with any value between \
2000 and 2999 msecs."</FONT></SPAN></DIV> <P>I can immediately thnk of one scenario \
wherein this can result in incorrect behavior: <P>M: 2000 ms & IPx, B1: 2000ms \
& IP1, B2: 2999 ms (misconfig) & IP2 <P>B1 (secondary backup), B2 \
(primary backup) are backup for M. IP1 < IP2 <P>at t1 sec: M goes down
<P>at 3*(adver int of B1)sec: B1 becomes master (and sends advt. out) ==> B2 stays \
as Backup when it should have become master ( and thus know that there is some kinda \
misconfiguration!!!) <P>RFC compliant behavior would be as follows:
<P>at t1: M goes down
<P>at 3*t1: B1 & B2 become master (and send advt. out). If B2 was configured as 3 \
sec, then having 2 masters would tell us there is some misconfiguration. <P>
<DIV><SPAN class=778513921-27092002><FONT color=#0000ff face="Book Antiqua">"We would \
inter-operate with anyone who deals with just in seconds. For milli-seconds, we don't \
have anything specified in RFC and there can be interoperability issues. Still, \
Juniper did the same thing as what we have implemented."</FONT></SPAN></DIV> <P>So \
inter-op in such cases with other RFC complaint products fail even though they were \
configured in secs. Probably far-fetched, but still a valid scenario!! <P>Vikram
<P>p.s. (I missed doin a reply all earlier, adding back vrrp mailing list)
<P> <B><I>Mathur Sonum-CSM109 <SONUM@MOTOROLA.COM></I></B>wrote:
<BLOCKQUOTE style="BORDER-LEFT: #1010ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: \
5px"><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <META \
content="MSHTML 6.00.2600.0" name=GENERATOR> <DIV><SPAN \
class=778513921-27092002><FONT color=#0000ff face="Book Antiqua">No, we never neglect \
to check this field. We check only the seconds part, because milli seconds cannot be \
conveyed by the Master in that field. So, if backup is configured with value \
2700 msecs, then it will accept Advertisement with value = 2. The value 2 in the \
advt. means that Master could be configured with any value between 2000 and 2999 \
msecs.</FONT></SPAN></DIV> <DIV><SPAN class=778513921-27092002><FONT color=#0000ff \
face="Book Antiqua"></FONT></SPAN> </DIV> <DIV><SPAN \
class=778513921-27092002><FONT color=#0000ff face="Book Antiqua">We would \
inter-operate with anyone who deals with just in seconds. For milli-seconds, we don't \
have anything specified in RFC and there can be interoperability issues. Still, \
Juniper did the same thing as what we have implemented.</FONT></SPAN></DIV> \
<DIV><SPAN class=778513921-27092002><FONT color=#0000ff face="Book \
Antiqua"></FONT></SPAN> </DIV> <DIV><SPAN class=778513921-27092002><FONT \
color=#0000ff face="Book Antiqua">--</FONT></SPAN></DIV> <DIV><SPAN \
class=778513921-27092002><FONT color=#0000ff face="Book \
Antiqua">Sonum</FONT></SPAN></DIV> <BLOCKQUOTE style="BORDER-LEFT: #0000ff 2px solid; \
MARGIN-LEFT: 5px; PADDING-LEFT: 5px"> <DIV align=left class=OutlookMessageHeader \
dir=ltr><FONT face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> Vikram \
Pendharkar [mailto:philosopher203@yahoo.com]<BR><B>Sent:</B> Friday, September 27, \
2002 12:22 PM<BR><B>To:</B> Mathur Sonum-CSM109<BR><B>Subject:</B> RE: [VRRP] RE: \
Specifying 'Adver Int' in milli seconds...<BR><BR></FONT></DIV> <P>
<P>Well, if I understood it corretly then whenever the backup is configured with an \
adver int which is not a multiple of 1 sec then you will just neglect to check this \
field. I would recommend this solution only if your product doesnt wish/intend to \
inter-operate with other RFC compliant routers/switches. <P>Vikram
<P> <B><I>Mathur Sonum-CSM109 <SONUM@MOTOROLA.COM></I></B>wrote:
<BLOCKQUOTE style="BORDER-LEFT: #1010ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: \
5px"> <META content="MSHTML 6.00.2600.0" name=GENERATOR>
<DIV><SPAN class=176000918-27092002><FONT color=#0000ff face="Book Antiqua">That's \
how our implementation is. At the receiving end, check for milli seconds granularity \
cannot be made. So, if Master and Backup are configured with values 500 msecs and 700 \
msecs respectively, the receiver will not discard the packet. But if configured \
values are 500 msecs and 1700 msecs, then it will be discarded. If the values \
configured are in whole seconds, then behavior will be exactly as what RFC \
mandates. This is the best we could think of, if we were to live with 8 bit field and \
also need configurations in milli seconds.</FONT></SPAN></DIV> <DIV><SPAN \
class=176000918-27092002><FONT color=#0000ff face="Book \
Antiqua"></FONT></SPAN> </DIV> <DIV><SPAN class=176000918-27092002><FONT \
color=#0000ff face="Book Antiqua">--</FONT></SPAN></DIV> <DIV><SPAN \
class=176000918-27092002><FONT color=#0000ff face="Book \
Antiqua">Sonum</FONT></SPAN></DIV> <BLOCKQUOTE dir=ltr style="BORDER-LEFT: #0000ff \
2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px"> <DIV align=left \
class=OutlookMessageHeader dir=ltr><FONT face=Tahoma size=2>-----Original \
Message-----<BR><B>From:</B> Fernandes, Flavio \
[mailto:ffernandes@juniper.net]<BR><B>Sent:</B> Thursday, September 26, 2002 8:26 \
AM<BR><B>To:</B> 'Vikram Pendharkar'; 'Mathur Sonum-CSM109'; \
vrrp@ietf.org<BR><B>Subject:</B> RE: [VRRP] RE: Specifying 'Adver Int' in milli \
seconds...<BR><BR></FONT></DIV> <DIV><FONT color=#0000ff face="Courier New" \
size=2></FONT> </DIV> <DIV><FONT color=#0000ff face="Courier New" size=2><SPAN \
class=609362215-26092002>I agree. We do not expect Juniper's ERX to interop with \
anything other than another ERX</SPAN></FONT></DIV> <DIV><FONT color=#0000ff \
face="Courier New" size=2><SPAN class=609362215-26092002>while using sub-second \
intervals.... However, if user configures whole second values,</SPAN></FONT></DIV> \
<DIV><FONT color=#0000ff face="Courier New" size=2><SPAN class=609362215-26092002>the \
advertisement value in the VRRP payload will be exactly as the RFC \
mandates.</SPAN></FONT></DIV> <DIV><FONT color=#0000ff face="Courier New" \
size=2><SPAN class=609362215-26092002></SPAN></FONT> </DIV> <DIV><FONT \
color=#0000ff face="Courier New" size=2><SPAN class=609362215-26092002>-- Flavio \
Fernandes</SPAN></FONT></DIV> <DIV><FONT color=#0000ff face="Courier New" \
size=2></FONT> </DIV> <BLOCKQUOTE>
<DIV align=left class=OutlookMessageHeader dir=ltr><FONT face=Tahoma \
size=2>-----Original Message-----<BR><B>From:</B> Vikram Pendharkar \
[mailto:philosopher203@yahoo.com]<BR><B>Sent:</B> Thursday, September 26, 2002 11:10 \
AM<BR><B>To:</B> Fernandes, Flavio; 'Mathur Sonum-CSM109'; \
'vrrp@ietf.org'<BR><B>Subject:</B> Re: [VRRP] RE: Specifying 'Adver Int' in milli \
seconds...<BR><BR></FONT></DIV> <P>RFC states clearly in section 7.1 that:
<P>"While recv. pkts:
<P>- MUST verify that the Adver Interval in the packet is the same as the locally \
configured for this virtual router <P></P>
<P>If the above check fails, the receiver MUST discard the packet, SHOULD log the \
event and MAY indicate via network management that a misconfiguration was \
detected. "</P> <P>So if internally configured value in millisec cannot be \
retrived exactly then this mechanism is essentially non-compliant behavior of \
RFC.</P> <P>Since 'discard the packet' is preceded with MUST, I am not sure if that \
field is there just for debugging purposes (discarding a packet for non-compliant \
behavior is as good as no pkt sent out by master!!)</P> <P>Vikram</P>
<P> <B><I>"Fernandes, Flavio" <FFERNANDES@JUNIPER.NET></I></B>wrote:</P>
<BLOCKQUOTE style="BORDER-LEFT: #1010ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: \
5px"><BR><BR>unit. When populating the VRRP payload, the code simply divides the \
value<BR>by 1000 (1573 milliseconds, for instance, would map into the value of \
1).<BR><BR>Note that the 'Adver Int' in the VRRP packet is mainly there for \
debugging<BR>purposes. The fact that we only have 8 bits for storing the 'Adver \
Int'<BR>makes<BR>is a bit challenging for storing the potentially large values we \
would have<BR>if using milliseconds as the unit.<BR></BLOCKQUOTE><BR><BR>----<BR>NO \
sense being pessimistic. It wouldnt work anyway <P><BR>
<HR SIZE=1>
Do you Yahoo!?<BR>New <A \
href="http://rd.yahoo.com/evt=1207/*http://sbc.yahoo.com/">DSL Internet Access</A> \
from SBC & Yahoo!</A></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE><BR><BR>----<BR>NO \
sense being pessimistic. It wouldnt work anyway <P><BR>
<HR SIZE=1>
Do you Yahoo!?<BR>New <A \
href="http://rd.yahoo.com/evt=1207/*http://sbc.yahoo.com/">DSL Internet Access</A> \
from SBC & Yahoo!</A></BLOCKQUOTE></BLOCKQUOTE><BR><BR>----<br>NO sense being \
pessimistic. It wouldnt work anyway<p><br><hr size=1>Do you Yahoo!?<br> New <a \
href="http://rd.yahoo.com/evt=1207/*http://sbc.yahoo.com/">DSL Internet Access</a> \
from SBC & Yahoo!</a>
_______________________________________________
vrrp mailing list
vrrp@ietf.org
https://www1.ietf.org/mailman/listinfo/vrrp
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic