Re: VRRP - Multiple Masters Question

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:

>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 protected] [mailto:[email protected]]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 protected]
>>Subject: Re: [VRRP] VRRP - Multiple Masters Question
>>
>>
>>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 protected] (E-mail)*
>>>
>>>-------------------------------------------------------------
>>>      
>>>
>>-----------
>>    
>>
>>>_______________________________________________
>>>vrrp mailing list
>>>[email protected]
>>>https://www1.ietf.org/mailman/listinfo/vrrp
>>> 
>>>
>>>      
>>>
>>_______________________________________________
>>vrrp mailing list
>>[email protected]
>>https://www1.ietf.org/mailman/listinfo/vrrp
>>    
>>


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