On Fri, Jun 09, 2000 at 08:57:57AM +0300, Julian Anastasov wrote:
> The transition is not so easy as you said. In LVS the
> dispatcher keeps state for each connection to the real
> hosts. When switching from one router to another after crash
> you usually lose this connection table. So, all current
> connections are broken.
no, because this connection tracking doesnt exist in vrrp
and is specific to LVS. vrrp and lvs dont have the same
aim.
> > In vrrp, the backup must not have the virtual IPs 'online'. Only the
> > master can receive/send packets with the virtual ips.
>
> OK, VIP is configured in the Master, not in the
> Backup. Or it is configured but flagged with
> IFA_F_NO_NDISC?
no, it is configured only in the master and always with IFA_F_NO_NDISC
> Is it configured in the real hosts?
i dunno what you mean by real hosts. vrrp doesnt have such thing.
It is configured only in the servers and the clients arent aware
of vrrp at all.
> Is NAT running in the default routers?
NAT is completly unrelated to VRRP. running it or not wont change vrrp
action.
> 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.
> 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)
> > I think so, i coded IFA_F_NO_NDISC because i wasnt aware of 'hidden'.
> > It isnt in the kernel source i looked in i.e. 2.4.0-test1.
> > As our needs are similar, we should use the same mechanism.
>
> I'm still not sure how the packets look exiting
> from the real hosts in your implementation. You have to
> explain this because I can't imagine how your setup is
> working. Without the above two requirements you patch is not
> working for LVS. If VIP is configured as address and so put
> in the "local" table it can be used as source in the ARP
> probes. I see this in your "MUST NOT"s for the Backup host.
> But this is requirement for all backup/real servers in LVS.
> So, your patch must be tuned if the net folks like the idea
> of this address flag. You have to patch inet_select_addr()
> too. The problem is arp_solicit, i.e. which local addresses
> are allowed in the ARP probes. This is decided from the
> routing. Your patch and defining VIP as interface address
> will allow using VIP in the ARP probes. But this is in our
> "MUST NOT". So, the big question is how you will put the
> IFA_F_NO_NDISC flag in the routing code (fib_lookup).
i fail to see why i should. To know if i answers to a ARP
reply for a locally configured address doesnt seems related to
the routing code to me. it is related to the configuratoin
of the local addresses so typically IFA_F_*.
> > IFA_F_NO_NDISC is tunable per address so seems to be more flexible
> > than 'hidden' which is tunable per interface.
>
> This is not a problem. Just put your VIP in lo or
> dummy device and be happy. There is no difference at all. I
> don't know why you/rfc have VIP configured if you want the
> VIP to be so hidden (even not to talk IP).
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.
> 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
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
> > 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.
> And please explain how the packets from one client
> request and the answer traverse all hosts in the cluster.
there is no cluster, and packet dont traverse any nodes in vrrp.
it is a pure LAN matter. lvs and vrrp are different.
|