DragonFly users List (threaded) for 2005-03
Re: DragonFlyBSD not in compliance with RFC 1122
Matthew Dillon wrote:
:The router in question is a Cisco and is dropping the packets from
:192.168.2.0/24 that arrive on 192.168.15.1 due to anti-spoofing rules. I
:was just hoping for an elegant solution. As I've mentioned I added a
:work-around with IPFW but I'm not pleased with it.
:I was quite surprised that FreeBSD doesn't support this even in 5.3. I
:would have thought that the Zebra problem alone would be reason enough
:to implement it. DragonFly is obviously affected too.
:(The Debian machines I administer would just require a "route add
:0.0.0.0 gw 192.168.2.1" to add the second default route.)
:It's a problem that has gone unresolved in FreeBSD for over 18 months so
:I guess it doesn't affect enough people to be a priority. I was just
:wondering if it was planned for the ongoing DragonFly routing overhaul.
Ah, I thought it would wind up being something like that.
This is actually a problem that has gone unresolved for over 10 years.
I've wanted to support multiple routes to a target forever.
The issue is that the route table module is a morass of unreadable code.
Jeffrey Hsu has been cleaning it up, and eventually I believe we will
be able to support multiple generic routes. If you happen to be a
programmer and want to take a shot at it (hint hint) the door is open!
This has been due to negligence on behalf of the BSD community.
Anyway, this is possible target, all we need to do is bring in
the RADIX_MPATH (multi-path routing) support from KAME, which
was done by Itojun. The other way to approach this problem is
to decouple ARP from routing entries, but this is a more long
winded approach... we could argue semantics all day. :-)
Multi-path routing is something that is required some protocols
like SCTP for fault tolerence.
I suggest we use the RADIX_MPATH work from KAME tree, and adapt
it to our new routing code; shouldn't be *that* difficult, IMO.
Hope that helps.