subject:"Vyatta as a BRAS"


On Jul 19, 2010, at 5:43 AM, Mark Smith wrote:

> This document supports that.

No, it doesn't.

Specialized NPUs, TCAMs present in ASR1K.

CRS-3 has specialized NPUs, ASICs, as well.

Enough on this topic - it's obvious that both ASR1K and CRS-3 are 
hardware-based platforms.

---
Roland Dobbins  // 

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

-- H.L. Mencken

Re: Vyatta as a BRAS

2010-07-18 Thread Mark Smith

On Sun, 18 Jul 2010 18:12:29 +0100
Nick Hilliard  wrote:

> On 18 Jul 2010, at 10:58, "Dobbins, Roland"  wrote:
> > ASR1K, which is what I'm assuming you're referring to, is a hardware-based 
> > router.  Same for ASR9K.
> 
> My c* SE swears that the asr1k is a "software router".  I didn't push him on 
> it's architecture though. 
> 

This document supports that. If the definition of a software router is
one that doesn't have a fixed at the factory forwarding function, then
the ASR1K is one.

http://www.cisco.com/en/US/prod/collateral/routers/ps9343/solution_overview_c22-448936.html

The CRS-3 might be too, as they say they've added the quantumflow
processor into those too.

> The asr9k is an npu based device - a completely different beast with 
> different architecture / operating system / capabilities / etc.
> 
> Nick

Re: Vyatta as a BRAS

On Jul 19, 2010, at 1:12 AM, Nick Hilliard wrote:

> My c* SE swears that the asr1k is a "software router".  I didn't push him on 
> it's architecture though. 

Specialized multicore NPU + TCAM = hardware.

---
Roland Dobbins  // 

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

-- H.L. Mencken

Re: Vyatta as a BRAS


On Jul 19, 2010, at 1:55 AM, Brett Frankenberger wrote:

> So where do you draw the line?  Is the ASR hardware forwarding? 


Yes - specialized muticore NPU plus TCAM.

---
Roland Dobbins  // 

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

-- H.L. Mencken

Re: Vyatta as a BRAS

2010-07-18 Thread Brett Frankenberger

On Sun, Jul 18, 2010 at 06:12:29PM +0100, Nick Hilliard wrote:
> On 18 Jul 2010, at 10:58, "Dobbins, Roland"  wrote:
> > ASR1K, which is what I'm assuming you're referring to, is a
> > hardware-based router.  Same for ASR9K.
> 
> My c* SE swears that the asr1k is a "software router".  I didn't push
> him on it's architecture though.

All routers have hardware, and any but the most overwhelmingly simple
"hardware" based devices are using ASICs running software to puah
packets around.  The line has been blurred for a long time, and the
ASR1K makes it very, very blurry.

It forwards packets in a relatively general-purpose (but not as general
purpose as, say the Intel processors inside your servers) CPU that has
40 cores and is optimised (it's architecture, instruction set, etc.)
for moving packets around.  Is that hardware forwarding?  Is that
software forwarding?  Depends in what you want to call it.

Do video cards with high-end GPUs do things in "hardware" or
"software"?  There are now development kits to allow you to easily use
those GPUs to do general purpose compute tasks.  The processors in the
ASR could do that, also, but Cisco hasn't written any code or released
ay libraries to actually do that (at lease not publicly; I wouldn't be
surprised to learn that some developer has hacked a 40-threaded
s...@home or something like that onto it just to prove it could be
done).

So where do you draw the line?  Is the ASR hardware forwarding?  If so,
would it still be hardware if, intead of the specialized processor,
Cisco got Intel to develop a 40-core pentium and used that?  What if
Cisco instead used 10 off-the-shelf 4-core processors from Intel or
AMD?  Where along this continuoum do we cross the line from "software
router" to "hardware router"?

 -- Brett

Re: Vyatta as a BRAS

2010-07-18 Thread Nick Hilliard

On 18 Jul 2010, at 10:58, "Dobbins, Roland"  wrote:
> ASR1K, which is what I'm assuming you're referring to, is a hardware-based 
> router.  Same for ASR9K.

My c* SE swears that the asr1k is a "software router".  I didn't push him on 
it's architecture though. 

The asr9k is an npu based device - a completely different beast with different 
architecture / operating system / capabilities / etc.

Nick

Re: Vyatta as a BRAS


On Jul 18, 2010, at 9:47 AM, Mark Smith wrote:

> Since specific routers have been mentioned, care to comment on the Cisco ASR? 


ASR1K, which is what I'm assuming you're referring to, is a hardware-based 
router.  Same for ASR9K.

---
Roland Dobbins  // 

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

-- H.L. Mencken

Re: Vyatta as a BRAS

2010-07-17 Thread Mark Smith

On Wed, 14 Jul 2010 14:12:07 +
"Dobbins, Roland"  wrote:

> 
> On Jul 14, 2010, at 8:48 PM, Florian Weimer wrote:
> 
> > From or to your customers?
> 
> Both.
> 
> > Stopping customer-sourced attacks is probably a good thing for the Internet 
> > at learge.
> 
> Concur 100%.
> 
> >  And you can't combat attacks targeted at customers within your own network 
> > unless you've got very large WAN
> > pipes, moving you into the realm of special-purpose hardware for other 
> > reasons.
> 
> Sure, you can, via S/RTBH, IDMS, et. al.  While DNS reflection/amplification 
> attacks are used to create crushing volumes of attack traffic, and even 
> smallish botnets can create high-volume attacks, most packet-flooding attacks 
> are predicated on throughput - i.e., pps - rather than bandwidth, and tend to 
> use small packets.  Of course, they can use *lots and lots* of small packets, 
> and often do, but one can drop these packets via the various mechanisms one 
> has available, then reach out to the global opsec community for filtering 
> closer to the sources.
> 
> The thing is, with many DDoS attacks, the pps/bps/cps/tps required to disrupt 
> the targets can be quite small, due to the unpreparedness of the defenders.  
> Many high-profile attacks discussed in the press such as the Mafiaboy 
> attacks, the Estonian attacks, the Russian/Georgian/Azerbaijan attacks, the 
> China DNS meltdown, and the RoK/USA DDoS attacks were all a) low-volume, b) 
> low-throughput, c) exceedingly unsophisticated, and d) eminently avoidable 
> via sound architecture, deployment of BCPs, and sound operational practices.
> 
> In fact, many DDoS attacks are quite simplistic in nature and many are low in 
> bandwidth/throughput; the miscreants only use the resources necessary to 
> achieve their goals, and due to the unpreparedness of defenders, they don't 
> have a need to make use of overwhelming and/or complex attack methodologies.
> 
> This doesn't mean that high-bandwidth, high-throughput, and/or complex DDoS 
> attacks don't occur, or that folks shouldn't be prepared to handle them; 
> quite the opposite, we see a steady increase in attack volume, thoughput and 
> sophistication at the high end.  But the fact of the matter is that many DDoS 
> targets - and associated network infrastructure, and services such as DNS - 
> are surprisingly fragile, and thus are vulnerable to surprisingly 
> simple/small attacks, or even inadvertent/accidental attacks.
> 
> > Previously, this was really a no-brainer because you couldn't get PCI
> > cards with the required interfaces, but with Ethernet everywhere, the
> > bandwidths you can handle on commodity hardware will keep increasing.
> 
> Concur 100%.
> 
> > Eventually, you'll need special-purpose hardware only for a smallish
> > portion at the top of the router market, or if you can't get the
> > software with the required protocol support on other devices.
> 
> I believe that the days of software-based routers are numbered, period, due 
> to the factors you describe.  Of course, the 'top of the router market' seems 
> to keep moving upwards, despite many predictions to the contrary.
> 

