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

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

Hi Sonum,

Interesting you ask, because the VRRP implementation on the Juniper's ERX
have the milliseconds support you refer to.

In the ERX's implementation, this field is left as zero when sub-seconds
are used. More specifically, values internally are stored in the
milliseconds
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.

-- Flavio Fernandes

-----Original Message-----
From: Mathur Sonum-CSM109 [mailto:[email-masked]]
Sent: Tuesday, March 12, 2002 9:08 PM
To: [email-masked]'
Subject: Specifying 'Adver Int' in milli seconds...

The draft talks about specifying 'Adver Int' in the VRRP packet to be in
seconds. What about the case when the configured Advertisement Interval on
Master is less than 1 second and is specified in milliseconds. How can that
be specified in the VRRP packet as 'Adver Int' field is only 8 bit long ? Is
there any provision in the specification, by which we can deal with
Advertisement Interval set to values less than 1 second ?

I am new to this list and don't know whether there has already been some
discussion on this or not.

Thanks for any inputs
--
Sonum
_______________________________________________
vrrp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/vrrp

---

From: Vikram Pendharkar <[email-masked]>
Date: Thu, 26 Sep 2002 08:10:21 -0700 (PDT)

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:

----
NO sense being pessimistic. It wouldnt work anyway

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