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