From owner-freebsd-current@FreeBSD.ORG Wed Mar 3 10:10:35 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 C84AB16A4CE; Wed, 3 Mar 2004 10:10:35 -0800 (PST) Received: from mx01.bos.ma.towardex.com (a65-124-16-8.svc.towardex.com [65.124.16.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3547D43D39; Wed, 3 Mar 2004 10:10:35 -0800 (PST) (envelope-from haesu@mx01.bos.ma.towardex.com) Received: by mx01.bos.ma.towardex.com (TowardEX ESMTP 3.0p11_DAKN, from userid 1001) id A55872F91A; Wed, 3 Mar 2004 13:10:34 -0500 (EST) Date: Wed, 3 Mar 2004 13:10:34 -0500 From: James To: Gleb Smirnoff , Wes Peters , Andre Oppermann , freebsd-net@freebsd.org, freebsd-current@freebsd.org Message-ID: <20040303181034.GA58284@scylla.towardex.com> References: <4043B6BA.B847F081@freebsd.org> <200403011507.52238.wes@softweyr.com> <20040302031625.GA4061@scylla.towardex.com> <20040302042957.GH3841@saboteur.dek.spc.org> <20040302082625.GE22985@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040302082625.GE22985@cell.sick.ru> User-Agent: Mutt/1.4.1i X-Mailman-Approved-At: Thu, 04 Mar 2004 04:48:27 -0800 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: Wed, 03 Mar 2004 18:10:36 -0000 hello - > Is there any plans about integration of BGP routing daemon (Zebra or Quagga) > into FreeBSD? With BGP routing daemon onboard, FreeBSD will be a strong > alternative against expensive commercial routers. I have successfull experience > of running FreeBSD STABLE with 2 full BGP views for half a year. before FreeBSD can be a 'strong alternative against expensive commercial routers', there are several things that must be done rewriting of routing stack and implementing FIB-like structure as what andre proposed in this thread is very welcoming. there are still other things freebsd lacks. such as uRPF that _SERVICE_PROVIDER_ can use. ipfw2 has verrevpath but all it does from what i know is strict uRPF only. service providers like myself, if we were to use freebsd boxen to run our network, i am not spending money on a router that doesn't do loose-check uRPF. this sounds like something linux does too but i refuse to use that :P implementation of policy routing similar to vrf's is something i wanted for a while as well. modern router deployments out in service provider core arena requires most people to start implementing "routing processes" using different routing instances. i.e. carrying mpls core routes in one routing instance, and carrying transit routes in the other to prevent core being affected by edge or outside routing failures, etc, etc > Modern i386 PC > can route/filter/shape much more traffic than expensive Cisco 36xx. I haven't > yet compared with 7000 series... comparing a modern x86 box running freebsd against a 3600 is a piece of cake. comparing a modern x86 box running freebsd against a 7000 is a piece of cake. comparing an x86 box running freebsd against a 7500 with old vip's and RSP1 or RSP2 is also piece of cake. there must be something seriously wrong if any of these junk old crisco routers that were supposed to be in dumpster since Jan 1st 2004, can beat modern freebsd box's performance. comparing a modern x86 box against a Cisco 7206VXR with NPE-G1 however is a good challenge :) > > Currently I'm working on my Netflow implementation, and I have faced the > following problem: I've already got global routing in my routing table, but it > lacks AS (Autonomous System) information. The routing daemon (zebra in my case) > already knows ASes, but this informations is lost when routing information is > injected into kernel. It'll be nice to add AS path to struct rtentry. > Seems like there is no problem with extending struct rtentry, but injecting > this info from userland requires changes to routing API. I see two ways of > implementing it: why inject as_path info from userland to kernel "fib"? may be netflow turning into an api that quagga can take advantage of to gather accounting information is more feasible? -- James Jun TowardEX Technologies, Inc. Technical Lead Network Design, Consulting, IT Outsourcing james@towardex.com Boston-based Colocation & Bandwidth Services cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net