On Fri, 9 Jun 2000, Andrey Savochkin wrote:
> 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
> 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 192.168.0.1 tell 192.168.0.2", where
192.168.0.1 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 192.168.0.2 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
So, only by defining additional logical network (the
main network 192.168.0.0/24), 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
> 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
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>