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. Thanks - Cathy > Sebastien Roy wrote: > >> 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 >> 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. > >
