Subject: RE: [VRRP] RE: Specifying 'Adver Int' in milli seconds...

From: "Fernandes, Flavio" <[email-masked]>
Date: Thu, 26 Sep 2002 11:26:08 -0400

I agree. We do not expect Juniper's ERX to interop with anything other than
another ERX
while 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:[email-masked]]
Sent: Thursday, September 26, 2002 11:10 AM
To: Fernandes, Flavio; 'Mathur Sonum-CSM109'; [email-masked]'
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  <http://rd.yahoo.com/evt=1207/*http://sbc.yahoo.com/>
Access from SBC & Yahoo!

---

From: "RamanaReddy venkata kunam" <[email-masked]>
Date: 27 Sep 2002 07:51:38 -0000

hi,
Its really good to have milli secs as well seconds. But how
to configure to second values as there is no object for sec or 
msec
in MIB. Is it proprietary MIB then???? I have seen only 
advertisement
Interval in the MIB.
ramana.

On Thu, 26 Sep 2002 Fernandes, Flavio wrote :
>New DSL Internet  
><http://rd.yahoo.com/evt=1207/*http://sbc.yahoo.com/>
>Access from SBC & Yahoo!
>

_______________________________________________
vrrp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/vrrp

---

From: Mathur Sonum-CSM109 <[email-masked]>
Date: Fri, 27 Sep 2002 13:15:54 -0500

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:[email-masked]]
Sent: Thursday, September 26, 2002 8:26 AM
To: 'Vikram Pendharkar'; 'Mathur Sonum-CSM109'; [email-masked]
Subject: RE: [VRRP] RE: Specifying 'Adver Int' in milli seconds...

 
-- Flavio Fernandes

-----Original Message-----
From: Vikram Pendharkar [mailto:[email-masked]]
Sent: Thursday, September 26, 2002 11:10 AM
To: Fernandes, Flavio; 'Mathur Sonum-CSM109'; [email-masked]'
Subject: Re: [VRRP] RE: Specifying 'Adver Int' in milli seconds...

"While recv. pkts: 

Vikram

----

  _____  

Do you Yahoo!?

---

From: Vikram Pendharkar <[email-masked]>
Date: Fri, 27 Sep 2002 16:20:02 -0700 (PDT)

"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:[email-masked]]
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:[email-masked]]
Sent: Thursday, September 26, 2002 8:26 AM
To: 'Vikram Pendharkar'; 'Mathur Sonum-CSM109'; [email-masked]
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-----

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

----

---------------------------------
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!

----

---------------------------------
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!

----

---------------------------------
Do you Yahoo!?
New DSL Internet Access from SBC & Yahoo!