Since specific routers have been mentioned, care to comment on the Cisco
ASR? If the days of software-based routers are numbered, I'm sure
Cisco would have recognised that, and not gone and developed it (or
rather, bought the company that did).

It seems to me that three key factors that haven't been discussed in
this thread are the chances of failure, types of failure triggers and
consequence of failure. It seems to have been a binary hardware = no
failure, software = failure.

If you put large amounts of traffic on a single router, you're likely
to need a hardware router, driving up the cost, sacrificing flexibility
and re-deployability, and impacting very large numbers of network users
if it fails. You may not be vulnerable or as vulnerable to a DoS
(software punt mentioned), but DoS's aren't the only type of failure you
can suffer from. Software faults on these high end platforms can be a
far more common issue within the first few years of release, because
they're less widely deployed. Hardware forwarding doesn't protect you
from protocol or protocol implementation vulnerabilities on the control
plane, and since these are big boxes with a big consequence if they
fail, they're a much larger target to aim for.

OTOH, if you have options to divide the traffic load across a number of
smaller routers, then you may gain the cost effectiveness of more
commodity platforms (with the ultimate commodity platform being a PC
acting as a router), more robustness because the platform is being used
by far more people in far more environments, and less of a consequence
when failures occur (DoS or not).

I don't think the hardware/software augment is as simple as it is being
made out to be. It is completely context dependent. Cost, availability,
scalability and flexibility all need to be considered. I personally put
a f

Re: Vyatta as a BRAS

2010-07-16 Thread Joel Jaeggli

On 7/16/10 6:02 AM, valdis.kletni...@vt.edu wrote:

On Thu, 15 Jul 2010 20:57:15 PDT, Henry Linneweh said:

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

There's also virtualization due to the ubiquitous deployment of VRF's
moderate to size extra-large routers are entirely likely to be serving
in multiple roles.

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_nut.jpg
garden hose -
http://upload.wikimedia.org/wikipedia/commons/thumb/c/cd/Garden_hose.jpg/800px-Garden_hose.jpg
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. :)

Re: Vyatta as a BRAS

2010-07-16 Thread Tony Li


On Jul 16, 2010, at 6:02 AM, valdis.kletni...@vt.edu wrote:

> 1/4" plastic tubing - 
> http://www.waterfiltermart.com/images/products/preview/plastic_tubing_and_nut.jpg
> garden hose - 
> http://upload.wikimedia.org/wikipedia/commons/thumb/c/cd/Garden_hose.jpg/800px-Garden_hose.jpg
> 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

Re: Vyatta as a BRAS

2010-07-16 Thread Lamar Owen

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.

Re: Vyatta as a BRAS

2010-07-16 Thread Joe Greco

> 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

There's a problem here in that some people want 'core router' to mean
'biggest fscking router', while other people want a functional 
definition that explains a router's role in the design of a network.

