> 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. > >> The project team has supplied new materials for this case addressing > >> issues brought up by Jim Carlson. I've thus reset the timer on this > >> case. It expires on 07/29/2009. > >> > >> The changes include: > >> > >> 1. Make it clear that IFF_NOACCEPT is a per-ill flag. > >> 2. Make it clear that all vrrpadm operations are persistent > >> 3. Change /usr/sbin/vrrpd to /usr/lib/vrrpd What's the reason we settled on /usr/lib/vrrpd instead of /usr/lib/inet/vrrpd? > >> 4. Describe changes needed to support DR > >> 5. Change one of the dependency service from svc:/system/filesystem/usr > >> to svc:/system/filesystem/minimal, since we need filesystem/minimal to > >> mount /var/run directory, where the AF_UNIX socket file resides. > >> 6. Add back-up router configuration example > >> > > > > I still don't follow the need to hold the VNIC open so that renaming and > > DR are broken. If you haven't talked this over in detail with meem, I > > suggest doing so. > > > > The rest looks good to me. -- meem
