DragonFly BSD
DragonFly kernel List (threaded) for 2003-10
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Any interest in updating the routing engine?


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Tue, 7 Oct 2003 20:19:01 -0700 (PDT)

:...
:*bsd routing engine.  The CEF table is built by route lookups
:against the master table whenever a new flow hits the router.  The
:route is then 'cached' in the CEF table and stays until the flow
:stops, or the route is invalidated by an external means, be it link
:status or routing updates from an external/internal routing protocol
:like OSPF.
:
:Essentially, Cisco's have a concept of more than one route for a
:given destination.  I'd like to pull that logic into *bsd.
:
:----- Be warned, ugly paste from notes --------------
:
:The routing table should be expanded to include the following
:tables:
:...
:

    Good god, how long have you been day dreaming about this?

    Generally speaking I like the concept of a two-stage route table.  I
    have a few comments.  First, I think interface aliases would have to be
    treated the same as the primary interface address (that is, entered into
    the route table automatically simply by existing).

    Second, I like the concept of a two-layer route table with lookups based
    on both the souce and target IP's (and associated masks).  I am presuming
    that the primary layer would contain the multi-homed routes and the
    secondary layer would 'lock in' the selected interface for a flow, like a
    TCP connection, on a temporary basis.  

    Third, I think that if we were to do this sort of thing we really would
    want to completely rewrite the BSD route table radix tree code.  The
    existing code is a huge mess and does not suit an MP environment all that
    well.  And it would have to be done in the kernel or as a kernel module,
    though perhaps development could be done in userland using message-passing
    (to make it easier to develop, with a manual scan of interface IP/MASK's
    if the route table is otherwise not available as an emergency fallback).

    I haven't gone over your notes with a fine toothed comb but your ideas
    sound quite interesting.  

						-Matt




[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]