For an enterprise, for example, it doesn't make sense for them to have
a router in the middle of their network and then tell them "but you can
not call it your core router, because that term is reserved for routers
with 200g or more capacity per slot (Jared's def'n)."

I'm going to submit that the "big fscking router" definition is stupid
and meaningless, because today's big fscking router is tomorrow's small
aggregation router, and then a few years later just a coffee table stand.
Hello, 7513 from .. what, 1995?  :-)

A more customary understanding of border, core, etc., can be found in
places like RFC4098.

Generally speaking, a core router is an internal router, i.e. one that
speaks only to other devices/endpoints/whatever in the same AS.  Various
refinements to the definition might want it to speak BGP, etc.

That definition is very reasonable.  A small enterprise with a DS3 to the
'net has a border router that connects them to their ISP, which connects
to a firewall/IDS that protects their net, and then a core router that
connects all their internal networks and links to the firewall for 
external connectivity.  You could talk to most network engineers and 
they'd understand the terminology without further explanation.

There are of course problems with the core and border definitions as
well, of course, such as what happens when you connect a core router
interface to an upstream and you wind up with a mongrel.  However, the
"core means bfr" definition strikes me as singularly useless and
something that's really more marketingspeak from router vendors who
would like you to think of these routers powering the core of the
Internet, or whatever.

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

Re: Vyatta as a BRAS

2010-07-16 Thread Valdis . Kletnieks

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.

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:

Everybody good with that? ;)

