cvs commit: src/sys/conf files options src/sys/net radix.c
route.c route.h rtsock.c src/sys/netinet in_proto.c ip_output.c
src/sys/netinet6 in6_proto.c in6_src.c nd6_nbr.c
Bruce M. Simpson
bms at FreeBSD.org
Tue Apr 15 09:24:21 UTC 2008
First of all thanks for doing this. It would have been nice to have had
some advance warning though.
Qing Li wrote:
>> How does this behave with common routing daemons;
>> Quagga/Zebra, OpenBGPD, OpenOSPFD?
> Hmm... Good question, I haven't tried them but
> I will. Is this something you could help me
> with ?
I'm surprised XORP hasn't been mentioned here, so I'll mention it now...
For what it's worth this should not make any operational changes to
XORP's behaviour, it already plumbs routes to the FIB from its RIB with
the next-hop field, and always parses the next-hop in any PF_ROUTE
messages it sees. I can't speak for the others.
* So, does this RADIX_MPATH code originate from KAME?
* If so, to what extent does it share heritage with the OpenBSD code?
I looked at this stuff in some depth last year, with a view to
implementing new forwarding code. However without a source of ongoing
financial support it was difficult to make real progress with anything,
and other things came onto my plate at that stage.
It will be useful as a baseline for other work, in particular removing
the 32 (S,G) channel limitation from the multicast forwarding code --
with such a change it would be possible to move multicasting into the
usual radix trie lookup by adding a new flag which says "flood this to
all next-hops specified as AF_LINK sockaddrs".
We really need to get ARP out of there now. :-) It would be nice if
rt_mpath_matchgate() used the sa_dl_equal() macros from if.c, it reads a
The questions you raise about ownership of FIB entries bear some
scrutiny. Microsoft, for example, are pretty strict about only exposing
the forwarding table to consumers which are willing to play by all rules
of the API. What they have could be termed a RIB in of itself, you never
get to interact with the forwarding tables directly outside of the
TCPIP.SYS driver, except for read-only access e.g. SNMP. There is
locking capability in their API.
At the moment in the open source sphere what we have are mechanisms
which build on top of this in userland (e.g. the quagga approach), or
things which push these issues into a lower layer (such as the Linux
It really is worth looking at Linux, rtnetlink has an informational RFC,
it uses a tag-length-value protocol which addresses a number of the
issues blocking further progress in this area, and whilst we can't take
the code, the design, and the idea, are not subject to the GPL --
particularly so given the informational RFC status.
More information about the cvs-all