Subject: [VRRP] VRRP - Multiple Masters Question

From: "Hott, Robert W CIV B35-Branch" <[email-masked]>
Date: Fri, 2 Dec 2005 14:44:34 -0600

I am in the process of updating a draft for sub-second timers for VRRP for IPv4. An area that I have struggled with has been how to deal with legacy devices that might be on a network with devices that use sub-second timers. In thinking out this issue for this new draft, I noticed something that seems to a problem with the current RFC. The interesting area in RFC 3768 is section 7.1 on receiving VRRP packets.

The issue is this. Suppose that I have a master router configured with an advertisement interval of 1 second. I have two more routers configured as backups. One is configured with an advertisement interval of 2 seconds and another is configured with an advertisement interval of 3 seconds.

I know that this is problematic but it could happen. Anyway, the master would send an advertisement. Based upon section 7.1, both of the backups would discard this advertisement and would report the misconfiguration. Since the advertisement would be discarded, both would eventually transition to masters. The end result would be three masters, since the state machine would not act on the advertisement.

Did I interpret this correctly? I would think that you would not want to discard the advertisement because of the wrong setting. I would think you would want to use the interval of the master, at least until you assume the role of the master.

Bob Hott

Robert (Bob) W. Hott
NSWC-DD
Code B35, Bldg. 1500A/122A
17320 Dahlgren Road
Dahlgren, VA 22448-5100
540-653-1497 (W)
540-653-8673 (FAX)
[email-masked] (E-mail)

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

---

From: Radia Perlman <[email-masked]>
Date: Fri, 02 Dec 2005 13:04:43 -0800

I agree with you that protocols should be resilient to configuration 
differences between nodes,
and I think the ideal solution is what you suggested (use the timer as 
advertised by the master)
rather than what's in the spec (discard messages that disagree with your 
setting, so that
multiple masters will be elected, ignoring each others' messages). 
Especially in conjunction with
bridges, multiple masters are dangerous.

This was brought up on the mailing list before I was watching this 
group, and somehow
the discussion fizzled out. I think the subsecond timer draft is a good 
excuse to revisit this,
and make sure, if the WG really wants to keep the behavior as it is, 
that it is doing it
consciously.

So please, people, speak up about which behavior you prefer:

a) discard (and log an error) if the value advertised in the VRRP 
message disagrees with your
configured value for hello timer....this is what is currently specified
b) use the interval advertised by the master, for as long as it is master

If we switch to b), then another decision is whether that is configured 
misconfiguration or not,
i.e., if an error should be logged.

Radia

Hott, Robert W CIV B35-Branch wrote:

> I am in the process of updating a draft for sub-second timers for VRRP 
> for IPv4. An area that I have struggled with has been how to deal with 
> legacy devices that might be on a network with devices that use 
> sub-second timers. In thinking out this issue for this new draft, I 
> noticed something that seems to a problem with the current RFC. The 
> interesting area in RFC 3768 is section 7.1 on receiving VRRP packets.
>
> The issue is this. Suppose that I have a master router configured with 
> an advertisement interval of 1 second. I have two more routers 
> configured as backups. One is configured with an advertisement 
> interval of 2 seconds and another is configured with an advertisement 
> interval of 3 seconds.
>
> I know that this is problematic but it could happen. Anyway, the 
> master would send an advertisement. Based upon section 7.1, both of 
> the backups would discard this advertisement and would report the 
> misconfiguration. Since the advertisement would be discarded, both 
> would eventually transition to masters. The end result would be three 
> masters, since the state machine would not act on the advertisement.
>
> Did I interpret this correctly? I would think that you would not want 
> to discard the advertisement because of the wrong setting. I would 
> think you would want to use the interval of the master, at least until 
> you assume the role of the master.
>
> Bob Hott
>
> *Robert (Bob) W. Hott*
> *NSWC-DD*
> *Code B35, Bldg. 1500A/122A*
> *17320 Dahlgren Road*
> *Dahlgren, VA 22448-5100*
> *540-653-1497 (W)*
> *540-653-8673 (FAX)*
> [email-masked] (E-mail)*
>
>------------------------------------------------------------------------
>

---

From: "Don Provan" <[email-masked]>
Date: Fri, 2 Dec 2005 15:06:47 -0800

