|
Hello,
On Tue, 11 Jun 2002, Michael McConnell wrote:
> Julian I appreciate your advise and have enable this particular flag on our
> test production enviroment and am still in my early phase of testing.
>
> I did some searching on google for arp_filter and rp_filter, a few documents
> and news threads came up, most of which were either written by you, or
> refered to your web page. (-; I'm still trying to understand exactly what
> these flags do, I can find no solid explaination as to how they will change
> the kernel's behaviour. I've taken a look at arp.c and well, I don't really
> understand that function....
OK
By default Linux replies to ARP probes for any local
IP address configured on any device no matter on what device the
probe is received. Such probes look like "who-has TARGET tell SENDER".
If the probe is answered later we can receive IP traffic from
SENDER to TARGET destined to the TARGET's MAC address.
When we have different subnets (network routes) configured
on multiple interfaces attached to same hub sometimes we prefer (may
be the reader can find good reason for this) the traffic to/from one
subnet always to use one interface. In such cases replying through
many interfaces is not desired. We have 2 options:
arp_filter:
when /proc/sys/net/ipv4/conf/DEV/arp_filter is set to
1 or /proc/sys/net/ipv4/conf/all/arp_filter is set to
1 then the flag will cause any probe received on interface
DEV to be dropped if the route from TARGET to SENDER points
to different interface. With the usual local networks in
table main in the form "from 0/0 to local_net lookup main"
we see that the TARGET is ignored. As result, we drop
probes received from SENDER that comes from wrong
interface. As result, if the route from TARGET to
SENDER1 is via DEV1 and from TARGET to SENDER2 is
via DEV2, then we will reply only through one device
for each of the senders. Of course, the arp_filter
relies on the routing and as result the bahavior
depends on the used ip rules and routes. The above
is a simple example for normal local networks. The
arp_filter simply checks the route for the reversed
addresses. It should point to the input device.
rp_filter:
The rp_filter flag (DEV/rp_filter or all/rp_filter)
set to 1 has similar semantic. It has nearly the same
function as arp_filter and can control the ARP for
the same purposes: symmetric talks (in and out using
same device) but it covers the IP traffic too. It is
assumed that where ARP is received (replied more
exactly) there the IP traffic will be accepted too.
It has mostly security function and can defend
against IP spoofing. It controls the reverse path
protection: we accept traffic from SENDER to TARGET
received on DEV only when the reverse path (from
TARGET to SENDER) points to the input interface
DEV. It is used usually for "external" interfaces.
How you can use it:
ifconfig eth0 192.168.1.2
ifconfig eth1 192.168.2.2
echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_filter
echo 1 > /proc/sys/net/ipv4/conf/eth1/arp_filter
> If you, or anyone for that matter could elaborate on exactly how my kernels
> behaviour will change by enabling / disabling these flags I would greatly
> appreciate it.
>
> Thanks again, Michael
Regards
--
Julian Anastasov <ja@xxxxxx>
|
