Hi Al, the Linux stack is not treating the two subnets as distinct networks as it does not know that they are in a different networks. To the stack it seems that there is one network and two interfaces in different subnets of that network. So, you have to tell the box that they are different networks. To do that you have to use policy routing like Henrik suggests. Cheers, Jonne. -----Original Message----- From: linux-net-owner@xxxxxxxxxxxxxxx on behalf of ext Al Boldi Sent: Tue 8/16/2005 07:14 To: Henrik Nordstrom Cc: linux-net@xxxxxxxxxxxxxxx Subject: Re: Kernel Routing sequence 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 - : 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
