Hello,
On Fri, 9 Jun 2000, Jerome Etienne wrote:
> > How looks the packet from
> > the real host through the default router? Now I don't know
> > in which host you want to stop replying for VIP.
>
> in fact the virtual ip owner have to answer to ARP request for the virtual
> IPs. Currently the kernel can't reply with the virtual mac for the
> virtual IPs because this imply differents MACs if the several groups
> are configured on the same interface. so i prevent the kernel from
> replying and let a userspace deamon do it. my first email explains
> it better.
Oh, well. I reread the rfc. I read mostly the MUSTs
first time and didn't understand the difference in your
tests.
>
> > I read it. But I don't know if you tested only the
> > Master-Backup operations (which is the scope of this rfc).
> > Because I'm not sure the setup described in rfc2338 (which
> > is very limitted) will work without NAT-ing packets in the
> > Linux dispatcher. If they are NAT-ed I don't know why you
> > have VIP in the internal hosts.
>
> as i said lvs and vrrp are similar but distinct. vrrp
> has no dispatcher, and no notion of internal host.
>
> > Where are VIPs, except in the Master, configured, even specified
> > with this flag?
>
> the vip are configured as a local interface address only in the master.
>
> in the clients, vips are used only as destination (any nodes which wish to
> send packet to this ip) but the clients arent aware that this ip is virtual.
> so the client has no special configuration, their interface doesnt accept
> packet destined for the vip (so they dont use IFA_F_NO_NDISC)
Now I understand.
> the rfc doesnt want the virtual IP to be unused at all, they are used
> for xmit/recv as any ip. It want that a ARP request for a vip is
> replyed by a ARP reply containing the virtual mac. i use IFA_F_NO_NDISC
> only as a trick to prevent the kernel from replying and thus reply from
> the userspace.
OK
>
> > Just don't
> > configure VIP. May be I don't understand something, you
> > have to explain it.
>
> maybe you should reread my first email on netdev and possibly
> reread the rfc without thinking it is a way to do LVS. vrrp
Already done.
> and lvs have different aims.
>
> > > Thinking about it, i have another project in which i need to completly
> > > handle ARP reply and request in user space (still keeping the cache
> > > in the kernel).
> >
> > Playing in user space is preferred. But we need to
> > accept packets destined for VIP in the real hosts (where we
> > hide these addresses).
>
> to accept or not packet for the IP(virtual or not) is unrelated to ARP.
>
> > So, we need the mechanism to select
> > IP addresses as source for the ARP probes to be determined
> > in the kernel. It is not possible to control this from user
> > space.
>
> i dont see why. please elaborate on that
Look in arp_solicit (2.2). I'm talking about
selecting the source address in the ARP requests not for ARP
replies. But now I understand your problem.
>
> > > If i writes that, would it be more acceptable for the maintainers ?
> >
> > I'm not sure. I'm not against your patch but I think
> > it will include the same requirements as the patch for the
> > "hidden" flag.
>
> yes but with the same requirement, IFA_F_NO_NDISC is more flexible.
> nevertheless it isnt the point. I try to provide the mechanism
> flexible enought to satisfy our current needs and the potential
> future one. handle ARP packets in user space allow to implement
> any custom behaviour easily.
Good luck! IFA_F_NO_NDISC is not a complete solution
for LVS. The "hidden" flag has other semantic and the goal
is to mark part of the local addresses as shared (hidden).
This is different from IFA_F_NO_NDISC. We need to control
which addresses can be announced in the ARP probes too.
Regards
--
Julian Anastasov <uli@xxxxxxxxxxxxxxxxxxxxxx>
|