[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: Fri, 9 Jun 2000 09:53:19 -0400
Cc: Jerome Etienne <jetienne@xxxxxxxxxx>, Andrey Savochkin <saw@xxxxxxxxxxxxx>, netdev@xxxxxxxxxxx
In-reply-to: <>; from on Fri, Jun 09, 2000 at 08:57:57AM +0300
References: <> <>
Reply-to: jetienne@xxxxxxxxxx
Sender: owner-netdev@xxxxxxxxxxx
User-agent: Mutt/1.0i
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 

> > 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

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

> 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.

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