|
Hi Stephen,
On Sun, 21 Nov 1999, Stephen D. WIlliams wrote:
> Of course the ARP code in the kernel needs to be fixed so my filter code
isn't
> needed. Still, I'm confused by this statement. The IFF_NOARP flag
determines
> whether a device arp replies or not. What's wrong with honoring that?
>
> If you mean that arp replies should never be sent on another interface,
that $
> what I currently believe to be correct.
>
My understanding is that 2.2.x ARP code is not buggy and
there is no need to be "fixed". I must say that your patch is
working for the LVS folks but not for all linux users.
IFF_NOARP means "Don't talk ARP on this device",
from the 'man ifconfig':
[-]arp Enable or disable the use of the ARP protocol on
this interface.
So, where is the bug ? The ARP code never talks through
lo, dummy and tunl devices when they are set NOARP. It uses
eth (ARP) device.
If You hide all NOARP interfaces from the ARP protocol
this is a bug. One example:
+--------+ppp0 +------+
| Host A |------------ppp link----------|ROUTER|------ The World
+--------+A.B.C.1 (www.domain.com) +------+
|eth0
|A.B.C.2
|
|A.B.C.3
+--------+
| Host B |
+--------+
Is it possible after your patch Host B to access www.domain.com ?
How ? Host A doesn't send replies for A.B.C.1 through eth0 after
your patch. OK, may be this is not fatal. Tell it to all kernel
users. You hide all their NOARP interfaces. May be there are other
examples where this is a problem too. Or may be there is something
wrong in this configuration?
I want to say that this patch hurts all users if present
in the kernel. On Nov 6 I posted one patch proposal to the
linux-kernel list which adds the ability to hide interfaces
from the ARP queries and replies. But the difference is that
only specified interfaces are not replied, not all NOARP
interfaces. Its arp_invisible sysctl can be used by LVS
folks to hide lo, tunl or dummy interfaces but this feature
doesn't hurt all kernel users. I think, this patch is more
acceptable and can be included in the 2.2 kernel, may be after
some tunning. And I'm still expecting comments from the net
folks and from all LVS users.
Regards,
Julian Anastasov
----------------------------------------------------------------------
LinuxVirtualServer.org mailing list - lvs-users@xxxxxxxxxxxxxxxxxxxxxx
To unsubscribe, e-mail: lvs-users-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: lvs-users-help@xxxxxxxxxxxxxxxxxxxxxx
|
