Date: Wed, 29 May 2002 20:31:24 +0200 From: Andre Oppermann <oppermann@pipeline.ch> To: Richard A Steenbergen <ras@e-gerbil.net> Cc: "Louis A. Mamakos" <louie@TransSys.COM>, Attila Nagy <bra@fsn.hu>, Luigi Iannone <Luigi.Iannone@lip6.fr>, freebsd-net@FreeBSD.ORG Subject: Re: MPLS Message-ID: <3CF51E7C.E9A47960@pipeline.ch> References: <Pine.NEB.4.44.0205290915060.28431-100000@tibre.lip6.fr> <Pine.LNX.4.44.0205291108080.7798-100000@scribble.fsn.hu> <3CF4A64A.EE220611@pipeline.ch> <200205291413.g4TEDLRG075458@whizzo.transsys.com> <3CF4E483.2510639@pipeline.ch> <200205291522.g4TFMdRG076033@whizzo.transsys.com> <3CF4FCFC.3D760508@pipeline.ch> <20020529180204.GK33611@overlord.e-gerbil.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Richard A Steenbergen wrote: > > On Wed, May 29, 2002 at 06:08:28PM +0200, Andre Oppermann wrote: > > > > It's clear to me that this is not based on the old 3.6 gated that is > > have in ports. The Nexthop stuff is more advanced. Zebra also is very > > reliable and I use it on many FreeBSD based routers here around. Agreed, > > each of these things don't push more than 50Mbit/s. > > Zebra is about as stable as a trailer park IRC whore who didn't take her > meds. It's fine for playing around, and maybe even for a small home PC > router where BGP is completely or nearly extraneous, but it is NOT a core > router's BGP implementation. :) I don't know how many moons ago you had your last look at Zebra/BGP but it's perfectly stable and supports a very large number of peers without any serious scalability problems. Zebra/BGP is running here on two machines with 225 days of uptime and five full feeds each. And I've got one with 53 peers and 92 days uptime (reboot for upgrade) among others. This stuff is simply limited by the forwarding engine under it (which is a FreeBSD based PC router). I agree that some IRGP in the Zebra suite are not as advanced. > > But that is basically a problem of the old BSD network stack / crappy > > kernel routing (forwarding) table. Expect some nice work in this area in > > the next few month. > > This has been on my todo list for a while, but I never have time. > > Basically just gut the current radix tree and fast-switch like route-cache > system, and replace it with something optimized for fast insertions and > deletions (and FIB building) but not longest prefix matching for the RIB, > and a 4 level 8-bit mtrie (seems to work best for PC hardware) for the > FIB. Hehe... We've come to the same conclusion for the FIB. First I tried to rip out the current flow-based fast-forward code with a highly compact LC-Trie build from the kernels PATRICIA trie. If only a nexthop changes, adjust it in the LC-Trie. If a prefix disappears, mark it as NULL. If Prefix changes, mark it as lookup- in-main-table (slow). Either after so many changes or so many slow lookups rebuild the LC-Trie. Unfortunatly this concept is impossible to implement because [if]_output expects a pointer to a routetable entry. This would mean I had to up the refcount on too many nodes in the main trie from outside of it (so the walker can't find it). This blew up the whole idea and we decided to do it the right way. Unfortunatly the whole routing stuff in BSD is so cross-pointered that untangling it is a medium task in front of it. It made have sense 15 years ago to have pointers from the INPCBs directly to the route node and the if-structures doing the same and vice versa, but today it's simply messy. -- Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CF51E7C.E9A47960>