Hello,
On Tue, 22 May 2001, Andrey Savochkin wrote:
> > - is rt_src always local in 2.4
>
> For output routes, it is.
> It's either a local address or a preffered source from FIB.
> We, actually, do not need to bother about whether it's local or not because
> it's what administrator explicitly specified as a source for outgoing
> packets.
Yes, my doubt was about games with raw sockets but I see the
restriction in ip_route_output*, so no problem.
> But, nevertheless, preffered sources are currently checked for being local
> when the entry is being added.
>
> > - ONLINK
>
> I'm not sure about it.
> Providing ONLINK, you only reduce the chances of ip_route_output to succeed
> and increase chances to not to send any packet.
But this increases the chances we to send invalid source, eg.
if ip_route_output relies on inet_select_addr. When using ONLINK we
restrict the routes to RT_SCOPE_LINK, as it was before this patch.
I'm not sure whether this is fatal, i.e. address from eth1 will be
announced to eth0 and by this way we can change the arp table entry
in some LAN hosts reachable through eth0. But your words are the final
ones. I'm only thinking and ... I'm not sure.
> If the destination doesn't belong to the directly attached network, something
> is wrong, but, well, why not to send the packet if we have it?
> The source we select is legal...
Yes, the source is really local IP address but we will update
an entry in remote hosts and probably they will send us the next packets
to wrong device (bad with rp_filter protection). This happens if rt_src
is filled with local IP from another device. But may be I'm speculating
here and this is not possible :)
> A fixed patch is attached.
It looks good for me
> > > The second patch is for Julian.
> [snip]
> >
> > Filtering by routes is not my dream but give me some days to
> > think on it (of course this patch #2 is not for 2.4.5, I hope :)).
> >
> > - In my case control over the announced source in the probe is needed
>
> You already have it, it's preferred source in your routes.
Not always, I assume in my case the current rt_src will be used
which is in fact the same shared IP (it is local and can appear in rt_src
before arp_solicit), may be we will not reach this ip_route_output that
we are adding now. But I'll make some tests with #2 soon.
> > - RTF_NOARPREPLY: is it for unicast routes only? The filtering isn't
> > for routes to local (ip_route_input)?
>
> I don't understand you well.
> RTF_NOARPREPLY is for local routes.
Yes, the flag usage in arp.c is right but why it is defined in
include/linux/route.h where UNICAST routes only are created (I'm
looking in fib_semantics.c:fib_convert_rtentry). Is the flag for the
"route" command or for "ip route"?
> Generally, receiving arp request we check if it's for our local address (by
> that ip_route_input).
> We ammend this check by additional one, whether ARP replies are disabled for
> this local address or not.
So, do I need something like this (and flag in another .h file)?:
ip route change table local local 10.0.0.1 dev eth0 noarpreply
Not an atomic operation but anyway. I'll be very happy if this
flag is applied automatically to the IFF_LOOPBACK interface(s) for
RT_SCOPE_HOST addresses but this is may be only a my dream. Then I
can simply ip addr add SHARED_IP/32 dev lo scope host. So, this is
my next proposal. Do we hurt some users? We will not reply for
scope host addresses defined in dev lo?
Currently, due to the fixed priority 0 of the local table it seems
I can't add these addresses to table local if I need to apply different
behavior (drop/reply) for some requestors. And Alexey claims it is very
bad to add local addresses that are not in the local table due to many
dark places in the net/ code. We found, for example, one case with
icmp_send that is not very helpful with local addresses not in the
local table. It seems the net code is not very ready for such games.
There are many ip_dev_find calls and the problem with icmp_send is
the call in ip_route_output. There is no symmetry.
So, I assume the "route" command is of no help here? I need ip
route and the ability to specify ip rule from ... But really, for LVS this
rule is not needed. In fact, the hidden flag works just like the above
ip route change command, i.e. we can't mute for some requestors and
for others to reply, we filter for all. One day when we can add local
addresses out of the table "local" we will have more control. But there
is one difference from "hidden". The hidden flag is not so mandatory,
hidden does not stop replies to unicast probes and when they come from
the same device but these are "other features" and may be these features
can be allowed only when ip rule control is possible for these noarpreply
addresses.
And I have to test the arp_solicit support for my case. I'm
not sure if it is solved with patch #1.
> Andrey
Regards
--
Julian Anastasov <ja@xxxxxx>
|