From owner-freebsd-net@FreeBSD.ORG Thu Sep 20 04:04:18 2007 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4508C16A41B for ; Thu, 20 Sep 2007 04:04:18 +0000 (UTC) (envelope-from iaccounts@ibctech.ca) Received: from pearl.ibctech.ca (pearl.ibctech.ca [208.70.104.210]) by mx1.freebsd.org (Postfix) with ESMTP id D349013C45D for ; Thu, 20 Sep 2007 04:04:17 +0000 (UTC) (envelope-from iaccounts@ibctech.ca) Received: (qmail 88492 invoked by uid 1002); 20 Sep 2007 04:04:16 -0000 Received: from iaccounts@ibctech.ca by pearl.ibctech.ca by uid 89 with qmail-scanner-1.22 (spamassassin: 2.64. Clear:RC:1(208.70.104.100):. Processed in 11.354236 secs); 20 Sep 2007 04:04:16 -0000 Received: from unknown (HELO ?192.168.30.110?) (steve@ibctech.ca@208.70.104.100) by pearl.ibctech.ca with (DHE-RSA-AES256-SHA encrypted) SMTP; 20 Sep 2007 04:04:05 -0000 Message-ID: <46F1F136.3010203@ibctech.ca> Date: Thu, 20 Sep 2007 00:04:06 -0400 From: Steve Bertrand User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Sten Daniel Soersdal References: <46F1AC0B.9040109@ibctech.ca> <46F1BDE1.8090102@gmail.com> In-Reply-To: <46F1BDE1.8090102@gmail.com> X-Enigmail-Version: 0.95.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: mattr@eagle.ca, freebsd-net@freebsd.org Subject: Re: Quagga as border router X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2007 04:04:18 -0000 I'm going to reply this first response in full context, and Cc my colleague so he can see this. Please reply-all as he is not subscribed, and remove anything not in context from here on out... >> Here is my scenario and minimum requirements: >> >> - two upstreams, BGP, accepting default-originate only, advertising my >> /21 v4 and /32 v6 >> - 8 Ethernet interfaces >> - two of said interfaces will be under the control of mpd4, >> multi-linking two ADSL connections >> - one will be connected to a 100Mbps fibre-to-Ethernet converter for a >> LANx connection >> - rest will be to a mix of 100Mb and 1000Mb switches, and behind those: >> >> -- ~50 SDSL 1Mbps clients >> -- ~6 Port Master 3's, 48 56K modems per >> -- a few very heavily utilized DNS servers >> -- about 300 websites across about 10 servers >> -- a handful of co-lo boxes >> -- an email infrastructure that realizes ~1 million emails per day >> -- other things I've forgotten >> >> What I'd like to know beyond learning (from this list) that anything >> more than a dual-core is futile, what hardware should I be looking at? I >> already have my router config pretty well done, on a flash memory card, >> so in particular: >> >> - is 64 bit CPU advantageous for anything more than the 4GB memory limit > > I am no authority on this but I'd like to theorize (maybe someone will > enlighten me afterwards); > It could be beneficial for v6 processing but then i think you might be > hurt more from pushing/popping "twice" as much data on the stack the on > a context switch. You will be doing a lot of those, unless you use polling. Can you please explain in a technical way how polling can benefit me here in a dual-stacked situation? In all honesty, the last few months, I've been seeing many mails to the lists saying 'polling' has caused issues. (I'm not arguing, I'm just looking for reason ;) >> - is there a benefit to having more than 2GB of memory, and if so, what >> are said benefits > > Not unless you want to pull in the entire world through those bgp peers, > but since you use default-originate only, this shouldn't be a problem. I am only planning on receiving default-only. However, AFAIK, a substantial enough Cisco router can house the entire v4 route table via BGP with 1GB of memory. I would like to ensure that this worse-case-scenario is possible with this FBSD box, even though it's not on the table...yet. > But that could imply that you are going to do attempt active load > balancing on those two peer links. If so, you should be aware that such > load balancing must be done manually by some other method (pf? ng?) No plan on load balancing. It's all based on 100% failover. Thank you for the input, so if I ever do need to do load balancing, it has been already planned in a manual configuration as you stated, however via BGP. I'll break up my aggregate as an absolute LAST resort. (Essentially, in regards to v4, I will NOT advertise anything smaller than my allocated block...period). >> - is there a specific motherboard that I should look at > > One with the least amount of IRQ's that need to be shared with your > ethernets. I'm not a hardware person. I'd rather have a name brand and model as opposed to those terms ;) (sorry). > You might want to consider AMD cpu's with enormous caches and low memory > latency (but also sometimes lower bandwidth). There will be a lot of > tiny packets that go in and out of memory, not large chunks. One could > say you would benefit more from a speedy sportster than a U-Haul truck. > The large caches would benefit you on all those context switches. Thank you... >> - is there specific NIC's I should look at (of course, dual or quad >> 1Gbps, but what brand/model) > Intel! > Intel? > oh yeah, Intel. LOL. My partner will recognize this statement :) >> Essentially, I'd like a board with at *least* 6 PCI-X slots, and perhaps >> 8 RAM slots (if I can find justification that my router will work better >> with up to 16GB of memory). > > I can't think of a reason why it would go faster with 16GB of memory. > Memory for packets live in kernel space. Usable kernel address space > isn't big as it has to be shared with application address space. Ok. >> On the software side, many people suggested OpenBGP to me as opposed to >> Quagga, but I really didn't hear any 'technical' reason as to the >> recommendation, so I'm *very* interested to hear of any benchmarks or >> personal experience from anyone who has switched from one to the other. > > I haven't had the pleasure of using OpenBGPD much as it was not > available when i used Quagga. Quagga has several architectural issues > involving importing lots of routes. Way back then, Quagga could > disconnect peers just simply because the initial route "flooding" took > too much time. Peer communication (keep alives) and route > importing/structure updates were not separate threads. > Also Quagga used up a lot more memory for it's structures for no gain. > These things might have changed. > But OpenBGPD doesn't look like an alternative for you, if you are using > ipv6 as it only supports ipv4 route distribution (according to man pages) IPv6 is an absolute MANDATORY requirement. If a recommendation does not support IPv6, than it will NOT fit into my environment. Thank you for your detailed response! Steve