Tuesday, May 20, 2008

It's all about ASICs, right?

Every so often, Vyatta gets queries from potential users asking about Vyatta technology. One of those came in to our info-line this morning, and it's a frequently-asked-question, so I answered it with a lengthy reply and I'm going to post the question and answer here as well.

Fundamentally, the question is about the special mojo that Cisco must put into its products, right?

I’ve worked with almost all OS’s you can find and most devices as well.

I’ve read the articles on the OpenSource vs. Cisco, and to be honest I’ve known for a while now that most linux/unix os’s with some tweaking can do the same as most Cisco routers/switches.

But I also know that a lot of development not only goes into the os(source) of the devices, but also the device hardware which is specifically developed for routing/switching.

I would like to know will normal proprietary over the counter hardware match up to the Cisco device hardware?


Here's my lengthy answer. I might have given Brandon more than he was looking for, but I figured it would pay dividends if I also blogged it.


The answer to your question is complex, but let me take a shot at breaking it down. Apologies for the long response, but there simply isn't a quick answer to your question.

The simple answer is that it depends highly on which market segment you're looking at.

First, let's separate switches and other appliances (routers, firewalls, etc.). All switches are ASIC-based and are definitely tuned to process packets as quickly as possible. On the other hand, they don't really do much processing other than basic forwarding and possibly some queuing for QoS. The ASICs are tuned for the forwarding task but they can't do much else, and there is typically only a small, embedded processor handling the management interface. It's incapable of doing a lot of heavy-lifting. The operating system in a switch has little to nothing to do with its performance because it's just running the management interface. In spite of that, many switches run on a standard operating system. For instance, Extreme Networks switches run Linux. So, to sum this up, you aren't going to terminate a VPN on your switch, but if you want 48-ports of cost-effective, wire-speed Gigabit Ethernet forwarding performance, switches are just the thing.

Now, let's take a look at appliances. Many of the appliances that are out on the market are based on standard operating systems (Linux or FreeBSD) under the hood, and many are implemented using standard PC hardware. For instance, Fortinet UTM boxes, Juniper J-Series routers, and Riverbed WAN optimization boxes are all based on PCs. Fortinet runs Linux under the hood. Juniper's JunOS is based on FreeBSD. Riverbed uses Linux.

Cisco's IOS is based on a custom, embedded OS because Linux didn't exist back when it was first created and the Unix systems of the day were too resource hungry for the cost structure that they wanted to achieve. While Cisco's low-end hardware is not based on PC platforms, it is not based on much specialized hardware. The ISR series uses a chip from SiByte that contains 4x MIPS architecture cores. So even the ISR is really a software-based device. Further, these cores are underpowered today and are not as fast as off-the-shelf processors. If Cisco were to start over, with a clean slate, I think they would probably make completely different architectural choices. In fact, they are moving this direction, slowly. The recently announced Cisco ASR, while it uses custom silicon, runs IOS on Linux. When Juniper had the chance to start from a clean slate, they chose FreeBSD as the foundation for JunOS and used x86 chips as the CPU for all the Juniper route processor modules.

Now, what you say is definitely true in the high-end of the networking market. Cisco's CRS-1 and Juniper's M and T series routers all use ASICs to perform high-speed forwarding. In this sense, they are more like switches. As with switches, they are very fast, but the processing they perform is not very rich. That's okay for where they sit in the network. The core of the Internet needs to be fast; it doesn't need to be terminating VPNs, doing load balancing, or executing IDS code.

Other parts of the network are different (say the branch office, the edge of service provider networks, or in data centers in front of individual applications), which is why you find many of the appliances that sit there running on Linux/BSD on x86 processors.

So, to summarize, switches are definitely ASIC-based and the operating system has nothing to do with their performance. Some switches (Extreme), even run Linux. In the high-end of the routing space (Cisco GSR and CRS-1; Juniper M and T series), the insides are more like a switch than a router. Like a switch, the forwarding is all handled by ASICs. Still, JunOS is based on FreeBSD. Finally, in the mid-range of the appliance market (routers, firewalls, VPNs, load balancers, etc.), many devices are implemented using standard operating systems running on x86. This is the market place that Vyatta is addressing with our products.

