[Top] [All Lists]

Re: IFA_F_NO_NDISC (for vrrp)

To: Julian Anastasov <uli@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: IFA_F_NO_NDISC (for vrrp)
From: Jerome Etienne <jetienne@xxxxxxxxxx>
Date: Thu, 8 Jun 2000 13:03:23 -0400
Cc: Andrey Savochkin <saw@xxxxxxxxxxxxx>, jetienne@xxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <>; from on Thu, Jun 08, 2000 at 02:47:31PM +0300
References: <> <>
Reply-to: jetienne@xxxxxxxxxx
Sender: owner-netdev@xxxxxxxxxxx
User-agent: Mutt/1.0i
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[1] 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 ?

<Prev in Thread] Current Thread [Next in Thread>