At 11:21 PM 7/2/05 +0200, Henrik Nordstrom wrote: >On Fri, 1 Jul 2005, Zdenek Radouch wrote: > >> So, left with only a binary flag in /proc, and network definition on the >> interface, >> I assumed (perhaps naively) that the arp would proxy only for the addresses >> within the subnet defined for the interface (on which the proxy arp is >> turned on). >> However, that does not seem to be the case. > >You may be able to tune this with either arp_filter or arp_ignore. Unfortunately I can't. Not without adding more code to what is quite obviously a bunch of kludgy patches for an ill-conceived ARP proxy design. > >> I have an interface with address 10.1.2.219 and mask 255.255.255.248 with >> proxy arp turned on on this interface, and the machine is responding >> (I see that with tcpdump) to arp requests for address 10.1.2.1, i.e., >> an address outside of the proxy interface's subnet. > >Correct. > >> Can anyone explain the behavior? > >proxy_arp simply ARPs if there is a route for the requested destination >going out on another interface than where the ARP was seen. In my case, the proxy replies to a request seen on the very same interface to which the route points to. That's wrong no matter how you look at it; this is a route to which this node will be routing, i.e., this node will be ARPing for this route address - it itself should not reply to such requests, nor could it ever successfully do so. I find the idea to proxy based on routing tables quite questionable. It may work is some pretty trivial cases, but will very obviously fail with a more complex configuration. I have seven or eight networks attached to the node, and I certainly do not want to proxy for every single address one may find in the routing tables. It is equally mind boggling to me how this could ever work with a stack allowing source-based routing, that is, a stack allowing coexistence of multiple, possibly conflicting routing tables. Sounds to me like I am going to have to rewrite the module. It needs to be configured manually - the notion that it could work automagically, without external configuration is quite unrealistic, as one can see from the code in arp_filter and arp_ignore. Thanks for the pointers. -Zdenek - : send the line "unsubscribe linux-net" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html