Cathy Zhou wrote:
> Peter Memishian wrote:
>>  > Not sure whether Meem is following up our discussion here. I will
>> copy  > him on this email and give a summary as below:
>>  >  > In the current VRRP design, once a VRRP router is enabled, we
>> will hold  > the underlying data-link and the VRRP router associated
>> VNIC open, to  > prevent them from being renamed/deleted. The problem
>> of not doing so is  > that the administrator could delete the
>> underlying data-link (since it  > could be an aggregation or a VLAN)
>> or delete the VNIC or rename them or  > recreate other links with
>> those names, but since at the same time, vrrpd  > still listens to the
>> PF_ROUTE socket messages and try to track all the  > IP addresses over
>> the old data-link names, vrrpd could assume incorrect  > primary
>> address and virtual addresses set.
>>  >  > Therefore, the VRRP design proposes to hold the underlying
>> data-link and  > the VNIC open. Further, to make DR work, a vrrp_rcm
>> plugin needs to be  > implemented to disable the router when the
>> associated device is DRed-out  > and re-enable the router once the
>> device is DRed back.
>>  >  > Meem/James, please let me know if you see a problem with this
>> approach.
>>
>> That sounds fine to me, though I'd generally expect the VNICs to be
>> plumbed by IP which would also prevent them from being
>> renamed/deleted; in
>> what situations is that not the case?  Also, other daemons that hold
>> datalinks open (e.g., wpad), we do not have any specific interlock with
>> RCM -- the admin must stop the service and then reissue the DR operation.
>> I'm not sure why we're holding vrrpd to a more stringent requirement, but
>> I'm not opposed to it.
>>   
> Yes, once the VNIC is plumbed, it will not be renamed/deleted. But vrrpd
> cannot be assured that the VNIC is always plumbed when the VRRP router
> is created. Administrators can always unplumb the VNIC whenever they
> want, even the VRRP router that relies on the VNIC is already enabled.

It's not that it's a "more stringent requirement" -- my original
question here doesn't really have anything to do with DR -- it's that I
don't understand the need to block out link renames or deletes or
creates from within vrrpd.  If the link gets renamed, and the VRRP
configuration no longer works, so what?  Isn't that exactly what the
user asked you to do?

I don't expect vrrpd to be magic.  If I configure a virtual router with
link "foobar0" and then rename it without restarting vrrpd, I'd expect
that it won't work.  Having the system actively _stop_ me from renaming
things seems unnecessarily draconian, and likely just makes it harder to
manage.

We don't do this for other services that are critically dependent on
link names (such as routing daemons), so why is VRRP different?

-- 
James Carlson         42.703N 71.076W         <carlsonj at workingcode.com>

Reply via email to