Lab configuration is as follows: p3-500 dual machine running w\smp support configured with 4 3comXXXX ethernet cards with the logical addresses of 10.0.0.1/16 (base) 10.1.0.1/16 (perflab) 10.2.0.1/16 (dev/int labs) 10.3.0.1/16 (annex lab) 10.4.0.1/16 (systest lab) We have an L2TP network access system that was being tested, and an arp request was made by the linux box for a dialup client to find the return path (the lns ether address) to the l2tp/ppp client... Working Scenario: A client in perflab connects to the to the lns located at 10.1.0.163, and gets the address of 10.1.100.1. A packet goes out from the client to 10.1.0.1, and to get the return address the linux box arps for 10.1.100.1 with the source address of 10.1.0.1, of which the 10.1.0.163 box replies to the 10.1.0.1 with the approprate mac addy for the 10.1.100.1 client. Non-Working Scenario: A client in perflab connects to the lns located at 10.1.0.163, and gets the address of 10.1.100.1. A packet goes out from the client to 10.2.0.1, and to get the return address the linux box arps for 10.1.100.1 with the source address of 10.2.0.1, (but on the appropriate physical interface where the 10.1.0.1 resides). Of Which the 10.1.0.163 box ignores because it's an arp request that is out of his netmask/broadcast domain. The 10.1.0.163 box does the right thing by ignoring the arp request on the wire for an address which is out of his appropriate broadcast range. The linux box does the wrong thing by putting an arp request out on a physical interface with a source address that does not match that physical interfaces broadcast domain. Temp. fixes in the lab were to ping first the 10.1.0.1 address (adds the arp entry like in working scenario) and then go out to the world, and the other is to set the netmask on the 10.1.0.163 box to a /8. and add static routes to each of the /16 nets to maintain interlab communication. But this should be fixed, especially if more people (which in the future I am sure will) plan to use linux (specifically redhat) for lab routers, and test tools. I think that this may fall on the wrong ears, and if so.. please forward this to the caretakers of the code where this bug is located...
iproute is not part of Red Hat Linux 4.2