|
Julian your explanations of the arp_filter and rp_filter are excellent.
Thank you for taking the time to clarify these for me.
Perhaps is Mr. Mack can find the time, your comments regarding this flags,
would be a nice addition to the how-to.
Thanks again,
Michael McConnell
----- Original Message -----
From: "Julian Anastasov" <ja@xxxxxx>
To: "Michael McConnell" <michaelm@xxxxxxxxxxx>
Cc: <lvs-users@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Tuesday, June 11, 2002 5:38 PM
Subject: Re: arp responses by dual port eepro100
>
> 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>
>
>
> _______________________________________________
> LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
> Send requests to lvs-users-request@xxxxxxxxxxxxxxxxxxxxxx
> or go to http://www.in-addr.de/mailman/listinfo/lvs-users
>
|
