Vyatta as a BRAS

Have anyone tried Vyatta router instead of a Cisco 7200 as BRAS for adsl
customers?

If so, what model? do you recommend it?

BR

Sharef

My comment would be that a software-based BRAS - 7200, Vyatta, et. al. - is no longer viable in today's Internet, and hasn't been for years, due to security/availability concerns. Same for peering/transit edge, customer aggregation edge, et. al.

I agree. In a bind I have seen small providers experiment with FreeBSD/Linux L2TP termination (as a LNS), I would recommend against it if you have a business that depends upon these customers' happiness. There were all sorts of issues to address when the customer ran significant traffic forwarding through the unix boxes, namely adjusting kernel parameters for NMB_CLUSTERS, heap sizes, all sorts of sysctl parameters, adding additional interface counts, etc. A low cost 7200 or ERX-310 would easily fit the bill, and you can buy them cheap these days.

Cheers,
Truman

My comment would be:
That is simply matter of opinion and opinions may be swayed depending on the market that signs your check? :slight_smile:

There have been a fair share of appliance bugs/sec vulnerabilities over the years as well.

I agree software-based deployments have their flaws but I do not agree that it cannot be managed securely with comparable or exceeding uptime -vs- a drop in appliance. I firmly believe it has it's place in 'today's internet'.

The question is where your expertise lies and what you expect to get out of it. If your background is Cisco and you have a good relationship then I wouldn't fix what isn't broken.

I have very little experience with Vyatta other than doing some mild testing. I am simply speaking more to the 'software-based' market like Vyatta/BSD.

When a single botted/misbehaving host easily can take down a software-based BRAS, that's a pretty strong indication that software-based edge devices are contraindicated, heh.

Software-based edge devices have been obsolete for a long time, now. They're a great risk to operators who've yet to replace them with hardware-based devices.

Cisco may be a lot of things, but low cost is not one of them.

I've been running Vyatta on a small 1U Supermicro Server (cost $600.00) for over one year. It handles all of our VPN traffic and is the main router for our fiber connection. Except for dropping a tunnel every now and then its been flawless. I've set up a cron job to monitor the VPN and restart any tunnel that might drop. No tunnel is ever down for more than a minute.

router:~# uptime
  11:01:52 up 377 days, 17:22, 1 user, load average: 0.00, 0.00, 0.00

--Curtis

They are all software based, no matter who builds them. Cisco IOS, Juniper JunOS, etc.

--Curtis

They are all software based, no matter who builds them. Cisco IOS,
Juniper JunOS, etc.

controlling hardware asic's and fpga's.

-g

Which are in essence software burned into chips. They can provide some acceleration, but will the next faster set of multicore CPUs and related chipsets be faster? This back-and-forth has happened repeatedly over the decades. Even in NIC cards, where there were early cards that offloaded processing from the main computer, but on the next newer main CPU, these "accelerated" cards were now the bottleneck and processing moved back to the host. So it is with routers, ASICs and the like.

You should buy a solution because it meets your needs. You should not care about the presence or absence of programmed logic vs. one or more CPUs. You should care about throughput capabilities, latency, packets per second, performance of filtering rules, etc. If the results can be obtained with off the shelf parts and at a fraction of the cost, why do you care whether it was built by someone with a big budget to spin ASICs, or by a company using software in fast, off-the-shelf hardware?

Many Cisco products do not have ASICs or FPGAs, but are quite capable as routers. I expect that's true of all the vendors.

That run low level software microcode and bitstreams. Sorry, it's software running those ASIC's and FPGA's, even at that level. Verilog and VHDL, while not your ordinary programming languages, blur the line very effectively.

In a PIX, its a Pentium 4. I've also been in other routers that use PowerPC. It depends on the manufacturer. Cisco uses its own custom processor when it gets to that level. Its why you have a choice of processor in the 7200's.

--Curtis

When a single botted/misbehaving host easily can take down a software-based BRAS, that's a pretty strong indication that software-based edge devices are contraindicated, heh.

I'm assuming you have data on that assertion, right? And can we compare that with a 'hardware' BRAS with a weak control plane CPU? Say, Cisco 7600 with Sup720 and badly configured COPP?

Software-based edge devices have been obsolete for a long time, now. They're a great risk to operators who've yet to replace them with hardware-based devices.

Let's run this rabbit.

Is there really a true hardware router or BRAS out there?

Or are we misusing the term 'hardware-based' to really mean 'hardware accelerated?' Further, is the data plane on hardware accelerated routers really truly hardware-based, or does the firmware, microcode, FPGA bitstreams, and other software do the heavy lifting? And isn't the control plane in a BRAS arguably more critical than the data plane, as it has lots of work to do that requires software running on a general purpose processor to do it? And aren't many 'hardware' routers weak on the control plane side of the house?

Which one can be refitted to do IPv6 the quickest, and in the most robust manner? And without requiring a budget-busting (and maybe even bankrupting) expenditure to swap out the whole works (or the majority of the works)? Which one requires the least capex when you yet again overflow your routing tables? Which one is the quickest to get patched when bugs are found?

>> My comment would be that a software-based BRAS - 7200, Vyatta, et.
>> al. - is no longer viable in today's Internet, and hasn't been for
>> years, due to security/availability concerns. Same for peering/
>> transit edge, customer aggregation edge, et. al.
>
> A low cost 7200 or ERX-310 would easily fit the bill, and you can
> buy them cheap these days.

