Re: Vyatta as a BRAS
If there is sufficient CPU power (and I/O to the CPU) as compared to the bandwidth, then this is doable. Tony On Jul 19, 2010, at 11:40 PM, Akyol, Bora A wrote: Except that the goal you set below is very very hard to do on a software router unless its CPU has packet classification properties implemented in HW. In some systems, just the act of receiving the packet in the ISR and classifying it into a bucket is enough to overwhelm the system without proper hardware assist. Bora -Original Message- From: Mark Smith [mailto:na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org] Sent: Monday, July 19, 2010 2:39 AM To: Tim Durack Cc: NANOG list Subject: Re: Vyatta as a BRAS And that's the crux of the issue. Can the box survive if line rate maximum PPS is being aimed at it, either for forwarding or at the control plane? If the answer is yes, then whether it is a software router or hardware router is academic.
Re: Vyatta as a BRAS
On Monday, July 19, 2010 05:40:07 pm Akyol, Bora A wrote: Except that the goal you set below is very very hard to do on a software router unless its CPU has packet classification properties implemented in HW. And then there are Systems on a Chip (SoC) like the Realtek 8650 that really take it to another level. See http://www.csie.nctu.edu.tw/~cfliu/work/8650.htm for more information; by most definitions here this would be a SoC 'hardware' router. It's in many very low cost SoHo devices, such as NetGear FVS114.
Re: Vyatta as a BRAS
On Sun, 18 Jul 2010 21:07:36 -0400 Tim Durack tdur...@gmail.com wrote: On Sun, Jul 18, 2010 at 8:01 PM, Brett Frankenberger rbf+na...@panix.com wrote: On Mon, Jul 19, 2010 at 07:13:46AM +0930, Mark Smith wrote: 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. The code running in the ASICs on line cards in 6500-series chassis isn't fixed at the factory. Same with the code running on the PFCs in those boxes. There's not a tremendous amount of flexibility to make changes after the fact, because the code is so tightly integrated with the hardware, but there is some. (Not saying the 6500 is a software-based platform. It's pretty clearly a hardware-based platform under most peoples' definition. But: the line is blurry.) -- Brett Surely the important point for most forwarding engines is that there is isolation between control, management and forwarding planes? If I'm looking for a box, I want line rate forwarding on all interfaces. I want stateless ACLs and policing functions on the forwarding plane. I want to use those functions to protect the control and management planes. I want the control plane to cope with the required amount of forwarding state and churn. I want the management plane to be somewhat as capable as the Linux tools I run to maintain the network. And that's the crux of the issue. Can the box survive if line rate maximum PPS is being aimed at it, either for forwarding or at the control plane? If the answer is yes, then whether it is a software router or hardware router is academic. I don't honestly care whether it is a single cpu, multi-core multi-cpu, ASIC or NPU. That being said, for the networks I help maintain, the C6K meets most of those requirements. I think the N7K is movement in the right direction. I consider both to be L2/L3 switches :-) -- Tim:
RE: Vyatta as a BRAS
Except that the goal you set below is very very hard to do on a software router unless its CPU has packet classification properties implemented in HW. In some systems, just the act of receiving the packet in the ISR and classifying it into a bucket is enough to overwhelm the system without proper hardware assist. Bora -Original Message- From: Mark Smith [mailto:na...@85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org] Sent: Monday, July 19, 2010 2:39 AM To: Tim Durack Cc: NANOG list Subject: Re: Vyatta as a BRAS And that's the crux of the issue. Can the box survive if line rate maximum PPS is being aimed at it, either for forwarding or at the control plane? If the answer is yes, then whether it is a software router or hardware router is academic.
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 rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: Vyatta as a BRAS
On 18 Jul 2010, at 10:58, Dobbins, Roland rdobb...@arbor.net 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 Sun, Jul 18, 2010 at 06:12:29PM +0100, Nick Hilliard wrote: On 18 Jul 2010, at 10:58, Dobbins, Roland rdobb...@arbor.net 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
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 rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
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 rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: Vyatta as a BRAS
On Sun, 18 Jul 2010 18:12:29 +0100 Nick Hilliard n...@foobar.org wrote: On 18 Jul 2010, at 10:58, Dobbins, Roland rdobb...@arbor.net 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 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 rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: Vyatta as a BRAS
On Mon, Jul 19, 2010 at 07:13:46AM +0930, Mark Smith wrote: 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. The code running in the ASICs on line cards in 6500-series chassis isn't fixed at the factory. Same with the code running on the PFCs in those boxes. There's not a tremendous amount of flexibility to make changes after the fact, because the code is so tightly integrated with the hardware, but there is some. (Not saying the 6500 is a software-based platform. It's pretty clearly a hardware-based platform under most peoples' definition. But: the line is blurry.) -- Brett
Re: Vyatta as a BRAS
On Sun, Jul 18, 2010 at 8:01 PM, Brett Frankenberger rbf+na...@panix.com wrote: On Mon, Jul 19, 2010 at 07:13:46AM +0930, Mark Smith wrote: 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. The code running in the ASICs on line cards in 6500-series chassis isn't fixed at the factory. Same with the code running on the PFCs in those boxes. There's not a tremendous amount of flexibility to make changes after the fact, because the code is so tightly integrated with the hardware, but there is some. (Not saying the 6500 is a software-based platform. It's pretty clearly a hardware-based platform under most peoples' definition. But: the line is blurry.) -- Brett Surely the important point for most forwarding engines is that there is isolation between control, management and forwarding planes? If I'm looking for a box, I want line rate forwarding on all interfaces. I want stateless ACLs and policing functions on the forwarding plane. I want to use those functions to protect the control and management planes. I want the control plane to cope with the required amount of forwarding state and churn. I want the management plane to be somewhat as capable as the Linux tools I run to maintain the network. I don't honestly care whether it is a single cpu, multi-core multi-cpu, ASIC or NPU. That being said, for the networks I help maintain, the C6K meets most of those requirements. I think the N7K is movement in the right direction. I consider both to be L2/L3 switches :-) -- Tim:
Re: Vyatta as a BRAS
On Wed, 14 Jul 2010 14:12:07 + Dobbins, Roland rdobb...@arbor.net 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 fair bit of weight on flexibility, because I can't tell
Re: Vyatta as a BRAS
On Thu, 15 Jul 2010 20:57:15 PDT, Henry Linneweh said: Your definitions seem to be rather ATM-specific, which may be a bit of a problem in a world dominated by Ethernet... Can we get a consensus definition on these definition's and what hardware vender's make edge routers and what hardware vender's make core routers. I got a router, it's got 5-6 10GE interfaces talking to other routers on my network backbone, and a bunch of 10GE links to end-user-facing aggregation switches. Since it's only forwarding inside my network, it's a core router by your definition. I now turn up an identical hardware 10GE link - connected to Level3. I just became an edge router by your definition since I'm talking to another network. (I know, I probably don't want to do that - but I *could*, maybe even without a full BGP feed if the routing situation allows. The point is the definition is busticated). Adding to the confusion is the fact that the edge routers of some large providers need more capacity than the core routers of smaller organizations Maybe we need to ditch the terms edge and core, and instead talk about: 1/4 plastic tubing - http://www.waterfiltermart.com/images/products/preview/plastic_tubing_and_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. :) pgp7S3BXcEYfv.pgp Description: PGP signature
Re: Vyatta as a BRAS
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
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
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
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
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
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 rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: Vyatta as a BRAS
On Thu, Jul 15, 2010 at 11:35 AM, Dobbins, Roland rdobb...@arbor.net wrote: On Jul 15, 2010, at 10:23 PM, Joe Greco wrote: For example, for a provider whose entire upstream capacity is 1Gbps, I have a hard time seeing how a Linux- or FreeBSD-based box could credibly be claimed not to be a suitable edge router. Because it can and will be whacked quite easily by anyone who packets it, either deliberately or inadvertently. I've seen too many software-based routers fall over with far, far less traffic than 1gb/sec to think otherwise. Since you've seen many software-based routers fall over, can you provide details on specific hardware/software/traffic patterns/rates where you've seen these failures? From what I can tell, software based routers are almost universally used in SOHO environments; so it would be nice to know when such solutions are no longer viable in your experience. Thanks, Bill Bogstad
Re: Vyatta as a BRAS
On Thu, Jul 15, 2010 at 11:54:39AM -0400, Bill Bogstad wrote: On Thu, Jul 15, 2010 at 11:35 AM, Dobbins, Roland rdobb...@arbor.net wrote: On Jul 15, 2010, at 10:23 PM, Joe Greco wrote: For example, for a provider whose entire upstream capacity is 1Gbps, I have a hard time seeing how a Linux- or FreeBSD-based box could credibly be claimed not to be a suitable edge router. Because it can and will be whacked quite easily by anyone who packets it, either deliberately or inadvertently. I've seen too many software-based routers fall over with far, far less traffic than 1gb/sec to think otherwise. Since you've seen many software-based routers fall over, can you provide details on specific hardware/software/traffic patterns/rates where you've seen these failures? From what I can tell, software based routers are almost universally used in SOHO environments; so it would be nice to know when such solutions are no longer viable in your experience. 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
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 rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
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 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: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 rdobb...@arbor.net // http://www.arbornetworks.com 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)
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 rdobb...@arbor.net // http://www.arbornetworks.com 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
A question for the house and the moderators (was Re: Vyatta as a BRAS)
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
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 rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
RE: Vyatta as a BRAS
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. 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
Re: Vyatta as a BRAS
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
On Thu, Jul 15, 2010 at 1:22 PM, Dennis Burgess dmburg...@linktechs.net wrote: RouterOS is a software based router, we have them all over the world as CORE and EDGE routers to networks. You keep using that word (CORE). I do not think it means what you think it means. Drive Slow, DoS Slower, Paul Wall
Re: Vyatta as a BRAS
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 pauldotw...@gmail.com wrote: On Thu, Jul 15, 2010 at 1:22 PM, Dennis Burgess dmburg...@linktechs.net wrote: RouterOS is a software based router, we have them all over the world as CORE and EDGE routers to networks. You keep using that word (CORE). I do not think it means what you think it means. Drive Slow, DoS Slower, Paul Wall
Re: Vyatta as a BRAS
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 pauldotw...@gmail.com To: Dennis Burgess dmburg...@linktechs.net 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 dmburg...@linktechs.net wrote: RouterOS is a software based router, we have them all over the world as CORE and EDGE routers to networks. You keep using that word (CORE). I do not think it means what you think it means. Drive Slow, DoS Slower, Paul Wall
Re: Vyatta as a BRAS
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 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 rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: Vyatta as a BRAS
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 7:01 PM, valdis.kletni...@vt.edu valdis.kletni...@vt.edu 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 http://www.cisco.com/en/US/prod/collateral/routers/ps341/product_data_sheet0900aecd8047177b.html: '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 http://www.cisco.com/en/US/prod/collateral/routers/ps10538/qa_c67_553891_ps10536_Products_Q_and_A_Item.html 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 rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: Vyatta as a BRAS
* 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 Weimerfwei...@bfk.de 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 rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: Vyatta as a BRAS
* 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 Weimerfwei...@bfk.de 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 rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: Vyatta as a BRAS
* 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 Weimerfwei...@bfk.de 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: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 rdobb...@arbor.net // 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 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 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 rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: Vyatta as a BRAS
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 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
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
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
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 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 Dobbinsrdobb...@arbor.net //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 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
- Original Message - From: Joe Greco jgr...@ns.sol.net To: Dobbins, Roland rdobb...@arbor.net Cc: NANOG list nanog@nanog.org 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
Vyatta as a BRAS
Have anyone tried Vyatta router instead of a Cisco 7200 as BRAS for adsl customers? If so, what model? do you recommend it? BR Sharef
Re: Vyatta as a BRAS
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 rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: Vyatta as a BRAS
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 rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken I agree. In a bind I have seen small providers experiment with FreeBSD/Linux L2TP termination (as a LNS), I would recommend against it if you have a business that depends upon these customers' happiness. There were all sorts of issues to address when the customer ran significant traffic forwarding through the unix boxes, namely adjusting kernel parameters for NMB_CLUSTERS, heap sizes, all sorts of sysctl parameters, adding additional interface counts, etc. A low cost 7200 or ERX-310 would easily fit the bill, and you can buy them cheap these days. Cheers, Truman
Re: Vyatta as a BRAS
My comment would be: That is simply matter of opinion and opinions may be swayed depending on the market that signs your check? :) There have been a fair share of appliance bugs/sec vulnerabilities over the years as well. I agree software-based deployments have their flaws but I do not agree that it cannot be managed securely with comparable or exceeding uptime -vs- a drop in appliance. I firmly believe it has it's place in 'today's internet'. The question is where your expertise lies and what you expect to get out of it. If your background is Cisco and you have a good relationship then I wouldn't fix what isn't broken. I have very little experience with Vyatta other than doing some mild testing. I am simply speaking more to the 'software-based' market like Vyatta/BSD. -Original Message- From: Truman Boyes tru...@suspicious.org Date: Tue, 13 Jul 2010 16:56:16 To: Dobbins, Rolandrdobb...@arbor.net Cc: NANOG listnanog@nanog.org Subject: Re: Vyatta as a BRAS 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 rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken I agree. In a bind I have seen small providers experiment with FreeBSD/Linux L2TP termination (as a LNS), I would recommend against it if you have a business that depends upon these customers' happiness. There were all sorts of issues to address when the customer ran significant traffic forwarding through the unix boxes, namely adjusting kernel parameters for NMB_CLUSTERS, heap sizes, all sorts of sysctl parameters, adding additional interface counts, etc. A low cost 7200 or ERX-310 would easily fit the bill, and you can buy them cheap these days. Cheers, Truman
Re: Vyatta as a BRAS
On Jul 13, 2010, at 3:00 PM, khatfi...@socllc.net wrote: I agree software-based deployments have their flaws but I do not agree that it cannot be managed securely with comparable or exceeding uptime -vs- a drop in appliance. I firmly believe it has it's place in 'today's internet'. When a single botted/misbehaving host easily can take down a software-based BRAS, that's a pretty strong indication that software-based edge devices are contraindicated, heh. Software-based edge devices have been obsolete for a long time, now. They're a great risk to operators who've yet to replace them with hardware-based devices. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: Vyatta as a BRAS
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 Dobbinsrdobb...@arbor.net //http://www.arbornetworks.com 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 7/13/2010 4:53 AM, Dobbins, Roland wrote: On Jul 13, 2010, at 3:00 PM,khatfi...@socllc.net wrote: I agree software-based deployments have their flaws but I do not agree that it cannot be managed securely with comparable or exceeding uptime -vs- a drop in appliance. I firmly believe it has it's place in 'today's internet'. When a single botted/misbehaving host easily can take down a software-based BRAS, that's a pretty strong indication that software-based edge devices are contraindicated, heh. Software-based edge devices have been obsolete for a long time, now. They're a great risk to operators who've yet to replace them with hardware-based devices. They are all software based, no matter who builds them. Cisco IOS, Juniper JunOS, etc. --Curtis
Re: Vyatta as a BRAS
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
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
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 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 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
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 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 rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: Vyatta as a BRAS
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 lo...@pari.edu To: nanog@nanog.org 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 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
--- 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
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 rdobb...@arbor.net Date: Tue, 13 Jul 2010 16:15:18 To: NANOG listnanog@nanog.org Subject: Re: Vyatta as a BRAS On Jul 13, 2010, at 10:58 PM, Joe Greco wrote: It's interesting. One can get equally militant and say that hardware based routers are irrelevant in many applications. When BCPs are followed, they don't tend to fall over the moment someone hits them with a few kpps of packets - which should be a key criteria for an edge device. The same can't be said of software-based devices. If maintaining availability is important, then hardware-based (semantic hairsplitting aside) devices are a requirement. --- Roland Dobbins rdobb...@arbor.net // 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 12:39 AM, khatfi...@socllc.net khatfi...@socllc.net wrote: I haven't done real world testing with Vyatta but we consistently pass 750KPPS+ without the slightest hiccup on our FreeBSD routing systems. 750kpps packeting the box itself? Also, note that kpps is a small amount of traffic, compared to what even very small botnets can dish out. --- Roland Dobbins rdobb...@arbor.net // 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 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 rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: Vyatta as a BRAS
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 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 rdobb...@arbor.net // http://www.arbornetworks.com 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, khatfi...@socllc.net khatfi...@socllc.net wrote: I haven't done real world testing with Vyatta but we consistently pass 750KPPS+ without the slightest hiccup on our FreeBSD routing systems. 750kpps packeting the box itself? Also, note that kpps is a small amount of traffic, compared to what even very small botnets can dish out. --- Roland Dobbins rdobb...@arbor.net // 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, khatfi...@socllc.net 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 rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
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, khatfi...@socllc.net 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 rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: Vyatta as a BRAS
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
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
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
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
--- On Tue, 7/13/10, valdis.kletni...@vt.edu 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 7/13/10 10:56 AM, Dobbins, Roland wrote: On Jul 14, 2010, at 12:39 AM, khatfi...@socllc.net khatfi...@socllc.net wrote: I haven't done real world testing with Vyatta but we consistently pass 750KPPS+ without the slightest hiccup on our FreeBSD routing systems. 750kpps packeting the box itself? Also, note that kpps is a small amount of traffic, compared to what even very small botnets can dish out. I work for Vyatta. We regularly see 700+kpps per core using a Nehalem class cpu with higher rates possible in tuned systems. On a multi-core system this translates to a fairly high level of throughput. To echo an earlier post, Linux can comfortably handle gigabit. It wasn't too long ago that this wasn't the case. The growth in the number of cores available to the end user, the introduction of multi-queue nics, the move away from the FSB architecture towards QPI, ever faster PCIe... The technology is directionally trending towards faster, more consistent network throughputs whether your Linux host is acting as a router, firewall, web server, or whatever. There are activities taking place on the software front as well to increase speed and consistency in the realms of forwarding and firewall, including technologies that separate the control and forwarding planes. There is still headroom available in commodity compute to scale further. I will be the first to admit that Vyatta won't work for everyone. We still have a lot of work to do for our system to fit seamlessly in some environments. But, the bet that we have made is that commodity compute coupled with the amazing OSS dev community can keep pace with a good portion of the networking worlds needs. So far, that bet looks like a good one. To discount all software routing running on general purpose processors as being antiquated seems to me to be premature, especially given the various vendors interests as more functionality migrates into the cloud. As that happens commodity components in the cloud fabric will necessarily need to behave more like network appliances. Cheers, Robert.
Re: Vyatta as a BRAS
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 rob...@gdk.org 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, khatfi...@socllc.net khatfi...@socllc.net wrote: I haven't done real world testing with Vyatta but we consistently pass 750KPPS+ without the slightest hiccup on our FreeBSD routing systems. 750kpps packeting the box itself? Also, note that kpps is a small amount of traffic, compared to what even very small botnets can dish out. I work for Vyatta. We regularly see 700+kpps per core using a Nehalem class cpu with higher rates possible in tuned systems. On a multi-core system this translates to a fairly high level of throughput. To echo an earlier post, Linux can comfortably handle gigabit. It wasn't too long ago that this wasn't the case. The growth in the number of cores available to the end user, the introduction of multi-queue nics, the move away from the FSB architecture towards QPI, ever faster PCIe... The technology is directionally trending towards faster, more consistent network throughputs whether your Linux host is acting as a router, firewall, web server, or whatever. There are activities taking place on the software front as well to increase speed and consistency in the realms of forwarding and firewall, including technologies that separate the control and forwarding planes. There is still headroom available in commodity compute to scale further. I will be the first to admit that Vyatta won't work for everyone. We still have a lot of work to do for our system to fit seamlessly in some environments. But, the bet that we have made is that commodity compute coupled with the amazing OSS dev community can keep pace with a good portion of the networking worlds needs. So far, that bet looks like a good one. To discount all software routing running on general purpose processors as being antiquated seems to me to be premature, especially given the various vendors interests as more functionality migrates into the cloud. As that happens commodity components in the cloud fabric will necessarily need to behave more like network appliances. Cheers, Robert.
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
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 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 rdobb...@arbor.net // 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 4:03 AM, valdis.kletni...@vt.edu wrote: I wasn't aware that the 7206 and M20 classified as software-based. 7200 certainly is - I'm not familiar with the minutiae of Juniper boxes, but I believe the M20 is hardware-based. In the classic report you cite, the issue with the M20 occurred due to lack of BCP implementation. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken
Re: Vyatta as a BRAS
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 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 rdobb...@arbor.net // 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 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 rdobb...@arbor.net // http://www.arbornetworks.com Injustice is relatively easy to bear; what stings is justice. -- H.L. Mencken