James Carlson wrote: > Cathy Zhou wrote: > >>> This seems to describe IFF_NOACCEPT as a per-ipif flag. Is that the >>> right granularity? It seems odd to me that we could potentially >>> configure the system to have some addresses that respond and some that >>> do not. The point of "no accept" mode is to behave as a real VRRP >>> system. If you want that, I don't think you'd want it just some of >>> the time, would you? >>> >> You are right. I can add a per-ill flag. But since I would also like >> this flag to be observable by the administrator, I will keep the >> IPIF_NOACCEPT flag so that ifconfig bge0:1 will be able to show this >> address is set to be "no_accept". >> > > I don't understand. > > The IFF_* flag space is subdivided into flags on ipifs (IPIF_*), flags > on ills (ILLF_*), and flags on phyints (PHYINT_*). Those are all OR'd > together when delivered to user space. > > Thus, at least for observability, it does not matter where you put the flag. > Sorry that I wasn't clear. I meant to keep IFF_NOACCEPT and change its definition to be:
#define ILLF_NOACCEPT IFF_NOACCEPT > Yes. My argument, though, is that it doesn't actually matter if the > address is marked "UP" but (for reasons outside the application's > control) is not currently usable on the wire. At most, lack of network > connection is a reason to avoid that address when doing source address > selection -- but, then, you almost certainly should be avoiding these > VRRP-controlled addresses when doing source address selection for > outbound connections anyway. > Sorry, why cannot application use the virtual IP addresses as the source IP address, if the router is currently master? >> I looked but didn't see things similar to it. BSD does provide a >> IF_ANNOUNCE message to indicate the plumbing/unplumbing of the interface >> but that cannot satisfy my needs. >> > It'd probably help to describe that message and why it doesn't provide > the information needed. (In fact, that message is exactly what I'd > expected was needed ...) > As far as I know, the IFF_ANNOUCE only indicate the plumbing/unplumbing of the interface, not the address (the logical interface). That is why we cannot use it for our purpose. > >>>> - priv_net_rawaccess >>>> >> To prevent the data-link from being deleted or renamed. Note that we >> don't require the underlying interface and VNIC to be plumbed when the >> router is enabled. Instead, the PF_ROUTE socket will track all the IP >> addresses configured over the underlying interface and VNIC and >> determine the primary IP address and virtual IP addresses. >> > > Why do you care whether the underlying link is deleted or renamed? > > How does that work with DR? > When the VRRP router is first enabled, we check which VNIC is the associated VNIC and make sure it is created (otherwise, enable-router would fail). Then we listen to the PF_ROUTE messages to track all the IP addresses over this VNIC based on its interface name. If the VNICs is deleted or renamed in between, that would be a problem. Thanks for remind me of DR. I believe adding a router_rcm plugin is possible. Thanks - Cathy
