Peter Christy

Overview of Today’s Newsletter Topics

Cisco is a remarkably vibrant $40B company doing business in a challenging industry where product prices are rapidly commoditized. Networking equipment is highly standardized and there is no shortage of vendors that are happy to sell at a lower (than Cisco) price. Through this all Cisco continues to transform, evolve and delivery innovative products to the market. Today Cisco introduced the Nexus family of switches. In December Cisco introduced the TrustSec architecture, both of which we describe briefly here and cover more thoroughly in reports for our clients. Both are excellent and fascinating examples of what a vibrant company with dominating market share (Cisco probably prefers we don’t use that term but let’s call a spade a spade) can do even in such a constrained market space.

NEXUS -- Data Center Switching Redefined

   

Today Cisco announced the NEXUS switch family, a remarkable redefinition of data center switching. Over the last five years the data center has become more and more of an IT focus driven by these forces:

 

1. The increased deployment and use of shared, server-based applications and services,

2. The desire to improve IT cost efficiency (through consolidation),

3. The need to more carefully govern and control IT activities (regulatory compliance) and

4. The need to protect sensitive and private data.

The increased focus on the data center has in turn made it a fertile ground for innovation and yielded technology-enabled breakthroughs such as data center virtualization. As data center technologies and architectures evolved the network stood out as much as a limitation as an enabler in ways that seemed difficult to fix with just improved features.

From this perspective we can see that what Cisco has done with Nexus is an impressive systematic improvement to data center switching. Some of the elements we have seen before (what Cisco calls switch “virtualization” for example). We knew that Cisco was working with Nuova to improve Ethernet so that it could serve as a transport for fiber channel SAN protocols. We had already seen in the Catalyst offering how Cisco has evolved the product line for customer investment protection assuring that essentially all the components in the switch can be upgraded independently -- new control processors, new data backplane, and of course new line cards -- and that the old line cards had firmware flexibility to adapt to evolution in other parts of the switch. We knew that Cisco could and liked to do high-speed custom silicon (a great barrier to entry). NEXUS has all of that built into what is really a completely new network system for data center applications.

NEXUS represents a large and expensive product development effort for Cisco which we won’t try to describe in any real detail, but here are the key aspects:

1. Evolve switching so that Fiber Channel SAN traffic can use the same network fabric. NEXUS not only carries LAN and SAN traffic over the same switch but can use a single port for both. Converging these networks simplifies the data center infrastructure, reduces CapEX and OpEx and according to Cisco’s numbers saves an amazing amount of power when you consider the reduced number of server adaptors required.

2. Create a data center network architecture where all ports are equal and minimize the need for any physical network moves and changes or re-cabling while supporting the IT agility inherent in a virtualized data center (the ability to move applications between servers at will).

3. Reduce CapEx while providing very high availability. This is where the switch virtualization yields high returns by eliminating the need for “standby” devices and using them in the network fulltime.

4. Improve network availability by greatly improving the network re-convergence time after failure. Cisco makes heavy use of Level 2 coordination of the devices thereby avoiding the recovery delays that come with traditional spanning tree algorithms and also thereby flattening the topology toward the goals of having all ports equal for all tasks.

The net result over time is a data center network that is faster, more reliable and cheaper, hence what we think of a real step forward. Along the way the feeds and speeds improve a lot. Having enough backplane capacity to assure that the backplane is never the limitation was key to the integration of FC SAN traffic. The switch uses a new operating system derived from the SAN-OS used in the MDS 9000 SAN switching products. FC requires assured delivery which is quite different from traditional packet best effort delivery. Since a lot of the features required in WAN routing don’t need to be supported in the data center it made sense to move to an O/S platform with these key SAN primitives.

