This is RFC - per-route ARP control for Linux 2.4 in two parts:
a) filtering ARP probes
b) selection of the source IP in the ARP probes
there are attached patches
1. Part one: filtering ARP probes
- semantic: "don't reply for input routes marked noarp"
- we add "noarp" flag for the "ip route" command
- we add "hidden" flag for the "ip addr add" command and this is
propagated to the created local route, i.e.
"ip addr add IP[/mask] ... hidden"
is converted to
"ip route add table local local IP[/mask] ... noarp
- we don't distinguish broadcast/unicast probes (skb->pkt_type), may
be this is useful in cases where we must block the unicast probes too.
Who relies on the unicast probes to continue to reply (as in
"hidden" for 2.2)? IMO, it can't fit into the NOARP semantic, we
must not reply. Alexey?
- only local and unicast routes are filtered, for example:
a) local routes
ip route add table local local 192.168.0.100 dev lo noarp
b) unicast routes
ip rule add prio 100 from 192.168.0.100 table 100
ip route add table 100 default via 192.168.0.1 dev eth0 src 192.168.0.2
- the duplicate address detection code is not touched, do we need changes
there? As I see, ip_route_input can't be used.
The risks always exist if the "hidden" IP is used to talk IP to some
remote hosts that later will send probes and we will drop them with
noarp route but what routes are marked noarp is entirely under user
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"
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
target, so the above 2nd part will disappear (it is a bit difficult to
use the above 2nd part from user space with ip route :( but it is easy
for kernel :) ).
The patches are attached:
noarp-2.4.5-1.diff - the kernel patch on top of Andrey's (and/or
Alexey's?) arp patch but I added additional check for rt!=0
in arp_solicit which disappeared after the first version
iproute2-noarp-1.diff - the supplementary patch for
I hope these ifdefs are the only way to compile iproute2 with
kernels that don't support *HIDDEN and *NOARP defines. Or may
be we can add the same functionality to 2.2?
The same patches will be here:
Julian Anastasov <ja@xxxxxx>
Description: per-route arp control, patch against 2.4.5
Description: iproute2 changes for per-route arp control