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
> > eth0 picks up on
> > kernel checks the route table
> > kernel discovers collision with on eth1
> > kernel adds 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 on eth1?

kernel discovers collision with on eth0
kernel removes route 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 (eth1) to 10.X goes out on
> eth0 and things just works with the only restriction that clients
> on eth1 ( should talk to and clients on eth0
> ( should talk to

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.


To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at