...didn't he just finish saying "not 7200"?

Cisco may be a lot of things, but low cost is not one of them.

Agree...

I've been running Vyatta on a small 1U Supermicro Server (cost $600.00)
for over one year. It handles all of our VPN traffic and is the main
router for our fiber connection. Except for dropping a tunnel every now
and then its been flawless. I've set up a cron job to monitor the VPN
and restart any tunnel that might drop. No tunnel is ever down for more
than a minute.

This isn't a new issue. Quite frankly, software routers have some very
great strengths, and also some large weaknesses.

Advocates of hardware based solutions frequently gloss over their own
weaknesses.

Let's talk plainly here.

I'm not going to touch on things like Cisco's software-powered systems,
and for purposes of this discussion, let's take "hardware" to mean
"hardware-accelerated" solutions that implement forwarding in silicon.
That makes a fairly clear delineation between something like a Cisco
7600 and a Vyatta router. So.

Hardware router: Insanely great forwarding rates.
Software router: Varies substantially based on platform architecture and
  software competence. Generally speaking, a competent config can
  run 1Gbps ports without issue, but >=10Gbps gets dicey.

Cisco: Everyone learns Cisco's CLI.
Anything else: Everyone disses it because it's not Cisco. Even when it's
  very close to Cisco.

Hardware router: Usually a fixed lookup table size - have to have a gameplan
  to maintain routing table once you exceed it.
Software router: Virtually unlimited lookup table size.

Hardware router: Expensive custom hardware, good luck and hope you have
  a service contract in a crisis.
Software router: Varying cost hardware; for certain uses, an off-the-
  shelf server may do. The potential to be able to repurpose a
  gizmo in a crisis is a bonus.

Hardware router: Features are generally costly upgrades.
Software router: Might not have all the features you want, but typically
  most common features are readily available and reliable, usually
  at no cost.

Hardware router: Closed source software. Good luck if your vendor isn't
  patching your pet bug or security issue.
Software router: May be open source software. Inspect/audit for bugs,
  patch yourself. Might have to hire an expert though.

Hardware router: Low competence basic filtering at line rates.
Software router: High competence complex filtering, often at less than
  line rates.

Hardware router: May have moving parts. May not.
Software router: May have moving parts. May not.

It's interesting. One can get equally militant and say that hardware
based routers are irrelevant in many applications. I think it depends
on the application, and it's usually the specifics of the application
and the scale and features needed that's going to be more of a deciding
factor.

... JG

When BCPs are followed, they don't tend to fall over the moment someone hits them with a few kpps of packets - which should be a key criteria for an edge device.

The same can't be said of software-based devices.

If maintaining availability is important, then hardware-based (semantic hairsplitting aside) devices are a requirement.

Sorry, it's software running those ASIC's and FPGA's, even at that level

Sorry ..Its a clock that runs ASIC's and FPGA's
HDL is simply used to describe functionality before synthesis tools translate the design into real hardware (gates and wires)

And how many clockless CPU's have we seen so far?

I haven't done real world testing with Vyatta but we consistently pass 750KPPS+ without the slightest hiccup on our FreeBSD routing systems.

Correct hardware with the right configuration can make all of the difference.

750kpps packeting the box itself?

Also, note that kpps is a small amount of traffic, compared to what even very small botnets can dish out.

Joe Greco wrote:

This isn't a new issue. Quite frankly, software routers have some very
great strengths, and also some large weaknesses.

Advocates of hardware based solutions frequently gloss over their own
weaknesses.

Let's talk plainly here.

I'm not going to touch on things like Cisco's software-powered systems,
and for purposes of this discussion, let's take "hardware" to mean
"hardware-accelerated" solutions that implement forwarding in silicon.
That makes a fairly clear delineation between something like a Cisco
7600 and a Vyatta router. So.

Hardware router: Insanely great forwarding rates.
Software router: Varies substantially based on platform architecture and
  software competence. Generally speaking, a competent config can
  run 1Gbps ports without issue, but >=10Gbps gets dicey. ... [remaining good summary removed]
  
There's really three categories:
1) Devices which make all forwarding decisions and do the forwarding in software
2A) Devices which do forwarding in hardware, but which have a significantly limited forwarding table and punt to software for misses
2B) Devices which do forwarding in hardware, and which have hardware forwarding tables sufficient to hold your whole routing table

These then have the following attributes:
1) Can't handle traffic forwarding rates as high as the others, can do complex filtering, often least expensive choice, may scale well with commodity hardware scaling (processor, RAM, interface speeds). Great choice if you operate within their limitations and/or need their flexibility and potential processing complexity.
2A) Can handle higher forwarding rates, often can forward packets using less power-per-bps than systems in category 1, filtering at these rates is limited in capability, tends to scale with improvements in LAN switching technology (these are essentially layer 3 switches). Great in data centers, network edges. Dangerous in places where forwarding table exceeds hardware cache limits. (See Code Red worm stories)
2B) Can handle high forwarding rates, potentially lowest power-per-bps for forwarding if you are operating at sufficient scale, filtering at these rates is limited in capability, scales with investment in these highly specialized devices and the underlying TCAM technology. Great for Internet backbone network routing if you have the money. Expensive.

Matthew Kaufman

During the Code Red/Nimda period (2001), and on into the Slammer/Blaster/Nachi period (2003), all the routers I personally know of which were adversely affected were software-based, didn't make use of ASICs for forwarding.