On 13/07/2010, at 4:50 PM, Dobbins, Roland wrote:

On Jul 13, 2010, at 1:34 PM, Sharef Mustafa wrote:

...

do you recommend it?

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.

----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com>

Injustice is relatively easy to bear; what stings is justice.

-- H.L. Mencken

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

On Jul 13, 2010, at 3:00 PM, <khatfield@socllc.net> wrote:

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'.

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. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken

...

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

controlling hardware asic's and fpga's. -g

On Tuesday, July 13, 2010 11:11:57 am Greg Whynott wrote:

...

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

controlling hardware asic's and fpga's.

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.

On Tue, 13 Jul 2010 23:31:25 +0700, Christian Chapman said:

...

...

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

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

On Tue, 13 Jul 2010, Lamar Owen wrote:

Instruction issue? Execution unit? Special instructions? Sounds like a software-driven processor to me. Specialized software instruction set, yes. True hardware forwarding, no software involvement? No. More like asymmetrical multiprocessing software routing. Call it hardware accelerated if you like; PXF is to networking as a nVidia GeForce GPU is to graphics.

This is true on a lot of newer Cisco high end platforms. CRS-1 uses multicore processors (hundreds of cores) for forwarding on their linecards, and they achieve 40+ Mpps per linecard. This is the trend in networking where you need to do intelligent things, it's easier to do multicore parallell processing than doing hugely fast FPGA forwarding (at least it seems that way, and it's faster to upgrade the software on a CPU than on a FPGA). The lines are blurring between CPU/FPA/ASIC (well, ASIC is really a misnomer as it's just "application specific" which means packaging, not function) and since people want flexibility, general CPUs used for forwarding is the way it's headed, even though the CPUs right now have little to do with the CPUs we see in "normal" PCs. -- Mikael Abrahamsson email: swmike@swm.pp.se

On 7/13/2010 11:11 AM, Greg Whynott wrote:

...

...

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

controlling hardware asic's and fpga's.

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

Hi folks, On Jul 13, 2010, at 12:05 PM, Nick Hilliard wrote:

I think Roland's point was that on "hardware routers", there is a separation of function between the control and the forwarding planes, and that the forwarding plane is designed to be able to transmit data in an efficient parallel manner. I.e. on a well-designed hardware router, if you trash the data path on the router through ingress A and egress B, the damage stops there: the control plane is unaffected and ingress C to egress D is also ok (for arbitrary values of C and D).

The key point here is one of design, not one of implementation technology. If you need a router that is robust against DoS attacks, then that's what you should buy. Such routers can be built from ASICs, CPUs, or even 7400 series TTL, if you work hard enough at it. There is no meaningful distinction of 'hardware' or 'software'. All of the ASIC based systems embody processors of various flavors in the ASICs that are running forwarding software. And the difference between an ASIC and a CPU is not as much as you might think. Ok, ASICs typically don't go to full custom layout (tho some crazy people have done that) and are typically a few steps behind on the process technology curve. But this is not the fundamental issue. The whole point about being DoS resistant is one of horsepower. To do DoS protection correctly, you need to be able to do packet examination at line rate. When there are packets destined for the router, they need to be classified appropriately, queued carefully and those queues need to be serviced in The Right Way (tm). If your system has the performance to do this in addition to the normal transit load on the system, then it's in pretty good shape. Regards, Tony

On 14/07/10 02:18 +0000, Dobbins, Roland wrote:

On Jul 14, 2010, at 3:26 AM, Tony Li wrote:

...

The whole point about being DoS resistant is one of horsepower. To do DoS protection correctly, you need to be able to do packet examination at line rate.

Right. And to date, such routers make use of ASICs - i.e., 'hardware-based' routers, in the vernacular.

Routers which use only centralized, general-purpose processors can't handle even a fraction of 'line-rate' without tanking, as innumerable real-world examples of said behavior over the years have repeatedly and conclusively demonstrated.

I'm not really all that opinionated on the subject, other than to say that the definition of a router, and what qualifies as a sufficient router for any given administrator's needs, greatly varies. However, to state something like

as innumerable real-world examples of said behavior over the years have repeatedly and conclusively demonstrated.

has the appearance of you struggling to hold on to an idea that may have been more true in the past, and less true today, as is evident based on the input from other list participants. -- Dan White

On Wed, 14 Jul 2010 02:18:18 -0000, "Dobbins, Roland" said:

Right. And to date, such routers make use of ASICs - i.e., 'hardware-based' routers, in the vernacular.

Routers which use only centralized, general-purpose processors can't handle even a fraction of 'line-rate' without tanking

But as others have stated, the 7206 has at least some hardware acceleration, so it's *not* a router that uses *only* centralized general-purpose CPUs. So at least some hardware-assisted routers tank under loads too. And even the most heavily hardware-assisted systems have to do call outs from the FPGA's for *some* stuff, and can be tanked by suitably creative abuse of their weaknesses. Of course, in general the more hardware assist, the harder it is to tank (but it's never impossible). So basically, your definition of "hardware based" router is "one that has enough FPGAs to not tank under some arbitrary workload". Not very useful,that. Let's face it Roland - it's a continuum from hardware to software, and in many places it's downright murky which it is. Is the CRS-1 hardware or software? Lots of custom hardware in there - but lots of processing cores that look suspiciously like software engines too.

On Wednesday, July 14, 2010 08:39:50 am Dobbins, Roland wrote:

And it's not *my* definition - 'hardware-based' vs. 'software-based' are the terms to describe these two fundamental architectural classes of router *within Cisco itself*.

[snip]

There's a world of difference in packet-handling mechanisms and sheer performance between a 7200 and a CRS-1, or a GSR, or a CRS-3, or Juniper T-series - and not just one of 'more, faster processors', but of fundamental architecture.

CEF is CEF is CEF, whether done on a 2600 or a 7200 or a GSR. Now, don't get me wrong; the engineers who make massively parallel forwarding engines are creative and smart folks, and have come up with very elegant methods of moving the bits ever faster, but the fundamental forwarding architectures, even of these accelerated boxes, can be implemented in pure software, as evidenced by the Cisco Nexus 1000V.

This is why 'hardware-based' vs. 'software-based' is a useful distinction; again, note that within Cisco, these are the common terms used to describe these general classes of device, with 7200s and ISRs being termed 'software-based', and the other models mentioned above described as 'hardware-based'.

Marketingspeak doesn't necessarily reflect reality. The original draft of one of my replies in this thread said this 'Let's run this rabbit, and dispel some marketing hype while we're at it.' The reality is that 'hardware-based' routers really are AMP (asymmetrical multiprocessing) software-based routers, with specialized processors running specialized software. And when implemented properly they are very good at what they do; I have GSR's, they work great, and regardless of what engine is on the linecard some software at some level running on some processor is making the forwarding decisions at the data plane, and they can even for certain things require a punt to the MIPS processor on the linecard (IPv6 on Engine 1, anyone?). Knowing the technology and its architecture, without blindly buying into marketingspeak, helps operators make better procurement decisions. And Cisco's website has most of the information you need to make that decision, if you use their hardware, which is very good. Dig deeply enough, and past the hardware versus software pseudodichotomy, and you can make very informed decisions indeed. As a tongue in cheek example, remember the 'switching router' versus 'routing switch' distinction? If a specialized network processing engine in an AMP router can protect the control plane CPU, then code running on different processors in an SMP system could do the same. Perhaps not as efficiently, but the end result can be the same. I mean, I wonder if Blue Gene or Jaguar could give a CRS series a run for its money in terms of routing power (especially on the control plane), and what the price/performance ratio would be to throwing something like Jaguar (224K Opteron processors, running Linux) at the relatively mundane task of throwing precisely metered bits around the wires. :-) Regardless of recommendations, people are using commodity server-grade SMP hardware to run commodity OS's to get the job done, and given the people who have chimed in here, apparently are doing it without lots of problems. The increase on this and other lists of questions about Mikrotik, Vyatta, and other nontraditional routing platforms is an interesting throwback to the days of Proteon routers, the original SUN, and Cisco's multibus roots, and it shows that people are deploying these newer and much faster boxen in the real world, bugs and all. It's not a 'software-based = bad; hardware-based = good' world, even at the edge anymore; a few years ago, sure, I wouldn't dream of doing such a thing. I for one love what a good parallel state machine in an FPGA can do to your software's performance (we're doing that here, doing interferometric correlation at 96Gb/s on a relatively inexpensive FPGA platform based on IBOB); or what GPU acceleration can do to graphics performance, but it is a help to realize that those activities, accelerated though they may be, are still software-based. And while it's not a BRAS, one of the most exciting products I've seen in a long while from Cisco is the above-mentioned Nexus 1000V. Pure software virtual switching for VMware.

On Jul 15, 2010, at 1:49 AM, Lamar Owen wrote:

CEF is CEF is CEF, whether done on a 2600 or a 7200 or a GSR. Now, don't get me wrong; the engineers who make massively parallel forwarding engines are creative and smart folks, and have come up with very elegant methods of moving the bits ever faster, but the fundamental forwarding architectures, even of these accelerated boxes, can be implemented in pure software, as evidenced by the Cisco Nexus 1000V.

This is a *vast* oversimplification of the 'life of a packet' in a box like a CRS-1 vs. a 7200, for example. You know this, of course.

Marketingspeak doesn't necessarily reflect reality. The original draft of one of my replies in this thread said this 'Let's run this rabbit, and dispel some marketing hype while we're at it.'

I wasn't a marketing person during my time at Cisco, and I'm not a marketing person now. Technical people within Cisco and outside Cisco routinely make use of the terms 'hardware-based' and 'software-based' to describe these fundamental classes of routers, and have for years.

The reality is that 'hardware-based' routers really are AMP (asymmetrical multiprocessing) software-based routers, with specialized processors running specialized software.

Right - the 'hardware-based routers' idiom comes from the 'specialized processors', known as NPUs, ASICs, TCAMs, and so forth.

And when implemented properly they are very good at what they do; I have GSR's, they work great, and regardless of what engine is on the linecard some software at some level running on some processor is making the forwarding decisions at the data plane,

'Some processor' = ASIC or NPU = 'hardware-baed'.

and they can even for certain things require a punt to the MIPS processor on the linecard (IPv6 on Engine 1, anyone?).

Yes, this is true - or even to the system RP.

Knowing the technology and its architecture, without blindly buying into marketingspeak, helps operators make better procurement decisions.

Nobody in this conversation so far is 'blindly buying into marketingspeak', to my knowledge - certainly not me.

And Cisco's website has most of the information you need to make that decision, if you use their hardware, which is very good.

The content on Cisco's Web site is confusing, redundant, full of *actual* marketing-speak, and highly confusing in many aspects. This isn't a problem unique to Cisco, mind, but afflicts almost all technology companies.

Dig deeply enough, and past the hardware versus software pseudodichotomy, and you can make very informed decisions indeed.

Yes, but you aren't going to do that by looking at product marketing materials on a Web site.

As a tongue in cheek example, remember the 'switching router' versus 'routing switch' distinction?

Yes, which was nonsense. OTOH, 'hardware-based' vs. 'software-based' is a useful distinction commonly employed by technical, non-marketing people within both the vendor and operational communities alike.

If a specialized network processing engine in an AMP router can protect the control plane CPU, then code running on different processors in an SMP system could do the same.

Not on a general-purpose SMP system running commodity processors such as those found in PCs.

Perhaps not as efficiently, but the end result can be the same. I mean, I wonder if Blue Gene or Jaguar could give a CRS series a run for its money in terms of routing power (especially on the control plane),

Possibly - certainly not on the forwarding plane.

and what the price/performance ratio would be to throwing something like Jaguar (224K Opteron processors, running Linux) at the relatively mundane task of throwing precisely metered bits around the wires. :-)

Fruitless speculation, IMHO.

Regardless of recommendations, people are using commodity server-grade SMP hardware to run commodity OS's to get the job done, and given the people who have chimed in here, apparently are doing it without lots of problems.

My experience is that folks doing this on the edges of their networks eventually end up regretting it, after they get zorched a time or two.

The increase on this and other lists of questions about Mikrotik, Vyatta, and other nontraditional routing platforms is an interesting throwback to the days of Proteon routers, the original SUN, and Cisco's multibus roots, and it shows that people are deploying these newer and much faster boxen in the real world, bugs and all.

It shows me that a lot of folks, because they haven't been in the industry very long and/or don't learn from the mistakes of others in the past, seem determined to repeat those same mistakes, ad nauseam, ad infinitum.

It's not a 'software-based = bad; hardware-based = good' world, even at the edge anymore;

I very strongly disagree with this, based upon my hands-on operational experience in production networks. Running software-based platforms at the edges of one's network is extraordinarily irresponsible, in operational terms, if availability is an important metric for said network.

a few years ago, sure, I wouldn't dream of doing such a thing. I for one love what a good parallel state machine in an FPGA can do to your software's performance (we're doing that here, doing interferometric correlation at 96Gb/s on a relatively inexpensive FPGA platform based on IBOB); or what GPU acceleration can do to graphics performance, but it is a help to realize that those activities, accelerated though they may be, are still software-based.

Again, with the semantics. If you take this hairsplitting to its logical extension, there's no such thing as 'hardware', because it's all 'software' - just some of it is 'hardware' which happens to be instantiated in the form of physical chipsets. While this may be intellectually appealing to some folks at the hand-waving, 30,000-foot, pseudo-philosophical level, as a matter of practical reality in the real world on real networks using real boxes, the distinction has a great deal of import.

And while it's not a BRAS, one of the most exciting products I've seen in a long while from Cisco is the above-mentioned Nexus 1000V. Pure software virtual switching for VMware.

The N1KV is interesting primarily because it's Cisco's first retail pure-software - i.e., not tied to a box - product intended to move packets around. It also highlights the flexibility and portability of NX-OS, which is Cisco's best OS to date, IMHO. At the same time, from a performance perspective, it leaves a lot to be desired. I hardly like to think what will happen when a few dozen VMs sending their traffic through an N1KV get botted and start spewing out SYN-floods and so forth. We all know there's a great deal of difference between a box like a CRS-1 and a box like a 7200, and/or an Intel box running Quagga or what-have-you, and it's absurd to pretend otherwise. Bottom line - use a software-based box for a layer-3 edge application like a BRAS, and you're asking for trouble. And this time, I'm really done with this thread, as semantic arguments quickly grow tiresome. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken

On Tuesday, July 13, 2010 04:53:55 am Dobbins, Roland wrote:

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 -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.

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. -----Original Message----- From: "Dobbins, Roland" <rdobbins@arbor.net> Date: Tue, 13 Jul 2010 16:15:18 To: NANOG list<nanog@nanog.org> Subject: Re: Vyatta as a BRAS On Jul 13, 2010, at 10:58 PM, Joe Greco wrote:

It's interesting. One can get equally militant and say that hardware based routers are irrelevant in many applications.

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. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken

On 7/13/10 10:56 AM, Dobbins, Roland wrote:

On Jul 14, 2010, at 12:39 AM, <khatfield@socllc.net> <khatfield@socllc.net> wrote:

...

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

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.

I work for Vyatta. We regularly see 700+kpps per core using a Nehalem class cpu with higher rates possible in tuned systems. On a multi-core system this translates to a fairly high level of throughput. To echo an earlier post, Linux can comfortably handle gigabit. It wasn't too long ago that this wasn't the case. The growth in the number of cores available to the end user, the introduction of multi-queue nics, the move away from the FSB architecture towards QPI, ever faster PCIe... The technology is directionally trending towards faster, more consistent network throughputs whether your Linux host is acting as a router, firewall, web server, or whatever. There are activities taking place on the software front as well to increase speed and consistency in the realms of forwarding and firewall, including technologies that separate the control and forwarding planes. There is still headroom available in commodity compute to scale further. I will be the first to admit that Vyatta won't work for everyone. We still have a lot of work to do for our system to fit seamlessly in some environments. But, the bet that we have made is that commodity compute coupled with the amazing OSS dev community can keep pace with a good portion of the networking worlds needs. So far, that bet looks like a good one. To discount all software routing running on general purpose processors as being antiquated seems to me to be premature, especially given the various vendors interests as more functionality migrates into the cloud. As that happens commodity components in the cloud fabric will necessarily need to behave more like network appliances. Cheers, Robert.

On Jul 13, 2010, at 10:58 PM, Joe Greco wrote:

...

It's interesting. One can get equally militant and say that hardware bas= ed routers are irrelevant in many applications.=20

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

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

That's just a completely ignorant statement to make. I notice in particular how carefully you qualify that with "[w]hen BCPs are followed"; the fact that hardware router manufacturers have declared everything and anything that derails their bullet trains as "not a BCP" is a perfect example of this deceptive sort of misinformation. There are plenty of FreeBSD based devices out there that are passing tons of traffic; almost any of them are more competent than any Cisco router I'm aware of when hitting them directly with traffic, since the CPU's on your average Cisco are pretty flimsy, the CPU on a FreeBSD box is going to be fairly current tech, and the code on a FreeBSD box is going to have been designed to defend against such attacks because things like IRC server operators often don't have the luxury of hiding their device management on a protected net. The fact of the matter is that the way that most "hardware" platforms try to survive a DoS attack against their control plane is through hardware filtering; to the extent that that works, it's going to be pretty effective. However, if we're going to allow for that, then we have to allow the software platform to defend itself with a firewall as well, and once you do that, on both platforms, what actually happens in the end is that both devices can successfully defend at gigabit speeds, but you start losing traffic because you're filling the inbound pipe. Or, put another way: "When BCP's are followed, software devices don't tend to fall over the moment someone hits them with a few Mpps of packets either." ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.

On Jul 14, 2010, at 5:45 AM, Joe Greco wrote:

...

That's just a completely ignorant statement to make.

It's based on a great deal of real-world experience; I'm sorry you consider= that to be 'ignorant'.

You're speaking to someone who has extensive experience with "software" based routers, and you're failing to acknowledge the upsides of such an architecture, when I've already conceded the upsides of a hardware architecture.

...

I notice in particular how carefully you qualify that with "[w]hen BCPs = are=20 followed"; the fact that hardware router manufacturers have declared everything and anything that derails their bullet trains as "not a BCP" is a perfect example of this deceptive sort of misinformation.

Anti-spoofing, iACLs, CoPP (or its equivalent on non-Cisco platforms), et. = al. aren't 'misinformation'. They're useful, proven techniques/features wh= ich any operator ought to implement.

The things that any given use scenario ought to implement are highly dependent on the actual application.

...

There are plenty of FreeBSD based devices out there that are passing tons of traffic; almost any of them are more competent than any Cisco router I'm aware of when hitting them directly with traffic

Then your experience of Cisco routers (and/or those from other vendors) mus= t be limited to the lower-end platforms; I can assure you that faster Cisco= boxes such as ASRs, GSRs, CRSes, and so forth are in another league entire= ly, and can handle mpps of to-us traffic, when properly configured. Softwa= re-based routers simply can't do that; it's not an indictment of them, it's= just that they aren't suited to purpose, just as station wagons generally = aren't to be found in the Indy 500.

So your solution is to keep throwing heavier hardware at the problem until it works. Okay, I see that. Now, let me quote from a different message:

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

The truth is that you can keep throwing CPU at a problem as well. I can size a software based router such that it can remain available. This is neither new nor exciting technology. Luigi Rizzo was doing extensive work on this about a decade ago: he took an Athlon 750 platform with 4 100Mbit ethernet interfaces in it (Athlon 750 = 1999 tech) and was able to exceed 100Mbps levels without a problem. The UNIX based platforms have extensive capabilities to defend against attack, even without a firewall. As with a hardware based platform, there are both good things and bad things you can do that will impact availability. Software based platforms have an incredible edge in areas that hardware based platforms don't, including capex and the ability to find replacement parts after a disaster. I spent some time after the Haiti quake getting FreeBSD-based routers up and running, a task made easier because it's a lot easier to find a working PC and scavenge some network cards than it is to find a working Cisco router in a city where all inbound and outbound transportation is paralyzed. You can continue to defend your position, of course, but it's just looking a bit silly. A wise engineer knows that there are several ways to tackle any task, and "one tool for every job" is not a sound policy. If you'd like to revise your position to "Cisco and Juniper software based solutions are underpowered PoS", that's probably a defensible position, and you won't get any argument from me. Please don't generalize such a position into all software based devices, though. Overall, there are a lot more software based routers out there than hardware based devices. Your cablemodem, your ADSL modem, your wifi access point, all these are probably software based devices. Some of them will melt under a too-great load. Some won't. This is a function of many different factors. There is nothing inherent in a software-based device that's going to make it fail under load - just as there's nothing inherent in a hardware-based device that's going to make it succeed (which is why you have to qualify your defense of these with "must follow BCP"). It's the related engineering that ultimately determines whether or not it all works out. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.

On Jul 14, 2010, at 10:17 PM, Joe Greco wrote:

...

The truth is that you can keep throwing CPU at a problem as well. I can = size a software based router such that it can remain available.

Not against mpps, or even high kpps, you can't, unfortunately.

Really? I'm positive that I can, because I *have*, and other people *have*. The sweet spot for protecting a 100Mbps circuit, in particular, moved from hardware to software about five years ago. That simply means it's more cost-effective for a competent admin to spend some time to set up the box than it is to spend money on dedicated silicon that'll be obsolete in a few years, a fact that's conveniently ignored by a lot of the advocates of such solutions. To drive the point home, FreeBSD based routers that we built in 2004 are able to cope with full routing tables and IPv6 *today*, at the same traffic levels they were designed for, and those particular qualities don't seem to be present in many of the hardware-based offerings of the era. If and when they cease to be useful in that capacity, they can be trivially repurposed as firewalls or web servers or other similar tasks, because unlike the pricey purpose-built router hardware, there are advantages to general purpose hardware. Quite frankly, this is starting to be a little annoying. Perhaps you could do some research, or find some competent admins and test a few well built setups yourself before you make any more disprovable claims. My claims are not ridiculous and are not a figment of my imagination; I can point to many-years-old documented examples, such as http://lists.freebsd.org/pipermail/freebsd-net/2004-September/004840.html http://info.iet.unipi.it/~luigi/polling/ These are tests of forwarding capabilities, true, but the reality is that the same sorts of things that make this possible make it relatively easy to support large numbers of packets directed "at the control plane", since the concept of the control plane isn't as separated in the FreeBSD software model as it is in the hardware model. As a result, a FreeBSD box can take and sink quite a bit of traffic. Doing so does not cripple it. For giggles, I took two out-of-the-box FreeBSD 8.0 servers, twiddled *only* device polling to on, and started them running traffic at each other. Both were sending north of 100Mbps (>>100Kpps) of traffic at the other, both when listening and when not, no problems, no crashes, no issues. That doesn't sound too great until I reveal that I was lazy and it's only some excess capacity on a VMware box that's available to these two virtual servers.

...

Software based platforms have an incredible edge in areas that hardware b= ased platforms don't, including capex and the ability to find replacement p= arts after a disaster.

I agree 100% with this, and with much of what you say. My point is that at= the *edge* - like a BRAS, which is how this thread started - one must have= platforms which can be adequately protected against attack/abuse, and hard= ware-based platforms are the only practical way to do that.

In some cases, for some purposes, yes. Otherwise, no. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.

I briefly browsed the links and I didn't see any traffic profiles included.

If you are talking about pushing x mbps with no specifics and/or general traffic, I think most of us agree you can do that easily and probably consistently without any issues. And for some icing, you may even do it at <90% average CPU util. Does that mean it should be an edge device at any service provider? No. Some? Sure.

Those last two words are the point I've been trying to make. If you'll recall, Roland said flat out that that wasn't the case.

Can you point to any specific tests of attack vectors and/or traffic profiles with: CPU utilization, packet loss levels and pps/mbps/etc data?

Not without doing the work; I have no plans to do the work for free just to prove a point on NANOG. I have Real Work to do.

The reason I ask is that Roland is in a specific business and has a specific point.

Sure, and I'm making the point that this point isn't universally true in the way Roland would like to paint it.

As a side, were those 2 VMs on the same box? That traffic out on the wire? What's the traffic profile?

100Mbps attack on it at minimum packet size without blinking, while simultaneously delivering such an attack, in the spare CPU cycles of a vm host that has dozens of hosts on it. It's meant to suggest that what Roland is selling includes a healthy dose of FUD; I, on the other hand, am happy to concede that at a certain point, the hardware stuff is going to be more effective. It'd be nice if Roland could concede

Yes, no (just between vm's), just sheer UDP blasting of both the vservers from the other (mutual attack) with ports both closed and opened. Since Roland's point seems to be that the availability of the platform is impacted by an attack on the control plane (in this case, for all reasonable intents and purposes, that would appear to be the host OS's addresses), I didn't really feel it necessary to get particularly complicated, and just tested the control plane availability theory. My point is that a randomly created *virtual* machine can absorb a that software-based routers have some advantages and some reasonable use profiles. For example, for a provider whose entire upstream capacity is 1Gbps, I have a hard time seeing how a Linux- or FreeBSD-based box could credibly be claimed not to be a suitable edge router. The problem with Roland's statement is its absoluteness; I have a much easier side to argue, since I merely need to explain one case where the use profile does not result in failure, and there are many to choose from. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.

On Thu, Jul 15, 2010 at 11:35 AM, Dobbins, Roland <rdobbins@arbor.net> wrote:

On Jul 15, 2010, at 10:23 PM, Joe Greco wrote:

...

For example, for a provider whose entire upstream capacity is 1Gbps, I have a hard time seeing how a Linux- or FreeBSD-based box could credibly be claimed not to be a suitable edge router.

Because it can and will be whacked quite easily by anyone who packets it, either deliberately or inadvertently.  I've seen too many software-based routers fall over with far, far less traffic than 1gb/sec to think otherwise.

Since you've seen "many software-based routers fall over", can you provide details on specific hardware/software/traffic patterns/rates where you've seen these failures? From what I can tell, software based routers are almost universally used in SOHO environments; so it would be nice to know when such solutions are no longer viable in your experience. Thanks, Bill Bogstad

On Jul 15, 2010, at 11:01 PM, Cian Brennan wrote:

I'm almost certain they're not the uses that Roland is saying that software routers are entirely unsuited for.

Correct - I'm talking about SP (and even enterprise) edge routers. I've seen as little as a few hundred kpps totally hose Cisco 7200s, boxes running Zebra/Quagga, and so forth. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken

On Jul 15, 2010, at 11:33 PM, Joe Greco wrote:

Provided with a counterexample where this isn't true, you simply ignore it.

I've yet to see a counterexample involving a software-based edge router in a realistic testbed environment being deliberately packeted in order to cause an availability hit - apologies if I've missed one, mind.

Your arguments revolve around "My Ford Pinto's gas tank once exploded on me and it happened to other people too, therefore all inexpensive cars have unsafe gas tanks."

Actually, it's more along the lines of, "I've seen multiple accidents involving multiple brands/models of economy-class automobiles in which the passengers were grievously-injured or worse, while also having observed passengers walking away from similar accidents in similar circumstances involving heavier, more sturdily-built vehicles." ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken

On Jul 15, 2010, at 11:43 PM, Larry Sheldon wrote:

A democracy is two wolves and a lamb voting on what to have for dinner.

Under the assumption that I'm meant to be fulfilling the role of the lamb, I know when I'm outvoted, heh. This topic is obviously past its shelf-life. ;> ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken

RouterOS is a software based router, we have them all over the world as CORE and EDGE routers to networks. Some of our hardware can hit multi-gig speeds, BGP etc. We commonly replace 7206VXRs. Does some other form of DoS attack have an effect on it, sure, but as long as you have enough CPU to weather the storm you normally don't have major issues. ----------------------------------------------------------- Dennis Burgess, Mikrotik Certified Trainer Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net LIVE On-Line Mikrotik Training - Author of "Learn RouterOS" -----Original Message----- From: Joe Greco [mailto:jgreco@ns.sol.net] Sent: Wednesday, July 14, 2010 10:18 AM To: Dobbins, Roland Cc: NANOG list Subject: Re: Vyatta as a BRAS

On Jul 14, 2010, at 5:45 AM, Joe Greco wrote:

...

That's just a completely ignorant statement to make.

It's based on a great deal of real-world experience; I'm sorry you consider= that to be 'ignorant'.

You're speaking to someone who has extensive experience with "software" based routers, and you're failing to acknowledge the upsides of such an architecture, when I've already conceded the upsides of a hardware architecture.

...

I notice in particular how carefully you qualify that with "[w]hen BCPs = are=20 followed"; the fact that hardware router manufacturers have declared everything and anything that derails their bullet trains as "not a BCP" is a perfect example of this deceptive sort of misinformation.

Anti-spoofing, iACLs, CoPP (or its equivalent on non-Cisco platforms), et. = al. aren't 'misinformation'. They're useful, proven techniques/features wh= ich any operator ought to implement.

The things that any given use scenario ought to implement are highly dependent on the actual application.

...

There are plenty of FreeBSD based devices out there that are passing tons of traffic; almost any of them are more competent than any Cisco router I'm aware of when hitting them directly with traffic

Then your experience of Cisco routers (and/or those from other vendors) mus= t be limited to the lower-end platforms; I can assure you that faster Cisco= boxes such as ASRs, GSRs, CRSes, and so forth are in another league entire= ly, and can handle mpps of to-us traffic, when properly configured. Softwa= re-based routers simply can't do that; it's not an indictment of them, it's= just that they aren't suited to purpose, just as station wagons generally = aren't to be found in the Indy 500.

So your solution is to keep throwing heavier hardware at the problem until it works. Okay, I see that. Now, let me quote from a different message:

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

The truth is that you can keep throwing CPU at a problem as well. I can size a software based router such that it can remain available. This is neither new nor exciting technology. Luigi Rizzo was doing extensive work on this about a decade ago: he took an Athlon 750 platform with 4 100Mbit ethernet interfaces in it (Athlon 750 = 1999 tech) and was able to exceed 100Mbps levels without a problem. The UNIX based platforms have extensive capabilities to defend against attack, even without a firewall. As with a hardware based platform, there are both good things and bad things you can do that will impact availability. Software based platforms have an incredible edge in areas that hardware based platforms don't, including capex and the ability to find replacement parts after a disaster. I spent some time after the Haiti quake getting FreeBSD-based routers up and running, a task made easier because it's a lot easier to find a working PC and scavenge some network cards than it is to find a working Cisco router in a city where all inbound and outbound transportation is paralyzed. You can continue to defend your position, of course, but it's just looking a bit silly. A wise engineer knows that there are several ways to tackle any task, and "one tool for every job" is not a sound policy. If you'd like to revise your position to "Cisco and Juniper software based solutions are underpowered PoS", that's probably a defensible position, and you won't get any argument from me. Please don't generalize such a position into all software based devices, though. Overall, there are a lot more software based routers out there than hardware based devices. Your cablemodem, your ADSL modem, your wifi access point, all these are probably software based devices. Some of them will melt under a too-great load. Some won't. This is a function of many different factors. There is nothing inherent in a software-based device that's going to make it fail under load - just as there's nothing inherent in a hardware-based device that's going to make it succeed (which is why you have to qualify your defense of these with "must follow BCP"). It's the related engineering that ultimately determines whether or not it all works out. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.

On Thursday, July 15, 2010 02:24:06 pm Łukasz Bromirski wrote:

(and I'm all for FreeBSD boxes, don't get me wrong, the whole point of this discussion is that either you're doing hardware forwarding and you're pretty safe [unfortunately often with a lot of caveats, but still], or you're doing software forwarding and you have a nice attack vector open for anyone willing)

This distills one of the points of view nicely. An operationally useful question is to ask (yourself) at what point (bandwidth- and type of traffic- speaking) does a particular box become vulnerable? 10Mb/s? 100Mb/s? 1Gb/s? 100Gb/s? Traffic directed at the control plane? Small packet traffic? Any traffic? Any box; hardware-based or software-based is irrelevant, because at some data volume all boxes become vulnerable; the variance is only in what volume the box can handle and how well the control plane is protected from that volume. Test with reasonable traffic loads (and drawing on the collective wisdom of this group as to what is 'reasonable' for a BRAS is good!), and derive conclusions that fit your need. Knowing these things allows you to scale your solution to avoid the majority of the problems and buy what fits your projected scale over the design life of the solution. Take a 2003-vintage OSR7609 (Sup2/MSFC2) still running 12.1E. Definitely a hardware-based router. Does it have a nice attack vector? Perhaps. Is this combination still in use? I'm not sure I want to know (Sup2/MSFC2 is, I know; the 12.1E part is the scary one). Hardware-based is not a magic bullet that destroys attack vectors dead in their tracks (as Łukasz hints at with the parenthetical caveats remark). And software-based is not defenseless, either.

I have that same problem with vendors that insist that there is a core vs customer vs peering edge set in networks. If a customer has 10g to a specific peer why should one not place them on the same device, ASIC, linecard, usw.... Core today means something that is 200g+/slot capable IMHO. Anything else is non-core. Jared Mauch On Jul 16, 2010, at 9:28 AM, Paul WALL <pauldotwall@gmail.com> wrote:

On Thu, Jul 15, 2010 at 1:22 PM, Dennis Burgess <dmburgess@linktechs.net> wrote:

...

RouterOS is a software based router, we have them all over the world as CORE and EDGE routers to networks.

You keep using that word ("CORE"). I do not think it means what you think it means.

Drive Slow, DoS Slower, Paul Wall

On Thu, 15 Jul 2010 20:57:15 PDT, Henry Linneweh said: Your definitions seem to be rather ATM-specific, which may be a bit of a problem in a world dominated by Ethernet...

Can we get a consensus definition on these definition's and what hardware vender's make edge routers and what hardware vender's make core routers.

I got a router, it's got 5-6 10GE interfaces talking to other routers on my network backbone, and a bunch of 10GE links to end-user-facing aggregation switches. Since it's only forwarding inside my network, it's a core router by your definition. I now turn up an identical hardware 10GE link - connected to Level3. I just became an edge router by your definition since I'm talking to another network. (I know, I probably don't want to do that - but I *could*, maybe even without a full BGP feed if the routing situation allows. The point is the definition is busticated). Adding to the confusion is the fact that the edge routers of some large providers need more capacity than the core routers of smaller organizations.... Maybe we need to ditch the terms edge and core, and instead talk about: 1/4" plastic tubing - http://www.waterfiltermart.com/images/products/preview/plastic_tubing_and_nu... garden hose - http://upload.wikimedia.org/wikipedia/commons/thumb/c/cd/Garden_hose.jpg/800... fire hose - http://www.firetrainingcenter.com/images/FireHoseStreams.jpg NYC Delaware Aqueduct - http://www.allpropertymanagement.com/blog/2010/02/09/worlds-awesome-tunnels/ Everybody good with that? ;) (Man.. it *leaks* 15 million gallons a day. That's capacity. :)

On Jul 16, 2010, at 6:02 AM, Valdis.Kletnieks@vt.edu wrote:

1/4" plastic tubing - http://www.waterfiltermart.com/images/products/preview/plastic_tubing_and_nu... garden hose - http://upload.wikimedia.org/wikipedia/commons/thumb/c/cd/Garden_hose.jpg/800... fire hose - http://www.firetrainingcenter.com/images/FireHoseStreams.jpg NYC Delaware Aqueduct - http://www.allpropertymanagement.com/blog/2010/02/09/worlds-awesome-tunnels/

So, you finally admit it. The Internet is just a bunch of tubes. ;-) Tony

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

On Tue, 13 Jul 2010 18:11:45 -0000, "Dobbins, Roland" said:

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.

Cisco 7206VXF apparently had some issues dealing with it: https://puck.nether.net/pipermail/cisco-nsp/2003-September/005578.html Slammer's use of multicast addresses melted down at least a few large Cisco and Juniper boxes: http://paintsquirrel.ucs.indiana.edu/pdf/SLAMMER.pdf I wasn't aware that the 7206 and M20 classified as software-based. (cue weasel-words about those routers using ASICs for most forwarding, but doing multicast forwarding in software in 5.. 4.. 3..)

On Jul 14, 2010, at 4:03 AM, <Valdis.Kletnieks@vt.edu> wrote:

I wasn't aware that the 7206 and M20 classified as software-based.

7200 certainly is - I'm not familiar with the minutiae of Juniper boxes, but I believe the M20 is hardware-based. In the classic report you cite, the issue with the M20 occurred due to lack of BCP implementation. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken

On Jul 14, 2010, at 8:38 PM, Florian Weimer wrote:

There's also the question of IP options (or extension headers). 8-)

I know that some modern hardware-based routers have the ability to either ignore options, or to drop option packets altogether. I believe the same is now true of IPv6 extension-headere, or soon will be. You're absolutely correct that this is a significant possible attack vector, causing the packets in question to be punted, if there isn't a mechanism available to ignore them or to drop said packets. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken

On Jul 14, 2010, at 8:59 PM, Florian Weimer wrote:

There might be contractual reasons not to enable that feature. 8-/

Ignoring is generally pretty harmless; dropping can break traceroute, RSVP, et. al. Conversely, there are also generally pretty strong contractual reasons not to have one's edge routers go down due to excessive punts. ;>

Some vendors can process options in hardware, though.

True.

It's probably not a high-priority issue for vendors until there are network issues (as opposed to potential problems seen in labs),

This is always true when it comes to security, and especially to availability. That being said, I know that at least one major vendor is cognizant of the header-extenstion issue, and is taking steps to mitigate the associated risk.

so it's going to take quite a bit of time.

Yes, this is always the case, unfortunately.

Demand for devices with some IP-layer inspection capability that can handle (Fast or Gigabit) Ethernet at line rate, no matter what type of frames come in, is also a pretty recent thing, and I would be surprised if vendors can provide such capabilities across their entire relevant product line (where they advertise line-based forwarding).

With large vendors, these things are generally accomplished piecemeal, on a BU-by-BY, product-by-product basis. Unfortunate, but true, nonetheless. ----------------------------------------------------------------------- Roland Dobbins <rdobbins@arbor.net> // <http://www.arbornetworks.com> Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken

...

I wasn't aware that the 7206 and M20 classified as software-based.

I don't see why you could call it anything but a software router.

The 7206 yes. The M20, no. Steinar Haug, Nethelp consulting, sthaug@nethelp.no