On Thu, Jun 08, 2000 at 02:47:31PM +0300, Julian Anastasov wrote:
> In LVS the "Backup" server can talk IP while in
> rfc2338 this is not allowed. In LVS, for example, we can run
> the service on all hosts and the LVS software (the Primary
> Router) on one of them. Why should we (1) keep an unused
> Backup server(s)
> Of course, it depends on your needs.
Indeed, vrrp and lvs are similar but still distinct.
LVS modifies the two peers of the connection (dispatcher and server).
VRRP is designed to work without the client being aware of it.
The primary goal is to run several routers/servers, possibly running
different services (e.g. 2 routers both route but dont advertize
the same routes). If a router crash, another one with take over its
IPs (still keeping its own ones), so the client will goes on to send
the packets to the same IP/MAC without being aware of the transition.
> and (2) why with VIP configured?
In vrrp, the backup must not have the virtual IPs 'online'. Only the
master can receive/send packets with the virtual ips.
> May be I don't understand well rfc2338, I don't
> know how you are using it. Are you trying to implement
> rfc2338 or just to build a working setup?
rfc2338 as it is specified. my current implementation works as specified
for 1 virtual group per physical interface but uses a non-standard trick
(i.e. no more handle the virtual MAC) to support several groups per
> I think, the only required kernel support can be:
> 1. not reply for these (hidden) VIPs
> - this can be solved with policy routing or other
> kind of filtering without the "hidden device" flag
Yes, i read the linux kernel thread and the arp_filter solution
of andi kleen but honestly i dont understand it. why and how to
use the route table (so a destination thing) to know if you have
to 'arp-reply' for a locally configured address (so a local thing) ?
> 2. not use them as source of the ARP probes
> - currently this can be solved if the VIP is not
> defined in the local table but in another table. But
> I'm not sure if the planned Andrey's fixes will
> allow this. Currently, arp_solicit selects only IP
> addresses from the local table which allows this
> requirement to work. After Andrey's patch they will
> be selected from any table and this requirement will
> not work.
which patch are you speaking about ?
> Jerome, can the hidden device flag solve your
> problem? Oh, I now see that may be you need this VIP to be
> on an ARP device (in the Backup server)?
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.
IFA_F_NO_NDISC is tunable per address so seems to be more flexible
than 'hidden' which is tunable per interface.
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).
Why not provide a mechanism allowing to handle ARP request/reply from
userspace ? (af_packet to sniff the reply from the network, a flag
to prevent the kernel from replying and a kind of CONFIG_ARPD to
send ARP request to userspace via netlink)
It would be flexilbe and would satisfy the needs of my other project and
vrrp. i think it would be enough for lvs too, correct ?
If i writes that, would it be more acceptable for the maintainers ?