[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-vrrp
Subject:    RE: [VRRP] Skew_time calculation
From:       "Don Provan" <dprovan () bivio ! net>
Date:       2005-02-16 0:07:36
Message-ID: 001601c513bb$85a43330$9618a8c0 () corp ! networkrobots ! com
[Download RAW message or body]

[Attachment #2 (text/plain)]

The calculation is not integral. Higher priorities use a lower
skew time, with each priority differing by 1/256th of a second.

This causes the highest priority backup is the first one to
get fed up, hence the first one to declare itself master.

By the way, the skew is calculated on the *local system's*
priority. I'm not sure, but your comment about master
abdication makes it sound as if you're calculating it based
on the priority in the packet since the only time priority
0 is used is in a packet: it's never assigned to a node.

-don

> -----Original Message-----
> From: vrrp-bounces@ietf.org [mailto:vrrp-bounces@ietf.org]On Behalf Of
> Christoph Badura
> Sent: Monday, February 14, 2005 2:13 PM
> To: vrrp@ietf.org
> Subject: [VRRP] Skew_time calculation
> 
> 
> The RFCs specify that Skew_Tims is calculated as:
>         ( (256 - Priority) / 256 )
> 
> Priority has a range from 0 to 255. So Skew_Time gets usually 
> calculated
> as 0 except when the master sends an announcement that it is giving up
> the master status then Skew_Time becomes 1.
> 
> Can someone explain the reason for this to me?
> 
> Regards,
> --chb
> 
> _______________________________________________
> vrrp mailing list
> vrrp@ietf.org
> https://www1.ietf.org/mailman/listinfo/vrrp

_______________________________________________
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]