Finally, I'd point out that even if it was true that Cisco's ISR family was implemented using special ASICs and secret networking mojo, the results speak for themselves. The fact is, Vyatta has outperformed the Cisco ISR and 7200 with standard Intel processors at a fraction of the cost. If those Cisco products were using ASICs, that evidentally didn't matter very much in the final analysis. All the custom silicon and engineering did was raise the costs to develop those products, costs that were then passed on to customers. You can find those test results in the Tolly reports here: http://www.vyatta.com/documentation/whitepapers.php


-- Dave

So there you have it. The fact is, whether something is ASIC-based or not should be irrelevant to a consumer. The only thing we should care about is the price/performance of a device in our network and whether it can do the job we need it to do. It could be powered by ASICs, general purpose processors running software, or hamsters running on a wheel, as long as it works.

Maybe the ASIC/networking-mojo myth is a mental crutch. If $8000 of server hardware and Vyatta software can outperform a $35,000 Cisco router, where's the secret mojo that you're supposedly paying for? And if it doesn't exist, why should you pay for it? If you're committed to buying overpriced systems, maybe you need to believe there is something magical about them to justify it to yourself.

Monday, May 19, 2008

Cisco rootkit

Network World has a nice story today about a researcher who has created a rootkit for Cisco gear. I bring this to your attention, not because I want to criticize Cisco for having security issues, but rather because so many people think that if they just buy Cisco they are safe from this sort of thing. Nothing could be further from the truth!

The myth goes something like this:

  1. Everybody has bugs and therefore has the potential for security flaws.
  2. Because my proprietary vendor keeps its source code closed, however, the bad guys can't see that code and are thus hampered in developing exploits.
  3. My proprietary vendor keeps me safe by employing a large security team to constantly monitor its own development and fix any flaws that it uncovers.
  4. If my proprietary vendor uncovers a security flaw, they will use their vast resources to inform me of that flaw with instructions as to what I should do to deal with the problem.

The first statement in that list is true. The rest are all false. The facts are:

  • The bad guys already have Cisco's code. The reality here is that no code of any worth can be kept absolutely private. There are too many people at Cisco who have access to that code to keep it safe for long. Ditto with Juniper, Nortel, or anybody else. The same things have happened in the past to Microsoft. If your network security plan relies on the bad guys not having the code, it is fundamentally flawed.
  • It's great to have a security team that is monitoring your own products for flaws, but it's better to have a large community that is monitoring your products for flaws. At a certain level, you have to question the conflict-of-interest of an internal security team. Are they really incentivized to release information about potential exploits? How quickly? If security is in conflict with other internal priorities, what wins? We have seen lots of vendors sit on critical bugs for months after they have been discovered and communicated to them.
  • Finally, what happens when flaws are discovered? In Cisco's case, it sued a researcher trying to warn the world of potential security problems. Is your vendor really being forthcoming about issues, or are they trying to silence reasonable, serious discussions about security problems?

I have said it before and I'll say it again: There are two types of companies, those that have security issues and those that are lying. Open source tends to handle the exploits better (not perfectly!) when they occur by providing reliable information rapidly to the people who are in the best position to make use of that information.

Many people believe that security is increased when there is a free flow of information about systems. As the source code thefts make clear, you have to assume that the bad guys have the code. If the bad guys are left to work by themselves in a secret back room, trying to discover remote exploits, they will find them. Your only chance to stay ahead of that is to give the good guys all the information they need to find the exploits first. That can only be done when there is free access to the code.

Is a Cisco rootkit surprising? No, not if you have an accurate view of the world. It's only surprising if you were buying into the myth that your proprietary vendor was immune to that sort of thing. Is a Cisco rootkit necessarily a big problem? Again, no, because if you had an accurate view of the world you always knew something like this could be done and you'd be trying to make sure your systems were secure from the start.

Could somebody develop a Vyatta rootkit? Sure. The difference is that we'll tell you that's a possibility up front and we won't act surprised when it happens. In fact, given that Vyatta is based on Linux and there are many Linux rootkits floating around the ether, it's likely that one could be easily adapted to work with a Vyatta system. That's all the more reason to dispense with any other security myths you may be holding on to and get down to securing your systems.