[Top] [All Lists]

Re: IFA_F_NO_NDISC (for vrrp)

To: Andrey Savochkin <saw@xxxxxxxxxxxxx>
Subject: Re: IFA_F_NO_NDISC (for vrrp)
From: Julian Anastasov <uli@xxxxxxxxxxxxxxxxxxxxxx>
Date: Fri, 9 Jun 2000 15:03:44 +0300 (EEST)
Cc: Jerome Etienne <jetienne@xxxxxxxxxx>, netdev@xxxxxxxxxxx
In-reply-to: <20000609161159.A19020@xxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx

On Fri, 9 Jun 2000, Andrey Savochkin wrote:

> Hello,
> On Fri, Jun 09, 2000 at 10:56:34AM +0300, Julian Anastasov wrote:
> >     I   want   to   ask  you   about   arp_solicit.   Is
> > inet_addr_type()  going to die?  I see it  is still used. My
> > question    is:    can   arp_solicit    continue    to   use
> > inet_addr_type()  as in the  current kernel and  not to call
> > fib_local_source()?  You still can  call fib_select_addr. Is
> > there a good reason to change it?
> > 
> >     By this way we limit the local addresses that we can
> > announce  in our ARP probes. I'm not sure if this will break
> > something  but that will allow addresses not included in the
> > "local"  table not to  be announced. This  will help to hide
> > these addresses. But I agree, may be this is a hack. We will
> I suppose, the kernel looked only in local table only for optimization
> purposes under assumption that nobody wanted to insert local addresses in
> other tables.  But it is very necessary for source routing and proper
> ordering of routing lookups.
> A most simple example: I get network a.b.c.0/28 for some hosting.  I assigned
> a.b.c.d for gateway and use other addresses as local for virtual servers.  I
> write:
>       ip route add a.b.c.d dev eth0 table 10
>       ip route add local a.b.c.0/28 dev eth0 table 10
> That's fine.  But if I'm forced to reorder entries to put all local addresses
> in local table, I can't add a route for such a.b.c.0/28 prefix.

        Yep,  may be there are  cases where local routes can
be  specified not  in the  "local" table.   But if  we don't
change  the call  in arp_solicit()  from inet_addr_type() to
fib_local_source(),  we  will  use IP  from  another logical
network,  i.e.  returned  from  fib_select_addr().   I don't
think  this is  a big  problem.  Our  gateway always  can be
configured  with other  IP address because  we usually don't
define  only a.b.c.0/28 in our host.  Of course, our request
will  look:  "who-has  tell", where  and a.b.c.d are configured in the router and we
send  our probe after  the request "client  -> a.b.c.e". But
because  a.b.c.e is not  defined in the  "local" table it is
not found from inet_addr_type(). The result: we send a valid
ARP  probe  (with  saddr  and daddr  from  the  same logical
network) using as source of the request.

        Is this a big problem? To use another IP as gateway?
>From  the same device?  I assume the  only requests from the
router  will be "who-has a.b.c.e  tell a.b.c.d". But we will
reply for a.b.c.e because it is local (in any table):
"a.b.c.e  is-at  OUR_MAC", we  use ip_route_input()  in this
case which returns RTN_LOCAL.

        Is  that  working :)  The drawback  is that  we will
probe  only with  addresses from  the "local"  table. If all
hosts  share this  logical network  it is  not a  problem to
support  many  additional logical  networks as  specified in
your example.

        So, only by defining additional logical network (the
main  network, which is usual because we add
our new a.b.c.0/28 network as an additional network we solve
this  problem. The  result: we  can add  additional networks
with  any  prefix but  to use  our  main logical  network to
resolve our ARP requests.

> Adding local routes into non-local table you just explore some kernel
> optimization.
> We've discussed arp_solicit with you.
> As far as I remember, we agreed that always using fib_select_addr as a source
> address for the arp requests, independently if we may use skb's source,
> is good for you.  It's ok for me, too.

        Yes, using fib_select_addr() is not a problem. Oops,
sorry,  my  question  was  for  fib_local_source(),  not for
fib_select_addr()  but you  understood me.  We  want to keep
using  inet_addr_type()  instead  of  fib_local_source()  in
arp_solicit(). Only there. And it is not a problem the hosts
to  be involved  in same  logical network  to allow  them to
define  any number  of additional logical  networks as local
but  not in  the "local"  table.  I  think, this  can't be a
problem  for any user which can  add routes in other tables,
i.e. not only in the "local" table :)

        So,  can we just in this case to use inet_addr_type?

        I  now see  that inet_addr_type() is changed too, to
use  fib_lookup. I forgot about this.  Yep, with this change
we   can't  do  this  (to   limit  the  local  addresses  in
arp_solicit).   I have to wait for the final version of your
patch :)

        For  now, without the hidden  flag, the only problem
is  that we  can't allow  clients on  the LAN  to access the
hidden  addresses in the real servers.  We have to live with
it. Or to allow it with patch :)

        The last words: IFA_F_NO_NDISC with arp_solicit
calling original inet_addr_type is acceptable for LVS. This
will allow local clients to talk with the cluster. But is it
acceptable? If this is not true, LVS don't need
IFA_F_NO_NDISC (this version of the patch).


Julian Anastasov <uli@xxxxxxxxxxxxxxxxxxxxxx>

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