Re: Quagga as border router

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
_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Quagga as border router
    ... question I asked regarding the viability of an ISP using Quagga under ... already have my router config pretty well done, on a flash memory card, ... 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. ... Quagga could disconnect peers just simply because the initial route "flooding" took too much time. ...
    (freebsd-net)
  • Re: 2.6, 3.0, and truly independent intepreters
    ... have an additionalfieldthat would point back to their parent context ... one memory buffer to another memory buffer may be given two proxies as ... if a target context is idle you can enter it (acquiring its ... C and it's a simple object (no pointers). ...
    (comp.lang.python)
  • Re: [PATCH 1/7] async: Asynchronous function calls to speed up kernel boot
    ... be called within the caller's context. ... complex because the caller wants to do a more complex thing. ... BUT it does not solve the caller not getting memory, ... the scheduled function is not allowed to make the metadata ...
    (Linux-Kernel)
  • Re: Entropy
    ... but at the time the algo was rather slow. ... I have a big area of memory, showing the current symbol orders for every ... context, the index is output, and the symbol is moved to the front of the ... I don't want to take into consideration the space required for huffman ...
    (comp.compression)
  • Re: A reply to Marvin Minsky.
    ... It makes no sense either to talk about a hypothetical AI that behaves ... But in the context of AI, isn't it obvious where the typical functional ... or drop skin cells all over the floor. ... have similar visual and hearing discrimination, memory performance, operant ...
    (comp.ai.philosophy)