Cathy Zhou wrote:
>> 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.
>>
>
> That's a good point. I will change the source selection logic to not
> including the no_accepted IP addresses.
I'm not sure that any VRRP addresses are appropriate for automatic
selection -- but I guess that's a topic for a deeper discussion about
using VRRP for application protection.
>>> 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 ... ?
>>
> I am nervous to make such changes since that will probably confuse
> applications consuming the IFF_ANNOUCE messages.
I don't see how that's possible, given the bit vector used for the
extensible parts of a routing socket message ... but ok.
>>>> 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?
>>
> No, it cannot. But since we don't control the management of the IP
> addresses, one could unplumb the VNIC while the VRRP router is enabled,
> and even delete the VNIC and then probably create a inrelevant link with
> the old VNIC name. That is what we want to avoid. Since the vrrpd would
> assume that the new link is the VNIC that we need track the IP addresses
> on and make the wrong assumption what would be the virtual IP addresses.
The user could do all sorts of things that might make a mess of the
daemons that manage automatic interfaces. I don't think that means that
it's a good idea to try to prevent such administrative changes.
Unless I'm missing something, this sounds like a very different practice
from what we've had in place for pretty much all the rest of networking,
and it seems to require elevated and otherwise unnecessary privileges in
order to accomplish. I'm not sure what to make of it, but it sounds
like too much work to me.
If the user deliberately thwarts the VRRP daemon by reconfiguring things
in ways documented not to work, what's the worst that happens? It
doesn't work properly until restarted, right?