(Man.. it *leaks* 15 million gallons a day. That's capacity. :)

pgp7S3BXcEYfv.pgp
Description: PGP signature

Re: Vyatta as a BRAS

2010-07-15 Thread Henry Linneweh

Edge Router Definition:
 - A term used in asynchronous transfer mode (ATM) networks, an edge router is 
a 
device that  routes data packets between one or more local area networks (LANs) 
and an ATM backbone network, whether a campus network or a wide area network 
(WAN).   An edge router is an example of an edge device and is sometimes  
referred to as a boundary router.  An edge router is sometimes  contrasted with 
a core router, which forwards packets to computer  hosts within a network (but 
not between networks). 


Core Router:
 - A core router is a router that forwards packets to computer hosts within a 
network (but not between networks).  A  core router is sometimes contrasted 
with 
an edge router,  which routes packets between a self-contained network and 
other 
outside  networks along a network backbone. 


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 think this will make us all, have the same understanding.

-henry





From: Paul WALL 
To: Dennis Burgess 
Cc: nanog@nanog.org
Sent: Thu, July 15, 2010 5:28:44 PM
Subject: Re: Vyatta as a BRAS

On Thu, Jul 15, 2010 at 1:22 PM, Dennis Burgess  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

Re: Vyatta as a BRAS

2010-07-15 Thread Jared Mauch

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  wrote:

> On Thu, Jul 15, 2010 at 1:22 PM, Dennis Burgess  
> 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

Re: Vyatta as a BRAS

2010-07-15 Thread Paul WALL

On Thu, Jul 15, 2010 at 1:22 PM, Dennis Burgess  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

Re: Vyatta as a BRAS

2010-07-15 Thread Łukasz Bromirski

On 2010-07-15 19:22, Dennis Burgess wrote:

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

Wonderful, congratulations.

> Some of our hardware can hit multi-gig speeds, BGP etc.

Same can do your competitors.

We commonly replace 7206VXRs.

Sad story, really. And I bet 7200VXRs commonly replace RouterOS.

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

Sure, a lot of people were at this point of their learning curve,
pretty sure that they will withstand anything with their multi-GHz,
multi-core CPUs. Then they met real world, or as it is often said,
real world met them.

(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)

--
"Everything will be okay in the end.  | Łukasz Bromirski
 If it's not okay, it's not the end." |  http://lukasz.bromirski.net

RE: Vyatta as a BRAS

2010-07-15 Thread Dennis Burgess

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:jgr...@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.  Som

Re: A question for the house and the moderators (was Re: Vyatta as a BRAS)


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  // 

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

-- H.L. Mencken

A question for the house and the moderators (was Re: Vyatta as a BRAS)

2010-07-15 Thread Larry Sheldon

Oops--itch trigger finger


[a round of the on-going and growing tedious micturation tournament]

Is this squalling fest really more "operational" than a conversation
dealing with a disabling spam attack?

Really?

-- 
Somebody should have said:
A democracy is two wolves and a lamb voting on what to have for dinner.

Freedom under a constitutional republic is a well armed lamb contesting
the vote.

Requiescas in pace o email
Ex turpi causa non oritur actio
Eppure si rinfresca

ICBM Targeting Information:  http://tinyurl.com/4sqczs
http://tinyurl.com/7tp8ml

A question for the house and the moderators (was Re: Vyatta as a BRAS)

2010-07-15 Thread Larry Sheldon

On 7/15/2010 11:39, Dobbins, Roland wrote:
> 
> 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  // 
> 
> Injustice is relatively easy to bear; what stings is justice.
> 
> -- H.L. Mencken
> 
> 
> 
> 
> 


-- 
Somebody should have said:
A democracy is two wolves and a lamb voting on what to have for dinner.

Freedom under a constitutional republic is a well armed lamb contesting
the vote.

Requiescas in pace o email
Ex turpi causa non oritur actio
Eppure si rinfresca

ICBM Targeting Information:  http://tinyurl.com/4sqczs
http://tinyurl.com/7tp8ml

Re: Vyatta as a BRAS

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  // 

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

-- H.L. Mencken

Re: Vyatta as a BRAS

2010-07-15 Thread Joe Greco

> On Jul 15, 2010, at 10:23 PM, Joe Greco wrote:
> > For example, for a provider whose entire upstream capacity is 1Gbps, I ha=
> ve a hard time seeing how a Linux- or FreeBSD-based box could credibly be c=
> laimed not to be a suitable edge router.
> 
> Because it can and will be whacked quite easily by anyone who packets it, e=
> ither deliberately or inadvertently.  I've seen too many software-based rou=
> ters fall over with far, far less traffic than 1gb/sec to think otherwise.

You seem to be off in your own little world.  Provided with a 
counterexample where this isn't true, you simply ignore it.  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."

The sad reality is that any gas tank can be ruptured and can be made to
explode, but concluding that this is limited to inexpensive cars is a
silly conclusion.  The fact of the matter is that a /poorly engineered/
gas tank is much more prone to problems, whether it's in an inexpensive
car or a high end one.

You're drawing poor conclusions based on even poorer reasoning.  Your
negative experience with some software routers does not mean that they
are all crap, just as my negative experience with some hardware routers
does not mean that they are all crap.

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

Re: Vyatta as a BRAS

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  // 

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

-- H.L. Mencken

Re: Vyatta as a BRAS

2010-07-15 Thread Cian Brennan

On Thu, Jul 15, 2010 at 11:54:39AM -0400, Bill Bogstad wrote:
> On Thu, Jul 15, 2010 at 11:35 AM, Dobbins, Roland  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.
> 
SOHO environmnents aren't normally targets of DOS attacks. And if they are,
their pipes are probably small enough to be easily filled with far less
difficulty than making the router fall over.

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

> Thanks,
> Bill Bogstad
> 
>

Re: Vyatta as a BRAS

2010-07-15 Thread Bill Bogstad

On Thu, Jul 15, 2010 at 11:35 AM, Dobbins, Roland  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

Re: Vyatta as a BRAS

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.

---
Roland Dobbins  // 

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

-- H.L. Mencken

Re: Vyatta as a BRAS

2010-07-15 Thread Joe Greco

> 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?

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

Re: Vyatta as a BRAS

2010-07-14 Thread Tony Varriale

- Original Message - 
From: "Joe Greco" 

To: "Dobbins, Roland" 
Cc: "NANOG list" 
Sent: Wednesday, July 14, 2010 7:03 PM
Subject: Re: Vyatta as a BRAS

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.

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? 
The reason I ask is that Roland is in a specific business and has a specific 
point.

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

tv

Re: Vyatta as a BRAS

2010-07-14 Thread Joe Greco

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

Re: Vyatta as a BRAS

2010-07-14 Thread Joel Jaeggli


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


On Jul 14, 2010, at 1:02 AM, Matthew Kaufman wrote:


Dangerous in places where forwarding table exceeds hardware cache
limits. (See Code Red worm stories)



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.


Having msdp turned on was a great way to get nuked by slammer regardless 
of your choice of forwarding technology.


Which reminds me control plane protection is about more than just acls 
and rate limiting.



---



Roland Dobbins  //


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

-- H.L. Mencken

Re: Vyatta as a BRAS

2010-07-14 Thread Per Carlson

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

It might well be software engines in there, but that's not the point
here. The linecards (MSC/PLIM etc.) in a CRS is designed to handle
wirerate traffic *of any packet length* and simultaneously do ACLs,
QoS or whatever else you throw at them. If that is done using FPGAs,
CPUs or trained monkeys isn't really that interesting, as long as it
works. And it does. But it won't come for free.

A software-based router, i.e something equipped with a central CPU
doing all heavy lifting, of *any kind* isn't designed to do that.

The old corollary 7a in RFC1925 still make sense: "Good, Fast, Cheap:
Pick any two (you can't have all three)."

Some of the arguments expressed also vaguely resembles truth 11 in the
same RFC:
Every old idea will be proposed again with a different name and a
different presentation, regardless of whether it works.

There is a reason internet isn't built on Dell hardware...

-- 
Pelle

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

Re: Vyatta as a BRAS

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.

Re: Vyatta as a BRAS

2010-07-14 Thread sthaug

> > 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, sth...@nethelp.no

Re: Vyatta as a BRAS

2010-07-14 Thread sthaug

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

How many of them are deploying server-grade SMP hardware / commodity OS
to handle 10 Gig links and expect to handle DoS attacks using minimum
sized packets? That's 14.88 Mpps with Ethernet encapsulation, for each
10 Gig link.

Anybody?

Steinar Haug, Nethelp consulting, sth...@nethelp.no

Re: Vyatta as a BRAS

2010-07-14 Thread Jon Lewis


On Tue, 13 Jul 2010 valdis.kletni...@vt.edu wrote:


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.  That's 
sort of why things like it and the 7500 before it lasted so long.  As the 
thing ages, cisco comes out with new NPE (or RSP/VIP) processors with 
faster CPUs / more memory capacity that are able to move more packets. 
i.e. NPE-100->NPE-150->NPE-200->NPE-225->NPE-300->NPE-400->NPE-G1->NPE-G2


You could start with a VXR with NPE-225 and keep upgrading the CPU and 
keep the thing in service with the same interface cards 15 years or more.


--
 Jon Lewis   |  I route
 Senior Network Engineer |  therefore you are
 Atlantic Net|
_ http://www.lewis.org/~jlewis/pgp for PGP public key_

Re: Vyatta as a BRAS

2010-07-14 Thread Lamar Owen

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.

Re: Vyatta as a BRAS

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.

> 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 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 
hardware-based platforms are the only practical way to do that.

---
Roland Dobbins  // 

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

-- H.L. Mencken

Re: Vyatta as a BRAS

2010-07-14 Thread Joe Greco

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

Re: Vyatta as a BRAS

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  // 

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

-- H.L. Mencken

Re: Vyatta as a BRAS

2010-07-14 Thread Florian Weimer

* Roland Dobbins:

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

There might be contractual reasons not to enable that feature. 8-/
Some vendors can process options in hardware, though.

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

It's probably not a high-priority issue for vendors until there are
network issues (as opposed to potential problems seen in labs), so
it's going to take quite a bit of time.  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).

-- 
Florian Weimer
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

Re: Vyatta as a BRAS

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

> From or to your customers?

Both.

> Stopping customer-sourced attacks is probably a good thing for the Internet 
> at learge.

Concur 100%.

>  And you can't combat attacks targeted at customers within your own network 
> unless you've got very large WAN
> pipes, moving you into the realm of special-purpose hardware for other 
> reasons.

Sure, you can, via S/RTBH, IDMS, et. al.  While DNS reflection/amplification 
attacks are used to create crushing volumes of attack traffic, and even 
smallish botnets can create high-volume attacks, most packet-flooding attacks 
are predicated on throughput - i.e., pps - rather than bandwidth, and tend to 
use small packets.  Of course, they can use *lots and lots* of small packets, 
and often do, but one can drop these packets via the various mechanisms one has 
available, then reach out to the global opsec community for filtering closer to 
the sources.

The thing is, with many DDoS attacks, the pps/bps/cps/tps required to disrupt 
the targets can be quite small, due to the unpreparedness of the defenders.  
Many high-profile attacks discussed in the press such as the Mafiaboy attacks, 
the Estonian attacks, the Russian/Georgian/Azerbaijan attacks, the China DNS 
meltdown, and the RoK/USA DDoS attacks were all a) low-volume, b) 
low-throughput, c) exceedingly unsophisticated, and d) eminently avoidable via 
sound architecture, deployment of BCPs, and sound operational practices.

