Re: Kernel Routing sequence
From: Al Boldi
Date: Mon Aug 15 2005 - 23:15:40 EST
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
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.
To unsubscribe from this list: 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