Cisco says that they set about rethinking data center switching when they began this effort quite a few years ago. Typically “rethinking” is added by the marketing people when a project is done but in this case we think it’s probably true. The kind of wholesale systematic redesign is something only Cisco can do in enterprise networking (remember they own 70%+ market share to their nearest competitors 7%). Most dominating companies get lethargic and spend more time resting on their laurels and improving the bottom line a little by constraining R&D spending. We’re delighted that Cisco is still driving progress so aggressively.

Cisco TrustSec Architecture

Cisco’s TrustSec architecture significantly advances the state-of-the-art in network-provided security. Security was much easier when the action was primarily at the enterprise headquarters. We had a “perimeter” model of security. If a user was inside the perimeter (local) then they were trusted. Access from outside the perimeter was not trusted. Life was very simple.

But over the last five years the perimeter has pretty much become useless as a means of judging or enforcing security. Most enterprise users are no longer within the headquarters network. Compliance, security and privacy issues require that we “distrust” internal users. Where the user is doesn’t particularly help, while at the same time securing applications and data is increasingly important. What should we do?

IRG has long believed that the right answer categorically is an evolution to “identity-based” networking where the identity of the user is the prime determinant, not just their network location, but how should this be implemented? Historically the prime means of defense were various forms of firewall rules typically keyed off of source and destination IP number (network location again) augmented by some understanding about the specific flow (the application related to the traffic). Firewall rules were at best complicated (at worst incomprehensible) especially considering that firewalls were typically located in the “middle” of the network where there was a lot work to be done because of the diversity of flows that transited the network at that part -- sorting out what all the traffic was and then looking for the rules that were specific to that traffic. The difficulty of the approach was compounded by the challenge of fully understanding how traffic flows in a network and assuring that there aren’t any unanticipated network sneak paths that bypass the security devices.

A set of vendors including Nevis, Consentry and Vernier attacked this problem by putting much more intelligence at the network ingress points (e.g., where users connected to the network), and then using the user’s identity to determine the specific rules governing what they could do on the network. The difficulty in this approach is that it requires use of a new class of access switches with a great deal of security functionality on each port.

Cisco TrustSec re-factors the problem very creatively. The architecture encompasses these ideas:

1. Make the enterprise network more trustable (increase the confidence about the data that has transited the network);

2. When traffic enters the network tag each packet with an identifier that signifies what is known about it and do so in a way that most directly reflects how that data can be trusted.

3. Filter the data on exit from the network (e.g., at the point the network connects to a server) by acting on the tags.

TrustSec represents a long and large investment for Cisco; we can’t describe the details adequately here and won’t try. But the 50,000 foot view is relatively simple. We make the network trustable by (a) authenticating network devices before we let them join the network -- the device equivalent of NAC for people. For example, we can check the device serial number, the revision level of the firmware, and assure that the signature of the firmware is authentic, and only authenticate the device if all those tests pass. Then (b) we encrypt the links between authenticated devices so that the data cannot be snooped and more importantly can’t be modified by some “man in the middle” attack. This encryption is done link-by-link using certificates receives as part of the authentication process.

With a trustable network in place we next annotate traffic as it enters the network with what we know about it from a security perspective. Because the network is trustable we can confidently act on that tagging when the data exits the network because we know it hasn’t been modified. To simplify the filtering at the egress point, TrustSec is designed so that the tags used for the data identify the trust category (Cisco uses the term role) so the filtering task is as simple as possible since there aren’t complex IP-number-based rules to evaluate later on. A server only has to understand what level of trusted data to pass.

Finally, in a TrustSec based implementation, we need a way of tagging the data on entry. Cisco has announced a new family of edge switches capable of doing this tagging at line rates (a much simpler task than the challenge Nevis and Consentry had of doing full traffic identification and firewalling at line rate). An evolved version of NAC is used to authenticate the user and identify the suitable trust class (role) to assign to that user’s traffic. Anticipating the fact that Cisco customers aren’t going to do a wholesale refresh of their edge switches to implement TrustSec, there is a form of implementation in which the tagging is done by a switch inward from the edge coordinated with edge implemented NAC via out-of-band control plane communication.