In fact, many DDoS attacks are quite simplistic in nature and many are low in 
bandwidth/throughput; the miscreants only use the resources necessary to 
achieve their goals, and due to the unpreparedness of defenders, they don't 
have a need to make use of overwhelming and/or complex attack methodologies.

This doesn't mean that high-bandwidth, high-throughput, and/or complex DDoS 
attacks don't occur, or that folks shouldn't be prepared to handle them; quite 
the opposite, we see a steady increase in attack volume, thoughput and 
sophistication at the high end.  But the fact of the matter is that many DDoS 
targets - and associated network infrastructure, and services such as DNS - are 
surprisingly fragile, and thus are vulnerable to surprisingly simple/small 
attacks, or even inadvertent/accidental attacks.

> Previously, this was really a no-brainer because you couldn't get PCI
> cards with the required interfaces, but with Ethernet everywhere, the
> bandwidths you can handle on commodity hardware will keep increasing.

Concur 100%.

> Eventually, you'll need special-purpose hardware only for a smallish
> portion at the top of the router market, or if you can't get the
> software with the required protocol support on other devices.

I believe that the days of software-based routers are numbered, period, due to 
the factors you describe.  Of course, the 'top of the router market' seems to 
keep moving upwards, despite many predictions to the contrary.

---
Roland Dobbins  // 

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

-- H.L. Mencken

Re: Vyatta as a BRAS

2010-07-14 Thread Florian Weimer

* Roland Dobbins:

> That's what I meant - even a very small botnet can easily overwhelm
> software-based edge routers.

>From or to your customers?

Stopping customer-sourced attacks is probably a good thing for the
Internet at learge.  And you can't combat attacks targeted at
customers within your own network unless you've got very large WAN
pipes, moving you into the realm of special-purpose hardware for other
reasons.

Previously, this was really a no-brainer because you couldn't get PCI
cards with the required interfaces, but with Ethernet everywhere, the
bandwidths you can handle on commodity hardware will keep increasing.
Eventually, you'll need special-purpose hardware only for a smallish
portion at the top of the router market, or if you can't get the
software with the required protocol support on other devices.

-- 
Florian Weimer
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

Re: Vyatta as a BRAS


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  // 

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

-- H.L. Mencken

Re: Vyatta as a BRAS

2010-07-14 Thread Florian Weimer

* Valdis Kletnieks:

> (cue weasel-words about those routers using ASICs for most forwarding, but
> doing multicast forwarding in software in 5.. 4.. 3..)

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

-- 
Florian Weimer
BFK edv-consulting GmbH   http://www.bfk.de/
Kriegsstraße 100  tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99

