Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 20 Sep 2007 00:04:06 -0400
From:      Steve Bertrand <iaccounts@ibctech.ca>
To:        Sten Daniel Soersdal <netslists@gmail.com>
Cc:        mattr@eagle.ca, freebsd-net@freebsd.org
Subject:   Re: Quagga as border router
Message-ID:  <46F1F136.3010203@ibctech.ca>
In-Reply-To: <46F1BDE1.8090102@gmail.com>
References:  <46F1AC0B.9040109@ibctech.ca> <46F1BDE1.8090102@gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46F1F136.3010203>