The net result of this is to greatly diminish the role of traditional firewalls for this kind of security while emphasizing NAC and data center switching all of which makes sense given Cisco’s market strength. So we give Cisco two thumbs up for TrustSec for significantly advancing the state of network-enforced security!

Cisco Reorganizes Engineering

We usually don't pay a lot of attention to Cisco organization changes as long as John Chambers is still in place at the top, but the recent engineering changes caught our eye. It starts with the Chief Development Officer -- Charlie Giancarlo -- leaving to join a Private Equity firm. The plot gets somewhat more interesting if you add in the fact that Chambers just hired Padmasree Warrior as CTO (she had been Motorola's quite visible CTO prior). Cisco's CTO role had been open since last held by Charlie, and not very visible since Judy Estrin left in 2000. Warrior will report directly to Chambers as will the engineering functions. The other interesting change is that Chambers has built a software group led by Don Proctor and including the other major software development organizations. From our perspective software is at the core of Cisco's future given the system nature of most of Cisco's strategic initiatives. We look forward to seeing what Proctor decides to do.

Bandwidth Schmandwidth

It's been one of those "good news, bad news" months for bandwidth. At the Cisco Analyst meeting Chambers and other all mentioned an IP Traffic Forecast that Cisco had assembled (and has made available on their Web site along with a companion piece). For those of us who have been frustrated trying to get any meaningful traffic data in the past this is a wonderful document that presents a coherent view of what's happening to IP traffic in the Internet (hint: it's growing!). On the other hand, Chambers got exuberant and suggested that in fact video usage could cause traffic to grow much faster citing Cisco's own internal network growth driven by their aggressive use of TelePresence and other video services. Always eager to steal keen insights on the future I tried to find the facts under the enthusiasm and came up short. It's a longer story than fits here but this is the Readers' Digest version. (1) Video On Demand is clearly a happening thing. (2) Unfortunately the evidence that exists suggests that what people will do with VoD is time shift the same stuff (it's not one of them mythical "long tail" things). In which case, (3) the video needs can be served with content caches of some form right near the point of consumption and all that bandwidth won't do much to drive network equipment spending. If any of you dear readers has a more compelling argument why video use will drive a lot of core Internet bandwidth please share it with me!

Evildoer Update

If you want to understand security you can't ignore the economics as Bruce Schneier likes to point out. If you take phishing for example you can't expect the consumer or their ISP to spend much on the problem -- it's the financial institutions with brand and reputation at risk that the have most to gain from anti-phishing and therefore the most to spend. Early on when most of the phishing discussions were on technical solutions we were delighted to talk to the Cyota team because they very much thought of themselves as a service organization to financial service companies that happened also to bring some interesting technology to bear. Cyota was acquired by RSA and we hadn't talked to them since until recently we had a chance to get an update on the state of the evildoer art. It's pretty chilling. If you think we're making a lot of progress getting cyber crime under control you probably need to think again. It's not that good work isn't being done by Cyota and others. The problem is that the "enemy" includes some very bright and highly motivated criminals. It makes you think that maybe the right answer is ripping out the phone line and putting duct tape over unused electric outlets to keep them at bay.

Forget the Money

Against our advice the AR team at Cisco has succeeded in neatly removing all discussion of business from the Industry Analysts meeting. Cisco used to speak to both financial and industry analysts in one meeting which I personally loved because it meant they had to be careful about both business and technical statements. Apparently most industry analysts disagreed with this position and didn't want to wade through the boring stuff about how Cisco actually makes money. Perhaps if you're an industry analyst that prepares reports only for end users that's a reasonable perspective. Why should a buyer care how Cisco actually makes money if the product and price are right? But why any vendor should listen to the advice of someone who isn't interested in the money part is frankly a mystery to me although it must simplify the process of making Magic Quadrants enormously. So don't ask us for advice if you don't care about the money stuff either.