I don't agree. The VRRP router is created with the specified VRID and address family. Ideally, if the VNIC is renamed, vrrpd should simply find the new VNIC name and start to listen to the PF_ROUTE messages for the new interface name and tracks the IP addresses configured on that new interface as well.
But we don't have the mechanism available to be informed with the renaming operation, so vrrpd will behave incorrectly. Also, if the VRRP VNIC does not exist, the router enabling operation would simply fail. Therefore, once the router is enabled, the VNIC should not be deleted for consistency purpose. Thanks - Cathy > 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? > >
