Date: Mon, 13 Apr 2009 21:55:49 -0700 From: Julian Elischer <julian@elischer.org> To: sthaug@nethelp.no Cc: freebsd-net@freebsd.org, pcc@gmx.net Subject: Re: Multiple default routes / Force external routing Message-ID: <49E41755.8050701@elischer.org> In-Reply-To: <20090413.220932.74699777.sthaug@nethelp.no> References: <20090413135402.78610@gmx.net> <20090413.220932.74699777.sthaug@nethelp.no>
next in thread | previous in thread | raw e-mail | index | archive | help
sthaug@nethelp.no 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 stack. > > 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@nethelp.no > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" CONFIDENTIAL 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49E41755.8050701>