Re: Vyatta as a BRAS

On Jul 14, 2010, at 7:01 PM,  
 wrote:

> But as others have stated, the 7206 has at least some hardware acceleration,

Unfortunately, said statements are factually incorrect.  7200s have no hardware 
acceleration of any type whatsoever.

from 
:

'Processor

1.67-GHz Motorola Freescale 7448 processor'

> so it's *not* a router that uses *only* centralized general-purpose CPUs.

Actually, it is.  Same with ISRs.

from 

Note the 'Multicore Processor' line-item - singular.

The SREs for the ISR2s do each contain their own Intel x86 processor - so, the 
ISR2 models which can take SREs are distributed platforms, but aren't 
hardware-based in the sense that they contain high-performance forwarding 
chips.  The processors in the SREs are used to run applications on-board the 
router itself - so, they're kind of like special-purpose servers on a card, 
rather than high-performance linecards as one finds in higher-end platforms.

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

It's extremely useful to differentiate routers which have special-purpose 
forwarding hardware from those which don't, as the latter crumble quite quickly 
when packeted.  If you don't believe me, run some tests of your own with purely 
software-based routers, such as 7200s, and then with a hardware-based router 
such as an ASR1K, ASR9K, GSR, CRS-1, N7K, what-have-you.

I've seen this divergent behavior between software-based and hardware-based 
platforms time and time again in real, live production networks, during real, 
live attacks.  It isn't something which can simply be dismissed by semantic 
hairsplitting.

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

> 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?

Hardware, obviously - it has special-purpose NPUs on the linecards, along with 
special-purpose ASICs, and TCAMs.  

> Lots of custom hardware in there - but lots of processing cores that look 
> suspiciously like software engines too.

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

Anyway, enough on this topic.  If folks wish to continue to deploy 
software-based routers at the edges of their networks, then they oughtn't to be 
surprised or dismayed when said software-based routers fall over under 
relatively small amounts of packeting, either deliberate attacks or as the 
result of misconfiguration, et. al.  If, on the other hand, they prize 
availability, then investing in hardware-based platforms and then configuring 
said hardware-based routers with the appropriate BCPs greatly reduces the risk 
of such an occurrence.

---
Roland Dobbins  // 

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

-- H.L. Mencken

Re: Vyatta as a BRAS

2010-07-14 Thread Valdis . Kletnieks

On Wed, 14 Jul 2010 02:18:18 -, "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.



pgpvXXVQOMD51.pgp
Description: PGP signature

Re: Vyatta as a BRAS

On Jul 14, 2010, at 1:34 PM, Mikael Abrahamsson wrote:

>  CRS-1 uses multicore processors (hundreds of cores) for forwarding on their 
> linecards, and they achieve 40+ Mpps per linecard.

The CRS-1 makes use of the Metro subsystem for forwarding, with multiple Metros 
per Modular Service Card (MSC).  Each Metro complex (there are two per MSC) 
consists of the Metro chip itself, an NPU which contains 188 embedded RISC 
cores; two TCAM banks; SRAM; and FCRAM.

There's also a gatekeeper ASIC of some sort on the MSC which handles traffic 
incoming from the fabric, as well as another interface module ASIC on the 
Physical Layer Interface Module (PLIM).

I believe the CRS-3-specific MSCs each contain two QFAP complexes, which allow 
for 140gb/sec per linecard, and that there are various additional supporting 
ASICs on the MSCs and the PLIMs, as well.

---
Roland Dobbins  // 

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

-- H.L. Mencken

Re: Vyatta as a BRAS

2010-07-13 Thread Mikael Abrahamsson


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 Abrahamssonemail: swm...@swm.pp.se

Re: Vyatta as a BRAS

On Jul 14, 2010, at 9:31 AM, Dan White wrote:

> has the appearance of you struggling to hold on to an idea that may have been 
> more true in the past,

It's true today, and I'm not 'struggling to hold' onto anything.  Take any 
software-based router from Cisco or Juniper or whomever (if Juniper still make 
software-based routers, I don't know if they do or not), packet it until it 
falls over, then repeat the process with a properly-configured hardware-based 
router from the same manufacturer - you can demonstrate the validity of the 
proposition for yourself, as the hardware-based router can handle considerably 
more traffic, whereas the software-based router will pitch over as a result of 
a surprisingly small amount of traffic.

> and less true today, as is evident based on the input from other list 
> participants.

Input based upon experience which is seemingly heavily weighted towards the 
lower end, rather than the higher end, of network speeds and routing platforms 
- and which doesn't seem to encompass much examination of the ability of said 
lower-end devices to maintain availability in the face of direct attack.

It can be quite interesting to take a packet-generator to a software-based 
router and see just how easy it is to make it fall over, and then repeat the 
experience with a hardware-based router, and consider the implications thereof, 
even at relatively low bandwidth/throughput.

---
Roland Dobbins  // 

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

-- H.L. Mencken

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

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

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

> 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) must 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 entirely, and can 
handle mpps of to-us traffic, when properly configured.  Software-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.

;>

---
Roland Dobbins  // 

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

-- H.L. Mencken

Re: Vyatta as a BRAS

2010-07-13 Thread Dan White


On 14/07/10 02:18 +, 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

