Actually, your suggestion would break routing where asymmetric routes exist (where you have one-way connections). These are common in radio-based networks. Basically, you have a mis-designed network. Overlapping subnets are a bad idea, although you can make them work. As I (and others) have mentioned, policy routing will make it work. If you need more flexibility, then CONNMARK will aid you. Can you (as others have also asked) give us a diagram of your network and explain why you have overlapping addresses? With a Class A network (10.0.0.0) you should be able to subnet it so that there are no overlaps. On Tue, 2005-08-16 at 07:14 +0300, Al Boldi wrote: > 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
