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.
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.
Best regards
Andrey V.
Savochkin
|