Thanks for your valuable input! Henrik Nordstrom wrote: > On Mon, 15 Aug 2005, Al Boldi wrote: > > The problem is that the kernel is routing according to a fixed > > view of allowed subnets, ie: overlapping subnets are not treated > > distinctly. > > > > It should be possible for the kernel to detect an IP > > subnet-collision on packet pickup, something like: > > > > eth0 is listening on 10.0.0.0/8 > > eth0 picks up 10.0.1.2 on 10.0.0.0/8 > > kernel checks the route table > > kernel discovers collision with 10.0.1.0/24 on eth1 > > kernel adds 10.0.1.2/32 route on eth0 to ensure correct routing > > for return packets > > And what do you propose it is supposed to do when it later sees a > packet from 10.0.1.2 on eth1? kernel discovers collision with 10.0.1.2/32 on eth0 kernel removes route 10.0.1.2/32 on eth0 > What you are looking for above is policy routing as mentioned > numerous times in this discussion. With policy routing you simply > define that return traffic from 10.0.0.1 (eth1) to 10.X goes out on > eth0 and things just works with the only restriction that clients > on eth1 (10.0.1.2/24) should talk to 10.0.1.2 and clients on eth0 > (10.0.0.1/8) should talk to 10.0.0.1. Is policy routing dynamic? > If you at all need to look at these features (policy routing and > especially in combination with CONNMARK) then you are already in > quite deep murky waters, and should consider redesigning your > network. Yes, because the kernel does not treat overlapping subnets as distinct. Actually there is no such thing as a subnet in the current implementation, but rather a subnet is treated as a group of IPs. Calling groups of IPs a subnet is very misleading. > But all of this can be adjusted to your liking. Yes, but the kernel should default to an intuative way, ie: return packets to the intended client. Especially when this can be easily implemented via routing only. -- Al - : 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