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?
> 

BTW,

> * Route-cache invalidation

I do intend to commit this, soon.  It fixes a bug that causes me a lot
of grief.

> * 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
compliant.

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. :-)

Dave

>         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
>         bug.
> 
>         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.
> 
> Dave
> 
> -- 
> David Young             OJC Technologies
> dyoung@ojctech.com      Urbana, IL * (217) 278-3933

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933