Re: Vyatta as a BRAS


On Jul 14, 2010, at 4:03 AM,  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  // 

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

-- H.L. Mencken

Re: Vyatta as a BRAS

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.

;>

---
Roland Dobbins  // 

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

-- H.L. Mencken

Re: Vyatta as a BRAS

2010-07-13 Thread Joe Greco

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

Re: Vyatta as a BRAS

On Tuesday, July 13, 2010 12:31:25 pm Christian Chapman wrote:
> >> 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)

I missed an 'on' in my sentence; should have read '...software running ON those 
ASIC's and FPGA's'  My apologies for the error, which completely changed 
the meaning of my statement.  

A perusal of Cisco's own documentation for one of their 'hardware' forwarding 
engines, the PXF used in the 10k edge services router and others, shows that 
even with the Toaster ASIC (looking at a pair right now on an older PRE1 for 
uBR10K) and its associated memory, you have something running its own software 
doing the work.  Cisco's own documentation describes PXF in these words: "Each 
of the coprocessors in a PXF network processor is an independent, 
high-performance processor, customized for packet processing. Each processor, 
called an Express Micro Controller (XMC), provides a sophisticated 
dual-instruction-issue execution unit, with a variety of special instructions 
designed to execute packet-processing tasks efficiently."  

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.

Now, if we're talking directed attacks at the control plane well, COPP 
exists for a reason in Cisco-land.  Tarpits and other techniques (too bad 
nVidia's ActiveArmor firewall inside their nForce chipset's NIC's is so 
broken), including transparent layer 2 stateful inspection firewalling (easily 
doable with Linux iptables and bridging), can do the same for a single-core 
router.  

