[Top] [All Lists]

Re: per-route arp control

To: Andrey Savochkin <saw@xxxxxxxxxxxxx>
Subject: Re: per-route arp control
From: Julian Anastasov <ja@xxxxxx>
Date: Fri, 8 Jun 2001 11:40:21 +0300 (EEST)
Cc: "David S. Miller" <davem@xxxxxxxxxx>, ak@xxxxxx, kuznet@xxxxxxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <20010607212735.B26392@xxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx

On Thu, 7 Jun 2001, Andrey Savochkin wrote:

> Hi,
> > 2. Part two: source address selection for our probes
> >
> > - semantic: "in our probes announce the preferred source address for
> > the target if the original route in the skb is marked noarp"
> I consider it superfluous, and I don't see any symmetry here :-)
> If you maintain the proper configuration, i.e. specify preferred source for
> output routes, you should be fine.

        But I'm not fine :) I made tests and they show that my shared
address is announced as source in our probes because it is present
in skb->dst as pref_src :) You know, any local address can be in rt_src
in these routes because the higher protocols fill skb->dst by using
ip_route_output(&rt, world_ip, local_ip,...) while when we use
ip_route_output(&rt, arp_target, 0,...) in arp_solicit we load rt_src
with the preferred source to this target. So, my shared address is present
in rt_src and I need a way to fallback to the second ip_route_output.
For this, I can add ip rule + noarp route to mark the output route as
"not useful" for our ARP probes.

        The symmetry is here: when we don't reply for one IP => we
don't announce it in our probes. While other setups don't talk
with such IP (I'm not sure why they simply not remove this IP) in
my setup I still need to talk IP with this shared IP and this always
leads the shared IP to be present in pref_src, bad for ARP.

> >     Sometimes we don't want to announce particular addresses, for
> > example, if they are marked hidden/noarp in local routes - the symmetry.
> > In this case we add noarp route and then fallback to the preferred
> > source address no matter it is marked as hidden. The RTCF_NOARP flag
> > in the output routes is checked in this case (arp_solicit):
> >
> > ip rule from ...
> > ip route add ... noarp
> >
> >     Andrey, I see that in your current route.generic version
> > arp_solicit always fallbacks to the preferred source address to the
> As I've said that code wasn't completely correct.

        No, when noarp is set for one route this flag does not control
the both directions because one route is not used both to check the remote
probes and in the announcement. For my setup I need to set this flag
explicitly to two routes, not only to one. Other users may be will need
only to set it only to one route (the local route). I remember that
Jerome Etienne <jetienne@xxxxxxxxxx> has something similar for
VRRP (IFA_F_NO_NDISC). He will need to set noarp for a local route
only, i.e. only to drop the replies. But now there is nothing that
prevents this address to be announced in our probes (if any). I don't
know whether this hurts him. For my setup the announcement is a problem
because I talk IP with this ip.

        For my setup I have to add second rule+route to change the
announcement too. This second unicast route must not allow announcement
of the same shared addresses blocked by the first noarp local route.

        So, the symmetry is user defined. RTCF_NOARP does not work in the
both directions, may be only when you want to ignore the probes for
some unicast routes (proxy_arp?). Then for the announcement the preferred
source to the arp target will be used. May be this is the only case where
it is possible one route to be checked for both the ARP probes and replies.
But you always can add more specific ip rules that will point to two routes,
one with noarp flag and another without such flag. We are in the world
of the "routes" :))) Yes, my example is hard to setup with this noarp
flag (the second part, the announcement). May be there is alternative
to control the announcement with routes? I'll tell it again: for my setup
I'm not interested in the old route in skb->dst and I prefer always to
fallback to ip_route_output but I'm not sure who relies on the pref_src
in skb->dst. But in the current implementation (when we use skb->dst)
I need a way to control the announcement too. May be we can find a
better solution/semantic.

> For the remaining of your code and RTCF_NOARP additions look fine for me.
>       Andrey


Julian Anastasov <ja@xxxxxx>

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