diff options
| author | Quentin Young <qlyoung@cumulusnetworks.com> | 2019-03-12 18:31:39 +0100 |
|---|---|---|
| committer | Quentin Young <qlyoung@cumulusnetworks.com> | 2019-05-17 02:27:08 +0200 |
| commit | 8b28e459a17c661972362723ada9bf15e3957601 (patch) | |
| tree | af4f00372217ab0877c105d35c7362b12a41c8bd | |
| parent | vrrpd: display primary address in json output (diff) | |
| download | frr-8b28e459a17c661972362723ada9bf15e3957601.tar.xz frr-8b28e459a17c661972362723ada9bf15e3957601.zip | |
vrrpd: allow centisecond precision for vrrpv2
The RFC is not clear about how precise the skew time calculation should
be in VRRPv2. The advertisement interval is given in seconds, and the
field in the advertisement packet only supports non-fractional seconds,
so I was following this for calculating skew time as well. However the
skew time formula in vrrpv2 always yields a fractional amount of seconds
in the range (0-1), which right now means we always truncate to 0
seconds. I doubt this is what the RFC wanted so I'm allowing centisecond
precision for skew time.
Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
| -rw-r--r-- | vrrpd/vrrp.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/vrrpd/vrrp.c b/vrrpd/vrrp.c index cba79b544..3f93ac441 100644 --- a/vrrpd/vrrp.c +++ b/vrrpd/vrrp.c @@ -97,7 +97,7 @@ static void vrrp_mac_set(struct ethaddr *mac, bool v6, uint8_t vrid) */ static void vrrp_recalculate_timers(struct vrrp_router *r) { - uint16_t skm = (r->vr->version == 3) ? r->master_adver_interval : 1; + uint16_t skm = (r->vr->version == 3) ? r->master_adver_interval : 100; r->skew_time = ((256 - r->vr->priority) * skm) / 256; r->master_down_interval = (3 * r->master_adver_interval); r->master_down_interval += r->skew_time; |