From owner-freebsd-current@FreeBSD.ORG Tue Mar 2 06:11:55 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8EDAA16A4CF for ; Tue, 2 Mar 2004 06:11:55 -0800 (PST) Received: from mailtoaster1.pipeline.ch (mailtoaster1.pipeline.ch [62.48.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAF7443D3F for ; Tue, 2 Mar 2004 06:11:54 -0800 (PST) (envelope-from andre@freebsd.org) Received: (qmail 40977 invoked from network); 2 Mar 2004 14:11:54 -0000 Received: from unknown (HELO freebsd.org) ([62.48.0.53]) (envelope-sender ) by mailtoaster1.pipeline.ch (qmail-ldap-1.03) with SMTP for ; 2 Mar 2004 14:11:54 -0000 Message-ID: <4044962A.7F6ECE9A@freebsd.org> Date: Tue, 02 Mar 2004 15:11:54 +0100 From: Andre Oppermann X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: James References: <4043B6BA.B847F081@freebsd.org> <200403011507.52238.wes@softweyr.com> <20040302031625.GA4061@scylla.towardex.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: Wes Peters cc: freebsd-current@freebsd.org cc: freebsd-net@freebsd.org Subject: Re: My planned work on networking stack X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2004 14:11:55 -0000 James wrote: > > > > [] move IPv4 routing to its own optimized routing table structure and > > finally it's about time :) > > > > add multi-path and policy-routing options. (planned) > > would the policy-routing optioned table sort of similar to VRF's or > different routing instances that could potentially be tied to userlands > like Quagga? Policy-routing in this context means to have multiple forwarding tables which are being selected based on something else than the destination address. Normally that is the source address or source/incoming interface. Optionally it can be anything one of our firewall systems can match on and then tag the packet. The routing tables for source and destination address matches are opaque or non-opaque. That means you can have a table with exceptions and if an address doesn't match there it will fall through onto the next or default table. Or, if it's a opaque table, it will result in an unreach message. Etc. It's not VRF as such but can be set up to work like it. The userland routing daemons have the option to specify the table they want to modify. This requires certain changes to the routing daemons and a redesign of the routing message format (but not the routing socket). -- Andre