Now to, as Emeril would say, kick it up a notch, you're going to have a very 
hard time DoS'ing twenty-four Phenom II cores (four sockets, six cores per 
socket), though (which will likely set you back less than a midrange Cisco 
router).  I could see Vyatta on 24 Phenom II cores having blistering and nearly 
DoS-proof performance, for about what accelerated forwarding platforms cost.  
When the developers of software forwarding engines figure out how to leverage 
vector processing (SSE and similar, as well as nVidia's CUDA) to do packet 
forwarding, we're going to see commodity OS network routing performance hit 
another level. 

But specialized network processors don't always guarantee the great scalability 
that can be obtained with the technique.  Catalyst 8540 anyone? (I have 
several, and use a few in production; great boxes for raw IPv4 routing, but not 
at the edge, although in theory they should have been DoS-proof, since they're 
already switching worst-case packet sizes on the shared memory fabric at wire 
speed; their control plane was their weakest link).

Dedicated network coprocessors can be a good thing, but they're still 
software-based (even in the Catalyst 8540's case).

Re: Vyatta as a BRAS

2010-07-13 Thread Franck Martin

I think the issue, is that don't expect to build your own router using 
linux/bsd etc..

There are too many kernel parameters to tweak to make it optimal (unless a 
suboptimal router is ok with your environment)

You need people that understand network and the appliance they sell you.

Why Cisco is reliable (and expensive), because they give you that experience... 
Software based router can give you that experience if they are backed by a team 
that know what they are doing.

- Original Message -
From: "Robert Bays" 
To: nanog@nanog.org
Sent: Wednesday, 14 July, 2010 10:08:30 AM
Subject: Re: Vyatta as a BRAS

On 7/13/10 10:56 AM, Dobbins, Roland wrote:
> 
> On Jul 14, 2010, at 12:39 AM, 
>  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.

Re: Vyatta as a BRAS

2010-07-13 Thread Robert Bays

On 7/13/10 10:56 AM, Dobbins, Roland wrote:
> 
> On Jul 14, 2010, at 12:39 AM, 
>  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.

Re: Vyatta as a BRAS

2010-07-13 Thread David Barak

--- On Tue, 7/13/10, valdis.kletni...@vt.edu  wrote:

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

No weasel words necessary.

I won't speak for the M20, but I've always thought of the 7206 as a 
software-routing platform - it's a pretty good swiss-army-knife software router 
which supports limited hardware acceleration of specific functions.  Is there 
anyone who considers the 7206 a "hardware" router?

David Barak
Need Geek Rock?  Try The Franchise: 
http://www.listentothefranchise.com

Re: Vyatta as a BRAS

On Tuesday, July 13, 2010 03:02:21 pm khatfi...@socllc.net wrote:
>  In that case you are entirely accurate. If you were to use Vyatta 
> (linux-based) systems for this then you would likely need additional 
> infrastructure to firewall or zone it to ensure it can't be hit directly.

Much like COPP for the Sup720 control plane, no?  Tarpit is your friend.

Re: Vyatta as a BRAS

2010-07-13 Thread Valdis . Kletnieks

On Tue, 13 Jul 2010 18:11:45 -, "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..)



pgpde06Rw2gGg.pgp
Description: PGP signature

Re: Vyatta as a BRAS

2010-07-13 Thread Tony Li

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

Re: Vyatta as a BRAS

2010-07-13 Thread Nick Hilliard

On 13/07/2010 16:07, Curtis Maurand wrote:
> On 7/13/2010 4:53 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.
>>
>> 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.
>>
> 
> They are all software based, no matter who builds them.  Cisco IOS,
> Juniper JunOS, etc.

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

Depending on your configuration, this may or may not be important to your
IP connectivity requirements.  For many - if not most - companies, it is.

Nick

Re: Vyatta as a BRAS

 In that case you are entirely accurate. If you were to use Vyatta 
(linux-based) systems for this then you would likely need additional 
infrastructure to firewall or zone it to ensure it can't be hit directly.

Depending on what all it has running and the configuration it could be 
firewalled off locally but you're right it wouldn't withstand like 
'hardware-accelerated' as stated before.

Sorry for the confusion :)

--Original Message--
From: Dobbins, Roland
To: NANOG list
Subject: Re: Vyatta as a BRAS
Sent: Jul 13, 2010 1:37 PM


On Jul 14, 2010, at 1:29 AM,  wrote:

> We were talking about routing though.

I was talking about packeting the boxes directly, apologies for being unclear - 
that's what I meant when I said that the era of software-based edge boxes is 
long past.

---
Roland Dobbins  // <http://www.arbornetworks.com>

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

-- H.L. Mencken

Re: Vyatta as a BRAS


On Jul 14, 2010, at 1:29 AM,  wrote:

> We were talking about routing though.

I was talking about packeting the boxes directly, apologies for being unclear - 
that's what I meant when I said that the era of software-based edge boxes is 
long past.

---
Roland Dobbins  // 

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

-- H.L. Mencken

Re: Vyatta as a BRAS

Routing.

We can route that. If it were targeting the box itself it would depend if the 
attack were getting through. 

Certainly iptables can't handle something like that but pf does well with high 
PPS rates. If it were all 'DROP' traffic then likely higher. If it were hitting 
the box directly and getting past the firewall, yes it would be substantially 
lower.

We were talking about routing though.
--Original Message--
From: Dobbins, Roland
To: NANOG list
Subject: Re: Vyatta as a BRAS
Sent: Jul 13, 2010 12:56 PM

On Jul 14, 2010, at 12:39 AM,   
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.

---
Roland Dobbins  // <http://www.arbornetworks.com>

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

-- H.L. Mencken

Re: Vyatta as a BRAS

On Jul 14, 2010, at 1:02 AM, Matthew Kaufman wrote:

> Dangerous in places where forwarding table 
> exceeds hardware cache limits. (See Code Red worm stories)

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.

---
Roland Dobbins  // 

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

-- H.L. Mencken

Re: Vyatta as a BRAS

2010-07-13 Thread Matthew Kaufman


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

Re: Vyatta as a BRAS

On Jul 14, 2010, at 12:31 AM, Scott Weeks wrote:

> I'm guessing "a few kpps of packets" is tounge-in-cheek?  Entry level script 
> kiddies can get to a few hundred kpps easily.

That's what I meant - even a very small botnet can easily overwhelm 
software-based edge routers.

---
Roland Dobbins  // 

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

-- H.L. Mencken

Re: Vyatta as a BRAS

On Jul 14, 2010, at 12:39 AM,   
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.

---
Roland Dobbins  // 

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

-- H.L. Mencken

Re: Vyatta as a BRAS

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" 
Date: Tue, 13 Jul 2010 16:15:18 
To: NANOG list
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  // <http://www.arbornetworks.com>

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

-- H.L. Mencken

Re: Vyatta as a BRAS

2010-07-13 Thread Scott Weeks



--- rdobb...@arbor.net wrote:
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.
---


I'm guessing "a few kpps of packets" is tounge-in-cheek?  Entry level script 
kiddies can get to a few hundred kpps easily.

scott

Re: Vyatta as a BRAS

2010-07-13 Thread Valdis . Kletnieks

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?



pgpZRV93nKbv1.pgp
Description: PGP signature

Re: Vyatta as a BRAS

2010-07-13 Thread Christian Chapman

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)

- Original Message - 
From: "Lamar Owen" 

To: 
Sent: Tuesday, July 13, 2010 10:25 PM
Subject: Re: Vyatta as a BRAS

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.

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  // 

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

-- H.L. Mencken

Re: Vyatta as a BRAS

2010-07-13 Thread Joe Greco

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

Re: Vyatta as a BRAS

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?

Re: Vyatta as a BRAS

2010-07-13 Thread Curtis Maurand


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

Re: Vyatta as a BRAS

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.

Re: Vyatta as a BRAS

2010-07-13 Thread Daniel Senie

On Jul 13, 2010, at 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.  

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.

Re: Vyatta as a BRAS

2010-07-13 Thread Greg Whynott

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

controlling hardware asic's and fpga's.  

-g

Re: Vyatta as a BRAS

2010-07-13 Thread Curtis Maurand


On 7/13/2010 4:53 AM, Dobbins, Roland wrote:

On Jul 13, 2010, at 3:00 PM,  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.
   


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


--Curtis

Re: Vyatta as a BRAS

2010-07-13 Thread Curtis Maurand


On 7/13/2010 2:56 AM, Truman Boyes wrote:

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  //

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

-- H.L. Mencken
 

  A low cost 7200 or ERX-310 would easily fit the bill, and you can buy them 
cheap these days.

   

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

Re: Vyatta as a BRAS

On Jul 13, 2010, at 3:00 PM,  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  // 

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

-- H.L. Mencken

Re: Vyatta as a BRAS