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. > What's the reason we settled on /usr/lib/vrrpd instead of > /usr/lib/inet/vrrpd? > If /usr/lib/inet/vrrpd is a better place. I can certainly change that.
Thanks for your comments. - Cathy
