On Mon, 12 Jun 2000, Andrey Savochkin wrote:
> > 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 :)
> Using inet_addr_type() in arp_solicit(), especially the current one looking
> into local table only, is wrong from conceptual point of view.
> It makes decisions that can't be explained in human terms, only as some
> manipulations in C language.
> It's better not to call any checking function that to call wrong one.
> I'll call fib_select_addr() unconditionally.
Without calling fib_local_source() the situation is
different. This leads arp_solicit to use limited number of
local addresses in some situations and may be will allow not
to include hidden addresses in the ARP request.
To summarize the problem without the hidden flag. If
we have a client on the LAN and our host with the hidden
address we need:
1. route from CLIENT to Hidden address to go in the blackhole for ARP
2. the same
route from CLIENT to Hidden address to return RTN_LOCAL for non-ARP
3. arp_solicit not to include hidden addresses in the ARP request
(1) and (2) can't coexist in the FIB world. May be if we
play with fwmark? So, we need a way to distinguish them by
using other methods. I'm not sure if we can add something
like ip add route "shared" VIP table 100. RTN_SHARED will be
handled as RTN_LOCAL but the difference will be for ARP.
This leads to big changes in the routing (RTN_SHARED subset
of RTN_LOCAL) and I don't want to make such big changes. In
many places we will need:
if (type == RTN_LOCAL || type == RTN_SHARED)
May be if we change the RTN_ values from enum to flags, for example:
if (type & RTN_LOCAL)
In some places we will check:
if (type & RTN_SHARED)
We will have:
#define RTN_SHARED (RTN_HIDDEN | RTN_LOCAL)
But this is a big change.
I will continue to think on this problem. For now,
I'm sure I can't do it with current policy routing rules.
Any ideas are welcome.
Julian Anastasov <uli@xxxxxxxxxxxxxxxxxxxxxx>