RE: 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