Here are the comments I put in my implementation. The summary is
that I slow down my timer if I hear from a higher priority system
with a slower interval. All other cases (I claim) aren't an issue.
This is the last step in packet validation:

 /* MUST verify that the Adver Interval in the packet is the same as
 ** the locally configured for this virtual router */
 /* OK, that's what the spec says, but actually it makes very
  * little sense: all it does is insure the two routers with
  * different times argue over the MAC address, etc., while
  * ignoring each other's packets. Notice that this would
  * happen while the time was being reconfigured on multiple
  * systems. So I ignore that requirement, and instead take his
  * timer value if it's larger than mine and he has higher
  * priority. (If I have higher priority, I continue using my
  * own time: I shouldn't have heard from him, anyway.) note
  * that we're checking against our configured interval, not
  * this entry's interval: this entry could have been
  * previously slowed down, only to be speeded up again
  * (possibly already the way to our configured interval, hence
  * the greater than *or equal to*).
  */
 vrrp_interval = VRRP_TIME_TO_MS( vrrp->adver_int );
 if ( ( vrrp_interval != entry->adver_int )
      && ( vrrp_interval >= vrrpd_adver_int )
      && ( vrrp->priority > entry->priority ) )
 { /* he's better than me, so just use his advertisement
    * interval, automatically changing the down interval.
    * (if he's running faster than us, it's not an issue,
    * which is good because we don't want to change our
    * scheduling rate. if he ever gets set to a lower
    * value, we'll see it and adjust again, possibly
    * making it back down to our own value (although
    * we'll never explicitly notice that.)
    */
   entry->adver_int = vrrp_interval;
 }

-don

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Radia Perlman
> Sent: Friday, December 02, 2005 1:05 PM
> To: Hott, Robert W CIV B35-Branch
> Cc: Chappell, Brett L CIV B35-Branch; Odonoghue,Karen F CIV 
> B35-Branch;
> Plunkett,Timothy R CIV B35-Branch; [email-masked]
> Subject: Re: [VRRP] VRRP - Multiple Masters Question
> 
>

---

From: Radia Perlman <[email-masked]>
Date: Fri, 02 Dec 2005 15:12:41 -0800

I like Don's interpretation, and his implementation should be compatible 
with stations
that follow the spec, but it seems better to have the spec reflect what 
the WG wants
rather than implementations diverging from the spec. So I'd hope, if the 
WG likes
this interpretation, that we change the spec.

Also, I suppose there's another choice to be made:

If an implementation "uses" the master's interval, does that mean it 
overwrites what it has
been configured with? I assume not...i.e., if you temporarily bring up a 
master with
a short timer, once that master goes away, the other nodes will revert 
to their old value, right?

Radia

Don Provan wrote:

>>>I am in the process of updating a draft for sub-second 
>>>      
>>>
>>timers for VRRP 
>>    
>>
>>>for IPv4. An area that I have struggled with has been how 
>>>      
>>>
>>to deal with 
>>    
>>
>>>interesting area in RFC 3768 is section 7.1 on receiving 
>>>      
>>>
>>VRRP packets.
>>    
>>
>>>The issue is this. Suppose that I have a master router 
>>>      
>>>
>>configured with 
>>    
>>
>>>interval of 2 seconds and another is configured with an 
>>>      
>>>
>>advertisement 
>>    
>>
>>>interval of 3 seconds.
>>>
>>>would eventually transition to masters. The end result 
>>>      
>>>
>>would be three 
>>    
>>
>>>Did I interpret this correctly? I would think that you 
>>>      
>>>
>>would not want 
>>    
>>
>>>think you would want to use the interval of the master, at 
>>>      
>>>
>>least until 
>>    
>>
>>>-------------------------------------------------------------
>>>      
>>>
>>-----------
>>    
>>

---

From: Mukesh Gupta <[email-masked]>
Date: Fri, 02 Dec 2005 14:03:51 -0800

> a) discard (and log an error) if the value advertised 
>    in the VRRP message disagrees with your configured 
>    value for hello timer.... this is what is currently
>    specified
> 

I would vote for option b.

> If we switch to b), then another decision is whether that 
> is configured misconfiguration or not, i.e., if an error 
> should be logged.

Yes !

