On Tuesday 03 June 2003 20.56, Martin wrote:
The other thing is that doing routing the way the default gateway is on the different IP subnet then host even being on the same physical 'cable' impose significant performance degradation as for each packet there has to be done recursive route lookup
Standard scenario: packet to 1.2.3.4 routing table 192.168.0.0/24 eth0 0.0.0.0 192.168.0.1 Match rule 1? No Match rule 2? Yes, so send packet to 192.168.0.1 New packet, containing the first, but embedded in a packet targetted for 192.168.0.1 Match rule 1? Yes, so arp for 192.168.0.1 and ship it off on eth0. Weird scenario: packet to 1.2.3.4 routing table 192.168.0.0/24 eth0 10.0.0.1/32 eth0 0.0.0.0 10.0.0.1 Match rule 1? No Match rule 2? No Match rule 3? Yes, so send packet to 10.0.0.1 Match rule 1? No Match rule 2? Yes, so arp for 10.0.0.1 and ship it off on eth0
plus arp-ing,
You always get arping, and I don't see why the arp cache should cease to function just because it's on a different subnet. Remember, the arp protocol doesn't know about subnets. It should cache both. As far as I can see, you may get an extra rule lookup from it, but it shouldn't affect performance in any directly noticable way
so even Anders showed it's possible to make it work it's not the best practice.
Of course it's not best practice. Neither is having localhost as default gateway, or running Red Hat. There wasn't much in that mail that had "best practice" :)