Multiple default routes / Force external routing

Julian Elischer julian at
Mon Apr 13 22:13:14 PDT 2009

sthaug at wrote:
>> I've poked about for weeks and asked similar questions in
>> -questions and elsewhere without avail. Probably using the wrong keys
>> to search and ask:
>> I have set up a box with various vlan interfaces on it. I naively
>> expected to be able to set individual "default" routes and route
>> between them via an *external* router (and filter packets there etc.)
>> but somehow all packets seem to "short-circuit" locally, and I don't
>> seem to be able to see why this is so and how I prevent that.

I think you are rather confused about what Multiple FIBs is..
All it is is teh  ability to make a packet use a particular
FIB on it's outgoing path. There is not such thing as an interface
being "In" a FIB. All interfaces are still visible to the routing code
by default, and The IP stack still knows about them.I think the IP
stack set's the 'loopback' flag on a packet regardless of the FIB
selected if teh dest is one of its own addresses.

What you want is VIMAGE.

> I found this behavior also, and it breaks POLA pretty badly.
> There are several problems with the multiple routing table support (via
> setfib) that I see:
> - I found I needed "options ROUTETABLES= ..." to have additional routing
> tables. I could not find this option documented anywhere.

in LINT where all such are documented.

> - The standard behavior when adding new routes (via ifconfig or route
> command) is that the route is added to all routing tables. Coming from
> a router/MPLS/L3VPN background, this is extremely counterintuitive. I
> found I needed to set the sysctl net.add_addr_allfibs to 0 to avoid
> this behavior.

the route is only added to all routing tables for NEIGHBOUR routes.
there is a sysctl to turn this off. By default all interfaces are
available no matter what FIB you are using

> - Having two routing tables (one default, one table number 1 via setfib)
> I also expected to be able to route between these via external router.

what do you mean by that. Routing tables are not a destination.
how can you 'ping' it? you cant route between tables. what does
that mean?

> Pinging from the default routing table to routing table 1, 

what are you talking about? It's a routing table not another machine
how can you ping it?

> traffic from
> the default routing table goes out to external router and in via other
> interface 
> (in routing table 1) 

??? routing tables are for OUTGOING packets.  incoming packets
don't use routing tables. If you want to assign a FIB to an incoming
packet for the purpose of controlling further routing, then there is a 
patch that will be applied to assign a FIB as the "default FIB for
packets received on an interface", but until that is applied
use ipfw or pf to apply it.

> - but the ping reply is returned via the
> loopback interface on the FreeBSD host, without going out to the router.
> I assume this is the "short-circuit" you're talking about, and I find
> this behavior also very counterintuitive.

I don't see what is so counterintuitive about it.. you sent the packet 
to your own machine.. all such packets are short circuited by the IP

> If I explicitly ping from routing table 1 with ping prefixed by setfib 1,
> everything works as expected (traffic both ways go via external router).

anyhow I hope to be able to address some of the issues you have 
raised. At least, to add more functionality.

> Steinar Haug, Nethelp consulting, sthaug at
> _______________________________________________
> freebsd-net at mailing list
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at"


This document and attachments contain information from Fusion-io, Inc. which is confidential and/or legally privileged. 
The information is intended only for the use of the individual or entity named on this transmission. 
If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or taking of any 
action in reliance on the contents of this emailed information is strictly prohibited, and that the documents should be returned to Fusion-io, Inc. immediately. 
In this regard, if you have received this email in error, please notify us by return email immediately.

More information about the freebsd-net mailing list