|
Hello Ratz,
On Tue, 23 Jan 2001, ratz wrote:
> > It's the same, I think the *BSD folks are not gonna change it like
> > the Linux folks ;)
>
> Julian, as it seems, Alexey and Andi are not going to deploy the hidden
> feature for kernel 2.4. But how about introducing the arpfilter? It's
> NET_IPV4_CONF_ARPFILTER for ip_sysctrl. This has more likely the chance
> of getting into the mainstream kernel. From the list:
>
> "-arp means that the kernel will not put in link layer to the packets.
> It's probably not what you want. Yes the option is misnamed. 2.2 has
> arpfilter, which will hopefully end up in 2.4 soon too."
>
> There is a patch flying around for 2.4. This patch will enable only
> answer ARP requests on this device when the routing table would send
> packets to the source it to the same device.
> Ask Alexey for more info if you don't already know ;)
These URLs are from the linux-kernel discussion. You can find here
all the arguments:
http://marc.theaimsgroup.com/?t=95743539800002&w=2&r=1
http://marc.theaimsgroup.com/?l=linux-kernel&m=95747521113399&w=2
In short: the arpfilter flag is the other variant to
block ARP: if you have two interfaces you can restrict the
ARP responses only for the routes that point to the same interface
the ARP requests come from. For example:
eth0: 192.168.0.1/24, arpfilter=1
eth1: 192.168.1.1/24, arpfilter=0
ARP broadcast request for local IP 192.168.0.1:
come from eth0: who-has 192.168.0.1 tell 192.168.0.2 answer, same dev
come from eth0: who-has 192.168.0.1 tell 192.168.1.2 drop, 1.2 is on eth1
come from eth1: who-has 192.168.0.1 tell 192.168.0.2 answer
come from eth1: who-has 192.168.0.1 tell 192.168.1.2 answer
So, with arpfilter you drop all probes in eth0 that come from addresses
reached through another interface. We can see such request when
we put the two NICs in one hub (switched or shared). With arpfilter=0
we answer through both interfaces.
In the LVS case we have setup with one NIC which can't be
solved using arpfilter. Why? Because the uplink router is on the
same route where the request come from: eth0.
The ARP problem can be explained in this way:
1. we want to talk IP with local clients or the uplink gateway
2. we don't want to talk ARP with same IP addresses in (1)
But I explained this here:
http://marc.theaimsgroup.com/?l=linux-kernel&m=95782600528062&w=2
In short:
arpfilter=1: reply only for addresses on this device
hidden=1: don't reply for addresses on this device
Oposite:) hidden=1 is the Linux 2.0 (and other unices) behavior.
May be someone can come with exotic advanced routing rules to
solve the arp problem. May be I can't see something obvious that allows
arpfilter to solve the DR/TUN ARP problem.
I thought some time for additional route flags, etc. But can't
come with something that is a more clear idea.
The selection of the VIP as source address in the ARP probes
can be avoided in this way:
ip addr add VIP/32 brd + dev lo scope host
Now we have to find a solution to block ARP, i.e.:
- ignore the ARP request (not to reply for VIP) from LAN IP
- talk IP with the same LAN IP
LAN IP in our case is: (1) Client (2) Uplink gateway
These two hosts can probe for VIP and we don't want to reply.
> Regards,
> Roberto Nibali, ratz
>
> --
> mailto: `echo NrOatSz@xxxxxxxxx | sed 's/[NOSPAM]//g'`
Regards
--
Julian Anastasov <ja@xxxxxx>
|
