David S. Miller wrote: > > This is pretty irrelevant. If I were to change the behavior > then every who expects what we do now will break. > Can you give me one example when this works at all in the first place? > It has everything to do with your routes and the 'ip' command. > 'arp_filter' works by looking at the route it would use to get > from src to dst, and if it would go out this particular interface > where we heard the ARP it sends the response out, else it does > not respond. > Again, you're talking about ARP responses, I'm talking about ARP requests. Entirely different packets altogether. The problem is that the ARP *request* being generated by Linux is from an IP number that isn't on the subnet it's being transmitted on. 11:23:55.650514 0:4:75:ca:c4:ef Broadcast arp 42: arp who-has 10.10.10.1 tell 212.xxx.yyy.9 ... 10.10.10.1 receives the ARP request, how does it reply? It may not even have an interface on the 212.xxx.yyy network! Sure, it could just reply to the source ethernet address, but I'd hope that a router would do some level of sanity-checking! Should it add an ARP cache entry for the 212.xxx.yyy.9 address into its cache for the 10.10.10 network? No! It's dropped, as is suggested in RFC985: "An ARP request is discarded if the source IP address is not in the same subnet." I could understand what you're saying if I had two interfaces on the SAME network, and I wanted the ARP replies to go out of the appropriate interfaces ... but I've got two interfaces on different subnets, and I'm talking about ARP requests, NOT replies. Thanks, Richard - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
