RE: draft-ietf-vrrp-unified-spec-00 issues

But the problem you are describing isn't mismatched intervals,
it's an interval that's too short; the problem is the same
even if the master and backup are both configured to the same
interval.
-don

> -----Original Message-----
> From: Steve Bates [mailto:[email protected]]
> Sent: Monday, January 14, 2008 9:52 AM
> To: 'Don Provan'
> Cc: [email protected]
> Subject: RE: [VRRP] draft-ietf-vrrp-unified-spec-00 issues
> 
> 
>  Don,
> 
> My concern is that badly mismatched intervals can adversely impact the
> entire platform on which VRRP is running.  While it may not 
> be desirable to
> write the protocol to mitigate this situation completely, it seems
> irresponsible to not address the issue at all.  At the very 
> least it would
> seem a backup that believes it is about to be swamped could 
> log/indicate the
> situation and remove itself from the virtual router by reverting to
> initializing.  A hung backup is of no use anyway.
> 
> Steve
> 
> 
> -----Original Message-----
> From: Don Provan [mailto:[email protected]] 
> Sent: Friday, January 11, 2008 2:34 PM
> To: 'Steve Bates'
> Cc: [email protected]
> Subject: RE: [VRRP] draft-ietf-vrrp-unified-spec-00 issues
> 
> Hi, Steve,
> 
> My interpretation would be that, yes, to be compliant a 
> backup has to do its
> best to take over the VR according to the time table defined 
> by the master's
> interval as seen in arriving announcements. It would clearly not be
> compliant to ignore the arriving announcements and start 
> sending its own.
> 
> What alternative behavior do you have in mind? Is your 
> concern the missing
> alarm, or is there more to it that I'm missing?
> -don
> 
> > -----Original Message-----
> > From: Steve Bates [mailto:[email protected]]
> > Sent: Friday, January 11, 2008 1:20 PM
> > To: 'Don Provan'
> > Cc: [email protected]
> > Subject: RE: [VRRP] draft-ietf-vrrp-unified-spec-00 issues
> > 
> > 
> > Hi Don,
> > 
> > First of all let me say I appreciate your comments 
> tremendously.  Let 
> > me try to reframe my concern.
> > 
> > Must a backup accept the interval of the master to be considered 
> > compliant with the spec?
> > 
> > Steve
> > 
> > -----Original Message-----
> > From: Don Provan [mailto:[email protected]]
> > Sent: Friday, January 11, 2008 1:43 PM
> > To: 'Steve Bates'
> > Cc: 'Stephen Nadas'; [email protected]
> > Subject: RE: [VRRP] draft-ietf-vrrp-unified-spec-00 issues
> > 
> > Hi, Steve,
> > 
> > First, the principle advantage of this change is that it allows the 
> > interval to be changed by reconfiguring routers one at a time. The 
> > original spec forced the user to change all routers at the 
> same time 
> > least the network be confused with two masters during the 
> switch over. 
> > For this reason alone, I consider the change to be a big 
> improvement.
> > 
> > But let's look at the problem case you have brought up:
> > a router misconfigured with a cripplingly short interval.
> > The change from rejection to acquiescence has two negative 
> effects on 
> > this
> > problem:
> > 
> > N1. Because the rejected packet is dropped earlier, there's 
> less VRRP 
> > processing done on it than if we accept it for processing. I assume 
> > this is negligible, but perhaps you don't.
> > 
> > N2. A rejected packet might cause an alarm.
> > 
> > On the other hand, acquiescence also has a couple of advantageous 
> > effects on the same problem:
> > 
> > A1. As you pointed out, a misconfigured backup will learn 
> and use the 
> > correct value from the master. In other words, the problem will be 
> > resolved.
> > Without this change, not only will the backup keep spewing at the 
> > crippling rate, it will also continuously seize control of the VR.
> > 
> > A2. A backup facing a misconfigured master will stay out of the way 
> > instead of try to announce its control of the VR at its configured 
> > pace.
> > 
> > These advantages are even more useful when the 
> misconfigured interval 
> > is merely different, but not crippling. To me, this is what 
> wins the 
> > day. The much more typical misconfiguration would be 
> forgetting which 
> > of a range of reasonable values was actually selected, 
> something the 
> > new approach just deals with in a perfectly reasonable 
> manner, but the 
> > old approach leaves with two battling routers arguing over the VR 
> > until the problem is sorted out.
> > 
> > In your previous mail, I think you were suggesting what 
> amounted to an 
> > actual two way negotiation.
> > Personally, I don't think we want to open the protocol up 
> to that kind 
> > of thing, but the central problem to it is that, in the 
> end, one has 
> > to decide whether the slower value or the faster value is 
> correct. A 
> > VR misconfigured to fail over too slowly would also be a 
> problem, and 
> > one made harder to sort out when the master router's interval is 
> > configured correctly.
> > As spec'd, we've made the arbitrary but equally reasonable 
> choice of 
> > saying the master's time is always considered the correct one.
> > 
> > As to the user's understanding of the meaning of the 
> interval, that's 
> > something of an interface issue.
> > Yeah, if you follow the lead of the spec and talk about xmit rates, 
> > the user will probably miss the point. But if you document 
> that value 
> > as failover time and highlight the backup system's role in 
> a failover, 
> > the number might be better understood.
> > After all, the value is what it is, regardless of how a user might 
> > misinterpret it.
> > 
> > By the way, one last thing. You mentioned the fact that, of 
> course, no 
> > one really has multiple tiers of routers in a VR. Quite true. But I 
> > think the most interesting variation in interval is in that lowest 
> > priority router (i.e., the second router in any existing
> > deployment): it makes a great deal of sense to configure 
> this router 
> > with a much longer interval since the *only* effect of its 
> > announcements is to train the switch.
> > Now I probably wouldn't bring this up to a user, since I 
> don't really 
> > want them considering anything other than setting all the intervals 
> > the same except during a reconfiguration, but I find it an 
> > illuminating observation.
> > 
> > -don provan
> > 
> > > -----Original Message-----
> > > From: Steve Bates [mailto:[email protected]]
> > > Sent: Friday, January 11, 2008 10:49 AM
> > > To: 'Don Provan'; 'Stephen Nadas'; [email protected]
> > > Subject: RE: [VRRP] draft-ietf-vrrp-unified-spec-00 issues
> > > 
> > > 
> > > Hi Don,
> > > 
> > > Let me explain where I'm coming from on this.  I certainly 
> > can't speak 
> > > for the others on the list, but I suspect almost none of my users 
> > > share your view on the asymmetry of the advertisement 
> interval.  I 
> > > would be pleasantly surprised if ten percent of them knew 
> that the 
> > > advertisement interval was part of the advertisement, and really 
> > > surprised if any of them thought that the value they 
> > configured on the 
> > > master was intended for the backup.  There are at least 
> two reasons 
> > > for this.  First, almost all of them run with very symmetric 
> > > configurations.  Interestingly, they actually use the model we 
> > > describe in example one for individual LANs (the one the 
> > RFC felt was 
> > > going to be less common), but they run many LANs on a 
> > device.  They do 
> > > load splitting by making the virtual routers for half of the LANs 
> > > master on one device and half on another.  The two devices 
> > are viewed 
> > > as peers, not as master and slave.  Their virtual router 
> > > configurations for each device are almost identical, but 
> > they usually 
> > > have some criteria to make the priority higher for half 
> the virtual 
> > > routers on one device and half on the other.
> > > It's usually something like the odd VRIDs have higher 
> priority on  
> > > device A, the even VRIDs have higher priority on device 
> B.  I have 
> > > never seen a customer setup with multiple backups.  That 
> > doesn't mean 
> > > there aren't any, they're just few and far between.  The 
> > second reason 
> > > is implementation based.  Simply stated, based on the 
> > current RFC, the 
> > > participants in the virtual router must have the same 
> advertisement 
> > > interval, otherwise VRRP doesn't work.  This is not a fluke.
> > > 
> > > So from my perspective the change in the draft to accept 
> > the masters 
> > > advertisement interval is an effort to "keep it running" in 
> > spite of a 
> > > misconfiguration.  It will also be useful in migrating to 
> > new interval 
> > > values but this leads to the scenario I'm worried about.  
> My users 
> > > seldom misconfigure one virtual router - typically they 
> > misconfigure 
> > > all the virtual routers on a device.  Assume a setup like I 
> > described 
> > > above in which the user has twenty virtual routers, and she 
> > > misconfigures all the virtual routers on one device with an 
> > interval 
> > > of one instead of 100.
> > >  Upon reboot,
> > > there may be a burst of advertisements from the 10 
> virtual routers 
> > > that are supposed to be in a backup state but eventually 
> they will 
> > > hear the advertisements from the other device and (thanks to the 
> > > change we've made in the draft) they will accept the advertised 
> > > interval and revert to backup.
> > > The 10 virtual routers with higher priority however do not stop 
> > > advertising, so the other device instead of receiving the 10 
> > > advertisements per second it expected and could safely 
> handle, now 
> > > receives 1000 advertisements per second and not being able 
> > to support 
> > > that additional load it hangs, or crashes.
> > > 
> > > I realize this is exception upon exception, but I worry 
> > that we may be 
> > > taking a protocol induced problem that was bad (double 
> masters) and 
> > > replacing it with a protocol induced problem that's 
> > disastrous.  The 
> > > protocol doesn't have to require a negotiation step, just 
> > be flexible 
> > > enough to allow it, and I think the draft as written does 
> > that.  The 
> > > question is is
> > > the cure worse than the disease?   
> > > 
> > > Steve
> > > 
> > > -----Original Message-----
> > > From: Don Provan [mailto:[email protected]]
> > > Sent: Thursday, January 10, 2008 4:54 PM
> > > To: 'Steve Bates'; 'Stephen Nadas'; [email protected]
> > > Subject: RE: [VRRP] draft-ietf-vrrp-unified-spec-00 issues
> > > 
> > > > The second issue involves a backup virtual router accepting
> > > a masters
> > > > advertising interval.  It would be interesting to know 
> > why RFC 2338 
> > > > didn't do this in the first place.  Was it for 
> simplicity or just 
> > > > oversight?  As proposed this represents a pretty one sided 
> > > > negotiation.  For a backup on a device lacking horsepower
> > > or resources
> > > > a master sending advertisements every centisecond might 
> > as well be 
> > > > initiating a denial of service attack.  A clever backup
> > > might reject
> > > > the faster rate and instead become master and send
> > > advertisements at
> > > > its maximum acceptable rate.  An equally clever master 
> > would notice 
> > > > that it keeps getting advertisements from a lower 
> > priority virtual 
> > > > router and adjust its rate appropriately until the backup
> > > submits.  A
> > > granularity field might be a better way to accomplish this.
> > > 
> > > It *is* a one sided negotiation: the user configures the higher 
> > > priority router's timeout interval specifically to 
> control when the
> > > *backup* will
> > > take over. The user's decision has to be based on the 
> > abilities of the 
> > > backup system to actually take over in the configured 
> > amount of time. 
> > > It is just a fluke of the protocol that that amount of time 
> > has to be 
> > > configured on the *failing* system.
> > > 
> > > It makes very little sense to me to build into the protocol a 
> > > procedure to second guess the user's decision about the fail over 
> > > requirements of the virtual router.
> > > 
> > > To me, this all becomes clearer when I consider what it 
> > really means 
> > > when two routers have different intervals configured. The 
> > interval of 
> > > the lower priority router means *nothing whatsoever* to the 
> > speed of 
> > > failover *to* that router: it *only* controls how fast a 
> yet lower 
> > > priority router will take over from the middle backup. 
> The lack of 
> > > symmetry in the intervals is easy to overlook, and my guess 
> > as to why 
> > > different intervals weren't considered in the earlier 
> > versions is that 
> > > everyone thought of the intervals as being symmetric.
> > > 
> > > -don provan
> > > 
> > > 
> > > _______________________________________________
> > > 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

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