Subject: Re: works in progress: route cache invalidation, RADIX_MPATH
To: None <tech-net@NetBSD.org>
From: David Young <firstname.lastname@example.org>
Date: 11/16/2006 16:18:18
On Thu, Nov 16, 2006 at 01:33:30PM -0600, David Young wrote:
> Patches for two networking features I have in progress are at
> <ftp://cuw.ojctech.com/cuw/netbsd-70b158cb/net-wip.patch>. The first
> feature is route-cache invalidation. The second feature is RADIX_MPATH,
> the multipath routing patches from KAME, with many of my own improvements.
> Sorry the patches for both features are intermingled---anybody know a
> good patch editor?
> * Route-cache invalidation
I do intend to commit this, soon. It fixes a bug that causes me a lot
> * RADIX_MPATH
I don't know when I will get around to debugging and committing this.
Not very soon, I'm afraid.
RADIX_MPATH fixes a bug, albeit not a very popular one: IIRC, the
Host Requirements Spec requires that the routing table can hold more
than one default route, and NetBSD's will not. So we are not strictly
RADIX_MPATH also makes it a lot easier for someone to bootstrap an
experiment in wireless routing. Wireless routing is a hot topic these
days. NetBSD is too often overlooked as a platform for that.
I believe RADIX_MPATH will help us do things like operate in the IPv4
link-local subnet (169.254/16) on more than one ethernet, without bridging
all of the ethernets together. (Yes, I really do think that's useful. :-)
> The second feature is the RADIX_MPATH patches from KAME, with
> significant modifications by me. RADIX_MPATH implements multipath
> routing according to "Modulo-N Hash," described in RFC2991.
> Beware: I have not run compiled or run my RADIX_MPATH patches
> in a long time. I know there are bugs that cause crashes.
> My mods make RADIX_MPATH work sensibly in the event that you
> can reach the same destination both directly (i.e., it's on the
> same link), and through an IP router---this is not the least
> bit unusual on a wireless multihop network.
> I encapsulate each route's preferability in a macro,
> RADIX_MPATH_PREFERENCE(). Routes with greater preference
> numbers are chosen with greater likelihood. Right now,
> RADIX_MPATH_PREFERENCE() always evaluates to 1.
> I also add a "wireless heuristic" to the code that selects
> nexthops: if a destination is on the same link, but there is
> a route through an IP router, the heuristic chooses the latter
> route. The assumption is that a routing daemon has added the
> longer path, knowing full well what it is doing! :-) This is
> a pretty reasonable assumption in practice, but we need the
> capability to turn the heuristic on and off.
> * Et cetera
> I retired a workaround in gif(4) for the old route-caching
> I removed gre(4)'s ability to configure the same remote inner
> IP as remote outer IP, per prior discussions on tech-net.
> I made many cosmetic changes throughout the networking stacks.
> David Young OJC Technologies
> email@example.com Urbana, IL * (217) 278-3933
David Young OJC Technologies
firstname.lastname@example.org Urbana, IL * (217) 278-3933