Is there any case where having different advertisement intervals
on different nodes will be useful?  If not, it should be considered
a misconfiguration but handled gracefully !

We are waiting for another update of the VRRP for IPv6 draft
to address IESG's comments.  We still have some time to pitch
in this change if the WG agrees to do this !

- Mukesh

---

From: Mukesh Gupta <[email-masked]>
Date: Fri, 02 Dec 2005 15:46:51 -0800

Radia,

> this interpretation, that we change the spec.

I agree !

> to their old value, right?

No it does not make sense to overwrite what it has been configured with.
The node should keep using the master's interval till it
keeps hearing the master.  As soon as the master disappears, they
start using their configured advertisement interval.

Don, I am curious about why you didn't raise the issue and got
the spec fixed instead of deviating your implementation from
the spec :)

Regards
Mukesh

---

From: "Don Provan" <[email-masked]>
Date: Fri, 2 Dec 2005 16:00:58 -0800

For the first point, the observation is that *nothing* can
make an implementation that follows the spec reasonable: it's
just *going* to fight. My implementation works fine with an
implementation following the spec if the other implementation
is higher priority, but it ignores the case where the other
implementation is lower priority because there's basically
nothing to be done about it.

But that really just reinforces the observation that the
spec should be changed (assuming we all agree this is
the correct approach).

As to the second choice, I actually decided to stay with
the slower tick rate even after I'm in charge just because
the worst that can happen is a subordinate ticking faster
than a master, and we know there's at least one master
ticking slower. But I'm not sure there are any specific
problems with going to our faster configured rate once
we're in charge, so I'm ok with that if no one else sees
any problems.

-don

> From: Radia Perlman [mailto:[email-masked]]
> Sent: Friday, December 02, 2005 3:13 PM
> To: Don Provan
> Cc: 'Hott, Robert W CIV B35-Branch'; 'Chappell, Brett L CIV 
> B35-Branch';
> 'Odonoghue,Karen F CIV B35-Branch'; 'Plunkett,Timothy R CIV 
> B35-Branch';
> [email-masked]
> >>From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> >>Radia Perlman

---

From: "Don Provan" <[email-masked]>
Date: Fri, 2 Dec 2005 17:06:39 -0800

> the spec fixed instead of deviating your implementation from

I have raised it a couple of times. I even suggested
that this behavior be specified in the IPv4 timers
spec when I commented on it last March. But I guess
it was lost because I cast it as specifically a solution
to the backwards compatibility issue between subsecond
implementations and second-based implementations rather
than as the more general solution I actually implemented
in my own code.

And I wasn't too worried about deviating from the spec
since there don't appear to be any cases where this
behavior is worse than the spec's suggested behavior.

-don

---

From: "venkateshs" <[email-masked]>
Date: Mon, 5 Dec 2005 14:53:55 +0530

Hi,

   Don's interpretation and Mukesh's comments over that are fine.

   I feel that the Administrators should ensure that there is no mismatch in
these critical parameters like advertisement Interval.

   If the problem is the the `Mater State`, Why can't the State can be
retained in INIT/BACKUP when there is a mismatch in Such Parameter Values?

   We have similar hello Interaval Parameter in OSPF .There also,the
adjacency won't form if any mismatch in Hello Interval.

   I think there should be some valid reasons behind the Advertisement
Interval.Can Authuors of RFC please give their comments on the same?

Thanks & Regards
Venkatesan S.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Mukesh Gupta
Sent: Saturday, 3 December 2005 3:34 AM
To: Radia Perlman
Cc: Chappell, Brett L CIV B35-Branch; Hott,Robert W CIV B35-Branch;
[email-masked]; Plunkett, Timothy R CIV B35-Branch; Odonoghue, Karen F
CIV B35-Branch
Subject: Re: [VRRP] VRRP - Multiple Masters Question

Yes !

- Mukesh

***************************************************************************
This message is proprietary to Future Software Limited (FSL)
and is intended solely for the use of the individual to whom it
is addressed. It may contain  privileged or confidential information
and should not be circulated or used for any purpose other than for
what it is intended.

If you have received this message in error, please notify the
originator immediately. If you are not the intended recipient,
you are notified that you are strictly prohibited from using,
copying, altering, or disclosing the contents of this message.
FSL accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including
damage from virus.
***************************************************************************