Cathy Zhou wrote:
> James Carlson wrote:
>> 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
OK.
>> 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?
At least for the routing version of VRRP (that is, "no accept" mode),
the virtual IP address is for the convenience of configuring routing on
dumb hosts, and intentionally not for regular communication.
Obviously, communication using that IP address won't work at all from
the non-address-owning node, because when it's master, it's not allowed
to accept packets there.
>From the address-owning node, it's possible, but usually you have better
(less volatile) addresses to use. An address that moves around leaves
questions about who exactly you're talking to.
In the non-routing mode ("accept" mode), I'm not sure what the right
practices are. That mode of operation is new (it's still just a draft,
I think) and still isn't clear to me.
>>> 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.
Ah, so you want the address on "plumbed-but-down" interfaces, is that it?
Why can't IFF_ANNOUNCE on Solaris include an address ... ?
>> 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.
Can they be deleted while IP is configured?
I'm still confused about what the problems are. It'd be good to have a
description of the problems in the specification to make it clear why
these things are being held open.
> Thanks for remind me of DR. I believe adding a router_rcm plugin is
> possible.
It may be necessary.
