Rational Survivability

Cisco Is NOT Getting Into the Server Business...

Yes, yes. We've talked about this before here. Cisco is introducing a blade chassis that includes compute capabilities (heretofore referred to as a 'blade server.')  It also includes networking, storage and virtualization all wrapped up in a tidy bundle.

So while that looks like a blade server (quack!,) walks like a blade server (quack! quack!) that doesn't mean it's going to be positioned, talked about or sold like a blade server (quack! quack! quack!)

What's my point?  What Cisco is building is just another building block of virtualized INFRASTRUCTURE. Necessary infrastructure to ensure control and relevance as their customers' networks morph.

My point is that what Cisco is building is the natural by-product of converged technologies with an approach that deserves attention.  It *is* unified computing.  It's a solution that includes integrated capabilities that otherwise customers would be responsible for piecing together themselves...and that's one of the biggest problems we have with disruptive innovation today: integration.

While the analysts worry about margin erosion and cannibalizing the ecosystem (which is inevitable as a result of both innovation and consolidation,) this is a great move for Cisco, especially when you recognize that if they didn't do this, the internalization of network and storage layers within the virtualization platforms  would otherwise cause them to lose relevance beyond dumb plumbing in virtualized and cloud environments.

Also, let us not forget that one of the beauties of having this "end-to-end" solution from a security perspective is the ability to leverage policy across not only the network, but compute and storage realms also.  You can whine (and I have) about the quality of the security functionality offered by Cisco, but the coverage you're going to get with centralized policy that has affinity across the datacenter (and beyond,) iis  going to be hard to beat.

(There, I said it...OMG, I'm becoming a fanboy!)

And as far as competency as a "server" vendor, c'mon. Firstly, you can't swing a dead cat without hitting a commoditzed PC architecture that Joe's Crab Shack could market as a solution and besides which, that's what ODM's are for.  I'm sure we'll see just as much "buy and ally" with the build as part of this process. 

What's the difference between a blade chassis with intel line processors and integrated networking and a switch these days?  Not much.

So, what Cisco may lose in margin in the "server" sale, they will by far make up with the value people will pay for with converged compute, network, storage, virtualization, management, VN-Link, the Nexus 1000v, security and the integrated one-stop-shopping you'll get.  And if folks want to keep buying their HP's and IBM's, they have that choice, too.

QUACK!

/Hoff

Servers and Switches and VMM's, Oh My! Cisco's California "Server Switch"

From the desk of Cisco's "Virtualization Wow!" Campaign: When is a switch with a server not a virtualization platform?  When it's a server with a switch as a virtualization platform, of course! ;)

I can't help but smile at the announcement that Cisco is bringing to market a blade-based chassis which bundles together Intel's Nehalem-based server processors, the Nexus 5000 switch, and VMware's virtualization and management platform.  From InformationWeek:

Cisco's system, code-named California, likely will be introduced in the spring, according to the sources. It will meld Cisco's Nexus 5000 switch that converges storage and data network traffic, blade servers that employ Intel Nehalem processors, and virtualization management with help from VMware. 

This news was actually broken back in the beginning of December by virtualization.info but I shamefully missed it.  It looked like a bunch of others did, too.

This totally makes sense as virtualization has driven convergence across the compute, network and storage realms and has highlighted the fact that the provisioning, automation, and governance -- up and down the stack -- demands a unified approach for management and support.

For me, this is the natural come-about of what I wrote about in July of 2007 in a blog post titled "Cisco & VMware - The Revolution Will Be...Virtualized?":

This [convergence of network, compute and virtualization, Ed.] is interesting for sure and if you look at the way in which the demand for flexibility of software combined with generally-available COTS compute stacks and specific network processing where required, the notion that Cisco might partner with VMWare or a similar vendor such as SWSoft looks compelling.  Of course with functionality like KVM in the Linux kernel, there's no reason they have to buy or ally...

Certainly there are already elements of virtualization within Cisco's routing, switching and security infrastructure, but many might argue that it requires a refresh in order to meet the requirements of their customers.  It seems that their CEO does.

When I last blogged about Cisco's partnership with VMware and (what is now called) the Nexus 1000v/VN-Link, I made reference to the fact that I foresaw the extraction of the VM's from the servers and suggested that we would see VM's running in the Nexus switches themselves.  Cisco representatives ultimately put a stake in the sand and said this would never happen in the comments of that blog post.

Now we know what they meant and it makes even more sense.

So the bundling of the Nexus 5000* (with the initiator,) the upcoming protocol for VM-Flow affinity tagging, the integrated/converged compute and storage capabilities, and Intel's SR-IOV/MR-IOV/IOMMU technologies in the Nehalem, all supported by the advances with vNetworking/VN-Link makes this solution a force to be reckoned with.

Other vendors, especially those rooted in servers and networking such as HP and IBM, are likely to introduce their own solutions, but given the tight coupling of the partnership, investment and technology development between Intel, VMware and Cisco, this combo will be hard to beat. 

Folks will likely suggest that Cisco has no core competency in building, selling or supporting "servers," but given the channel and partnership with VMware -- with virtualization abstracting that hardware-centric view in the first place -- I'm not sure this really matters.  We'll have to see how accurate I am on this call.

Regardeless of the semantic differences of where the CPU execution lives (based on my initial prediction,) all the things I've been talking about that seemed tangentially-related but destined to come together seem to have.  Further, here we see the resurgence (or at least redefinition of Big Iron, all over again...)

Remember the Four Horsemen slides and the blog post (the network is the computer, is the network, is the...) where I dared you to figure out where "the network" wasn't in the stack?  This is an even more relevant question today. 

It's going to be a very interesting operational and organizational challenge from a security perspective when your server, storage, networking and virtualization platform all come from a single source.

California Dreamin'...

/Hoff

* Not that the 1000v ain't cool, but that little slide that only appeared once at VMworld about the 5000v and the initiator was just too subtely delicious not to be the real juice in the squeeze. The 1000v obviously has its place and will be a fantastic solution, but for folks who are looking for a one-stop shop for their datacenter blueprint designs heavily leveraging virtualization, this makes nothing but sense.

Virtual Routing - The Anti-Matter of Network SECURITY...

Here's a nod to Rich Miller who pointed over (route the node, not the packet) to a blog entry from Andreas Antonopoulos titled "Virtual Routing - The anti-matter of network routing."

The premise, as brought up by Doug Gourlay from Cisco at the C-Scape conference was seemingly innocuous but quite cool:

"How about using netflow information to re-balance servers in a data center"

Routing: Controlling the flow of network traffic to an optimal path between two nodes

Virtual-Routing or Anti-Routing: VMotioning nodes (servers) to optimize the flow of traffic on the network.

Using netflow information, identify those nodes (virtual servers) that have the highest traffic "affinity" from a volume perspective (or some other desired metric, like desired latency etc) and move (VMotion, XenMotion) the nodes around to re-balance the network. For example, bring the virtual servers exchanging the most traffic to hosts on the same switch or even to the same host to minimize traffic crossing multiple switches. Create a whole-data-center mapping of traffic flows, solve for least switch hops per flow and re-map all the servers in the data center to optimize network traffic.

My first reaction was, yup, that makes a lot of sense from a network point of view, and given who made the comment, it does make sense. Then I choked on my own tongue as the security weenie in me started in on the throttling process, reminding me that while this is fantastic from an autonomics perspective, it's missing some serious input variables.

Latency of the "network" and VM spin-up aside, the dirty little secret is that what's being described here is a realistic and necessary component of real time (or adaptive) infrastructure.  We need to get ultimately to the point where within context, we have the ability to do this, but I want to remind folks that availability is only one leg of the stool.  We've got the other nasty bits to concern ourselves with, too.

Let's look at this from two perspectives: the network plumber and the security wonk

From the network plumbers' purview, this sounds like an awesome idea; do what is difficult in non-virtualized environments and dynamically adjust and reallocate the "location" of an asset (and thus flows to/from it) in the network based upon traffic patterns and arbitrary metrics.  Basically, optimize the network for the lowest latency and best performance or availability by moving VM's around and re-allocating them across the virtual switch fabric (nee DVS) rather than adjusting how the traffic gets to the static nodes.

It's a role reversal: the nodes become dynamic and the network becomes more static and compartmentalized.  Funny, huh?

--

The security wonk is unavailable for comment.  He's just suffered a coronary event.  Segmented network architecture based upon business policy, security, compliance and risk tolerances make it very difficult to perform this level of automation via service governors today, especially in segmented network architecture based upon asset criticality, role or function as expressed as a function of (gulp) compliance, let's say. 

Again, the concept works great in a flat network where asset grouping is, for the most part, irrelevant (hopefully governed by a policy asserting such) where what you're talking about is balancing the compute with network and storage, but the moment you introduce security, compliance and risk management as factors into the decision fabric, things get very, very difficult.

Now, if you're Cisco and VMware, the models for how the security engines that apply policy consistently across these fluid virtualized networks is starting to take shape, but what we're missing are the set of compacts or contracts that consistently define and enforce these policies no matter where they move (and control *if* they can move) and how they factor these requirements into the governance layer.

The standardization of governance approaches -- even at the network layer -- is lacking.  There are lots of discrete tools available but the level of integration and the input streams and output telemetry are not complete.

If you take a look, as an example, at CIRBA's exceptional transformational analytics and capacity management solution, replete with their multi-dimensional array of business process, technical infrastructure and resource mapping, they have no input for risk assessment data, compliance or "security" as variables.

When you look at the utility brought forward by the dynamic, agile and flexible capabilities of virtualized infrastructure, it's hard not to extrapolate all the fantastic things we could do. 

Unfortunately, the crushing weight of what happens when we introduce security, compliance and risk management to the dance means we have a more sobering discussion about those realities.

Here's an example reduced to the ridiculous: we have an interesting time architecting networks to maximize throughput, reduce latency and maximize resilience in the face of what can happen with convergence issues and flapping when we have a "routing" problem.

Can you imagine what might happen when you start bouncing VM's around the network in response to maximizing efficiency while simultaneously making unavailable the very resources we seek to maximize the availability of based upon disassociated security policy violations?  Fun, eh?

While we're witnessing a phase shift in how we design and model our networks to support more dynamic resources and more templated networks, we can't continue to mention the benefits and simply assume we'll catch up on the magical policy side later.

So for me, Virtual Routing is the anti-matter of network SECURITY, not network routing...or maybe more succinctly, perhaps security doesn't matter at all?

/Hoff

Arista Networks: Cloud Networking?

Arista Networks is a company stocked with executives whose pedigrees read like the who's-who from the networking metaverse.  The CEO of Arista is none other than Jayshree Ullal, the former senior Vice President at Cisco responsible for their Data Center, Switching and Services and Andres von Bechtolsheim from Sun/Granite/Cisco serves as Chief Development Officer and Chairman.

I set about to understand what business Arista was in and what problems they aim to solve given their catchy (kitchy?) tagline of Cloud Networking™

Arista makes 10GE switches utilizing a Linux-based OS they call EOS which provides high-performance networking. 

The EOS features a "...multi-process state sharing architecture that completely separates networking state from the processing itself. This enables fault recovery and incremental software updates on a fine-grain process basis without affecting the state of the system."

I read through the definition/criteria that describes Arista's Cloud Networking value proposition: scalability, low latency, guaranteed delivery, extensible management and self-healing resiliency.

These seem like a reasonable set of assertions but I don't see much of a difference between these requirements and the transformative requirements of internal enterprise networks today, especially with the adoption of virtualization and real time infrastructure. 

Pawing through their Cloud Networking Q&A, I was struck by the fact that the fundamental assumptions being made by Arista around the definition of Cloud Computing are very myopic and really seem to echo the immaturity of the definition of the "cloud" TODAY based upon the industry bellweathers being offered up as examples of leaders in the "cloud" space.

Let's take a look at a couple of points that make me scratch my head:

Q1:     What is Cloud Computing?    
A1: Cloud Computing is hosting applications and data in large centralized datacenters and accessing them from anywhere on the web, including wireless and mobile devices. Typically the applications and data is distributed to  make them scalable and fault tolerant. This has been pioneered by applications such as Google Apps and Salesfore.com, but by now there are
hundreds of services and applications that are available over the net, including platform services such as Amazon Elastic Cloud and Simple Storage Service.

That's  a very narrow definition of cloud computing and seems to be rooted in examples of large, centrally-hosted providers today such as those quoted.  This definition seems to be at odds with other cloud computing providers such as 3tera and others who rely on distributed computing resources that may or may not be centrally located.

Q4:     Is Enterprise Cloud Computing the same as Server Virtualization? 
A4:     They are not. Server Virtualization means running multiple virtualized operating systems on a single physical server using a Hypervisor, such as VMware, HyperV, or KVM/XVM .  Cloud computing is delivering scalable applications that run on a remote pool of servers and are available to users from anywhere. Basically all cloud computing applications today run directly on a physical server without the use of virtualization or Hypervisors. However, virtualization is a great building block for enterprise cloud computing environments that use dynamic resource allocation across a pool of servers.

While I don't disagree that consolidation through server virtualization is not the same thing as cloud computing, the statement that "basically all cloud computing applications today run directly
on a physical server without the use of virtualization or Hypervisors" is simply untrue.

Q5:     What is Cloud Networking?  
A5:     Cloud Networking is the networking infrastructure required to support cloud computing, which requires fundamental improvement in network scalability, reliability, and latency beyond what traditional enterprise networks have offered.  In each of these dimension the needs of a cloud computing network are at least an order of magnitude greater than for traditional enterprise networks.

I don't see how that assertion has been formulated or substantiated.

I'm puzzled when I look at Arista's assertion that existing and emerging networking solutions from the likes of Cisco are not capable of providing these capabilities while they simultaneously seem to shrug off the convergence of storage and networking.  Perhaps they simply plan on supporting FCoE over 10GE to deal with this?

Further,  ignoring the (initial) tighter coupling of networkng with virtualization to become more virtualization-aware with the likes of what we see from the Cisco/VMware partnership delivering VN-Link and the Nexus 1000v, Ieaves me shaking my head in bewilderment.

Further, with the oft-cited example of Amazon's cloud model as a reference case for Arista, they seem to ignore the fact that EC2 is based upon Xen and is now offering both virtualized Linux and Windows VM support for their app. stack.

It's unclear to me what problem they solve that distinguishes them from entrenched competitors/market leaders in the networking space unless the entire value proposition is really hinged on lower cost.  Further, I couldn't find much information on who funded (besides the angel round from von Bechtolsheim) Arista and I can't help but wonder if this is another Cisco "spin-in" that is actually underwritten by the Jolly Green Networking Giant.

If you've got any useful G2 on Arista (or you're from Arista and want to chat,) please do drop me a line...

/Hoff

Performance Of 3rd Party Virtual Switches, Namely the Cisco Nexus 1000v...

One of the things I'm very much looking forward to with the release of Cisco Nexus 1000v virtual switch for ESX is the release of performance figures for the solution.

In my Four Horsemen presentation I highlight with interest the fact that in the physical world today we rely on dedicated, highly-optimized multi-core COTS or ASIC/FPGA-powered appliances to deliver consistent security performance in the multi-Gb/s range. 

These appliances generally deliver a single function (such as firewall, IPS, etc.) at line rate and are relatively easy to benchmark in terms of discrete performance or even when in-line with one another.

When you take the approach of virtualizing and consolidating complex networking and security functions such as virtual switches and virtual (security) appliances on the same host competing for the same compute, memory and scheduling resources as the virtual machines you're trying to protect, it becomes much more difficult to forecast and preduct performance...assuming you can actually get the traffic directed through these virtual bumps in the proper (stateful) order.

Recapping Horsemen #2 (Pestilence,) VMware's recently published performance results (grain of NaCl taken) for ESX 3.5 between two linux virtual machines homed to the same virtual switch/VLAN/portgroup in a host shows throughput peaks of up to 2.5 Gb/s.  Certainly the performance at small packet rates are significantly less but let's pick the 64KB-64KB sampled result shown below for a use case:
Given the performance we see above (internal-to-internal) it will be interesting to see how the retooling/extension of the networking functions to accomodate 3rd party vSwitches, DVS, API's, etc. will affect performance and what overhead these functions impose on the overall system.  Specifically, it will be very interesting to see how VMware's vSwitch performance compares to Cisco's Nexus 1000v vSwitch in terms of "apples to apples" performance such as the test above.*

It will be even more interesting to see what happens when vNetwork API's (VMsafe) API calls are made in conjunction with vSwitch interaction, especially since the performance processing will include the tax of any third party fast path drivers and accompanying filters.  I wonder if specific benchmarking test standards will be designed for such comparison?

Remember, both VMware's and Cisco's switching "modules" are software -- even if they're running in the vKernel, so capacity, scale and performance are a function of arbitrated access to hardware via the hypervisor and any hardware-assist present in the underlying CPU.

What about it, Omar?  You have any preliminary figures (comparable to those above) that you can share with us on the 1000v that give us a hint as to performance?

/Hoff

* Further, if we measure performance that benchmarks traffic including physical NICs, it will be interesting to see what happens when we load a machine up with multiple 10Gb/s Ethernet NICs at production loads trafficked by the vSwitches.

Fiction Versus Function: Three Unspoken Annoynaces of Cisco & VMware's Virtualization "Partnership"

I spend a good amount of time thinking about how multiple technology strategies from market leaders coalesce into a reasonably homogenized version of reality in the networking and security space in order to decide where to place bets; it's akin to reading a tell and analyzing a player's betting strategy at a poker table.

I look at Cisco and VMware and can't help to chuckle at the moves being made in the name of "partnership" on the virtualization front and there's an awful lot of twitching going on that doesn't require Phil Hellmuth to decode. 

Partnerships are nothing new, but usually they are couched with certain modicum of suspicion and cynicism.  However, speaking with folks at VMworld, either folks were high from the Oxygen Bar at the airport, or they were adding naiveté syrup to the drinks because I seemed alone in my concerns...

I've put together a couple of summary points on the matter -- more for my own personal enjoyment and note taking than anything else -- and framed them in terms of what I find to be really annoyingly obvious examples of these two strange bedfellows' behaviors:

1)  The purported cohesion of Cisco's and VMware's virtualization strategies is a simply a matter of converged parallelism and forced perspective.

You've seen diagrams that demonstrate the notion of converged parallel lines, right?  If you haven't here's an example:

You'll notice that in this diagram there exists a series of parallel lines which seem to converge at a "vanishing point" on the horizon.

This in fact is not the case.  The lines don't actually ever converge, they just look like they do.  It's all a matter of perspective.  Imagine these lines as Cisco's and VMware's virtualization strategies.

Similarly, the notion of forced perspective is a method by which the manipulation of perspective employs an optical illusion to make something appear closer, father away, larger or smaller than it actually is (see the title image above*.)

The announcements from Cisco and VMware are very much like these examples. Whilst they offer excellent opportunities for improving the management and security of virtual infrastructure, it's very much Machiavellian marketing -- the end is going to justify the means.

Speaking to either Cisco or VMware you're asked to suspend disbelief and accept that these two companies share a common blueprint for a datacenter OS, but they don't.  In fact, they're quite different, and the balance of who needs whom more is also very lopsided.

Despite the close technical partnership needed to pull off the integration of the Nexus 1000v as the first third party virtual switch (which we've been talking about for almost two years,) Cisco and VMware really are on parallel trajectories in terms of their visions regarding the datacenter OS; how it's designed, provisioned, deployed, managed and governed...and by whom.

Cisco is approaching this primarily as an infrastructure transformation play as a way of clawing back what they lost when the network access layer become absorbed into the virtual hosts while VMware is busy distancing itself from the infrastructure and elevating the discussion to that of the cloud in an effort to stave off Microsoft and Citrix.

Each want to own your datacenter, and while they play nice on the surface, there's really a nasty game of tug of war going on here.  This is a marriage borne of convenience, nothing more.

You try and unify Cisco's DC 3.0 vision with VMware's Virtual Datacenter OS blueprint and tell me how they mesh.

2)  Dear Virtual SysAdmin: You're fired as the network admin.  You're cool with that, right?

It's funny how both Cisco and VMware's marketing folk in the sessions discussing the release of the Nexus 1000v vSwitch, both snarkily (and rhetorically) posited "How many of you Virtual SysAdmins have coordination and communication issues between your virtualization and network teams?"

Leading the witness further, the next question was  "Don't you just hate having to fight to get the network teams to give you a trunk port on an access switch?" 

They followed that up with "Your prayers are answered!  The 1000v will allow you to give the network provisioning back to the network  teams and let them control the networking and connectivity.  Isn't that great?" 

While most nodded away in the affirmative to the first and second questions, I didn't see one audience member who answered positively on the latter.  What makes anyone think the vSysAdmins *want* to give up the control of the virtual networking layer and be at the mercy of the networking teams again?

Interesting battle ground for sure.  Now, please don't misinterpret my commentary as a suggestion that this is a bad thing, but we're already in the middle of a "West Side Story" turf war over organizational fiefdoms.  This will, depending upon what sort of contention exists already, make a really tenuous issue even more so.

3) Software Sucks.  Hardware Rules.   I hope you like ping pong.

I hinted at this point in my post titled (The Network is the Computer...)  The reality is that much like point #1, Cisco could care less in the long term about the Nexus 1000v as a software switch running in someone else's backyard operating environment, but rather introduces it to enable the landscape clawback it gets to enjoy in the short term and make relevant once again it's big network iron in the longer timeframe.

A telling slide was the announcement of what's coming AFTER the Nexus 1000v in one of the sessions that I have not seen presented in detail elsewhere -- that is Cisco's goal to extract networking out of the host completely.

The plan as discussed is to utilize what Cisco calls an "initiator" to replace the 1000v and force traffic, after specialized tagging which denotes affinity of flows to specific VM ID's, and ship them straight back out the network interfaces to a waiting Cisco 5000/7000 switch for processing.  Hence the ping-pong mention above.

Sorry for the quality of the picture as I took it sitting behind somebody, but here's a slide denoting just this very thing:
 
The notion of a third party switching capability is really just a way for Cisco to push the access layer back to where they think it rightfully belongs -- in the physical switch.

Cisco claims that VMware and they have submitted this tagging specification to the IEEE for review/ratification.   I find that very interesting.

I wrote about the need for such a technology at both the virtualization layer and more importantly the application/data level in June of 2007. 

Check out my post which described how I suggested Crossbeam do the exact same thing by way of something I called ADAPT (Applied Data and Application Policy Tagging) which describes this very thing.  What's next, they're going to announce vNAC? ;)

--

All in all, the Cisco/VMware relationship is about as natural looking as the Microsoft/Citrix version -- it's sort of like a midget dating a six foot supermodel...someone's getting the better end of the footrub in that relationship, too.

So, how about it?  Am I stating the obvious again -- and does it need to be stated?

/Hoff

*image from "The Eye of Brad" flickrstream

The Network Is the Computer...(Is the Network, Is the Computer...)

If there's one motif emerging from VMworld this year, it's very much the maxim "be careful what you ask for, because you might just get it."

The precipitate convergence of virtualized compute, network and storage is really beginning to take significant form; after five hard years of hungering for the materialization of the technology, enterprise architecture, and market/business readiness, the notion of a virtualized datacenter OS with a value proposition larger than just " cost-optimized infrastructure" has now become a deliciously palpable reality.  

The overlap and collision of many leading technology providers' "next generation" datacenter (OS) blueprints is something I have written about before.  In many cases there's reasonable alignment between the overall messaging and promised end result, but the proof is in the implementation pudding. I'm not going to rehash this here because I instead want to pick on something I've been talking about for quite some time.

From a network and security perspective, things are about to (again) fundamentally and profoundly change in terms of how we operationally design, provision, orchestrate, manage, govern and secure our infrastructure, applications and information.  It's important to realize that this goes way beyond just  adding a 'v' to the name of a product. 

What's incredibly interesting is the definition and context of where and what makes up the "network" that transports all our bits and how the resources and transports interact to deliver them securely.

It should be clear that even in a homogenous platform deployment, there exists an overwhelming complex conglomerate of mechanisms that make up the machinery enabling virtualization today.  I think it's fair to say that we're having a difficult time dealing with the non-virtualized model we have today.   Virtualization?  She's a cruel mistress bent on reminding us we've yet to take out the trash as promised.

I'm going to use this post to highlight just how "complexly simple" virtual networking and security have become using as an example the last two days' worth of  announcements, initiatives and demonstrations of technology and solutions from Intel, VMware, Cisco and the dozens of security ISV's we know and love.

Each of the bumps in these virtual wires deserves its own post, which they are going to get, especially VMware's vNetwork/VMsafe, distributed network switch, and Cisco's Nexus 1000v virtual switch announcements.  I'm going to break each of these elemental functions down in much more detail later as they are simply amazing.

Now that networking is abstracted across almost every layer of this model and in many cases managed by separate organizational siloes and technologies, how on earth are we going to instantiate a security policy that is consistent across all strata?  We're used to this problem today in physical appliances, but the isolation and well-definable goesinta/goesouta perimeterized boundaries allows us to easily draw lines around where these

policy differentials intersect. 

 It's used to be the devil you knew.  Now it's eleven different devils in disguise.

As you visualize the model below and examine how it applies to your experience, I challenge you to tell me where the "network" lives in this stack and how,  at a minimum, you think you're going to secure it.   This is where all those vendor roadmaps that are colliding and intersecting start to look like a hodgepodge:

In the example model I show here, any one of these elements -- potentially present in a single VMware ESX host -- can directly or indirectly instantiate a set of networking or security functions and policies that are discrete from one another's purview but ultimately interrelated or even dependent in ways and using  methods we've not enjoyed before.  

In many cases, these layered components are abstracted from one another and managed by separate groups.  We're seeing the re-emergence of  network-centricity, it's just that the  network is camouflaged in all its cloudy goodness.  This isn't a story where we talk about clearly demarcated hosts  that plug into "THE" network, regardless of whether there's a hypervisor in the picture.

 

Here's where it gets fun...

In this model you have agents in the Guest OS interacting with security/networking virtual appliances on the ESX host either inline or via vnetworking APIs (switching or security) which in turn uses a fastpath networking kernel driver  connected to VMware's vSwitch while another VA/VM is connected to a Cisco Nexus 1000v vSwitch implemented as a second distributed virtual network switching fabric which are all running atop an Intel CPU utilizing SR-IOV via VT-d in the chipset which in turn allows VM's to direct attach (bypassing the VMM) to NIC cards with embedded switching connected to your network/storage fabrics...

Mass hysteria, cats and dogs living together...

So I'll ask you again: "Where's the network in that picture?"  Or, more precisely, "where isn't it?"  

This so hugely profound, but that may because I've been exposed to each of the bubbles in this diagram and see how each of them relate or do not.  When you step back and look at how, as an example, Cisco and VMware are both going through strategic sea changes in how they are thinking about networking and security, it's truly 

amazing but I think the notion of network intelligence is a little less cut and dry as some might have us believe.

Is this as mind-blowing to you as it is to me?  If not, wait until I rip open the whole vNetworking and Nexus 1000v stuff.  Very, very cool.

/Hoff

VMWorld 2008: "Introducing Cisco's Virtual Switch for VMware ESX"...

 

Update below.

It's the night before VMworld 2008 and the Technology Exchange/Partner day begins and I'm pawing through the stuff in my bag, separating the "keep it" from the "toss it" schwag.

There's an innocuous little flyer stuffed in the bag on Cisco letterhead titled "Introducing Cisco's Virtual Switch for VMware ESX."  Fantastic.  Let's call it the 'cSwitch' ;)

A year and a month ago in August of 2007, I blogged about this very thing in a post titled: "VMware to Open Development of ESX Virtual Switches to Third Parties...Any Guess Who's First?" based on a hint from virtualization.info.

Given that VMworld 2007 came and went without this announcement, I'm very excited that we're actually going to get a look at what Cisco will offer; I think this is huge news and ultimately offers some profound game-changing (for good and bad) implications on the network and security fronts.

I have dozens of questions like: I wonder how much of the Nexus (7000 series)/NX-OS code cross-pollinates over (if any) to this solution and if we'll see capabilities such as STP/PVST+/Private VLANs, HSRP, Multicast, etc. make their way into Cisco's vSwitch and how this virtual switch with integrate/interoperate with the vkernel.

Further, as Ed Haletky and I unofficially bet over drinks this evening, I wonder if it will be a direct replacement for VMware's at-boot loadable module or it will co-exist?  I bet the former. ;)

In addition to the "cSwitch," there are a couple of sessions I am very, very interested in attending given my exposure to VFrame and some Cisco engineers/architects at last year's show:

Simplify VMotion with Virtual Machine–Aware Network and Storage Services
See how network and storage services can be linked to a virtual machine so they move with VMotion events.

ESX Server in a Unified Fabric Environment
See how ESX Server works in a unified fabric environment with ESX 3.5 U2, Emulex Converged Network Adaptors, and the Cisco Nexus 5000.

VFrame: Enriching ESX Deployment with End-to-End Orchestration
Cisco’s VFrame DC 1.2 provides an easy-to-use template-based provisioning approach for rapid, repeatable, and compliant provisioning of ESX Servers. Through a rich set of networking and storage orchestration capabilities, it reduces the time required to bring up ESX clusters while providing operational scalability to manage large clusters effectively.

See the second topic above?  Remember when I mentioned in prior posts about virtualizing applications directly within the Nexus?

Should be a very interesting couple of days.

/Hoff

Update: So there was no direct news/mention specifically of Cisco today in any of the distributed virtual networking (DVN) sessions -- there's a lot of messaging collisions because the re-branded 'v-everything' strategy has things being renamed.  Hopefully we'll see/hear more from Cisco tomorrow.

Many of the underlying functions that will enable 3rd party virtual switches as well as any network interface to the vkernel via API were discussed today under the capabilities described by vNetwork (this includes the vNetwork Appliance API's and what you've known as VMsafe.)  You can see more about vNetwork here in this post.

All I can say is that I got a lot of my suspicions confirmed, questions answered and conclusions affirmed in today's sessions.  Some good, some bad.  It's going to be a bumpy ride, kids.

The Four Horsemen live! ;)

Big Iron is Dead...Long Live Big Iron?

Over the last 5 years or so with the pronounced emergence of inexpensive multi-core COTS compute platforms and the rabid evangelism of virtualization, I have debated many times with folks who continue to suggest that "big iron" -- high performance equipment in the compute, network, security and storage domains -- is now "extinct" and that nobody buys bespoke equipment any more.

Many of them argued "All you need is a COTS PC, package up OS/Applications and voila!  Instant appliance!  Ready for the edge, ready for the core."

Not surprisingly, many of the networking/security/application delivery companies that these folks worked for ultimately introduced custom-engineered hardware solutions, melding their software with custom hardware and COTS elements to produce a piece of big iron of their own...

About a year ago, I wrote a blog on this topic highlighted by a post titled "All your COTS multicore CPU's with non-optimized security software are belong to us," in which I extrapolated some very interesting points regarding Moore's law and the hubris surrounding the gluttony of compute power offered by higher density chipsets without the corresponding software architecture to take advantage of it.

Update: I forgot that I wrote a really good post (this March!) on this same topic titled "I Love the Smell Of Big Iron In the Morning..."

This is a little tickler to that post.

I come from the land of servicing large enterprises, service providers, municipalities and nation states  and not the SME. 

While there are certainly exceptions to the "rule," and it's reasonable to suggest that my perspective is skewed, I've always been careful to ensure I framed my discussions this way, so debating/contrasting the architectural slants of an SME with a Fortune 10 doesn't really move the discussion along any.

So, sticking with the large enterprise theme, there are two interesting divergent themes emerging: the centralization of compute and storage with the distributed nature of connectivity and information.

Without muddying the water too much about how these scenarios are not all that mutually exclusive, let's stick with the "centralization" theme for a moment.

The mainstream adoption of virtualization as an enabler brings us full-circle back around to the centralized mainframe model* of compute, networking and storage.  Now that reasonably reliable, high speed and low latency connectivity is available, centralization of resources makes sense since people can generally get access to the assets they require and the performance to get from point A to point B is for the most part acceptable (and getting more so.)

Once again, the natural consolidation of functionality and platform architecture follows suit -- we're back to using big iron to deliver the balance of cost, resilience, performance and simplified management that goes along with squeezing more from less.

To wit, let's examine some recent virtualization-inspired, big iron plays:

Compute:

HP introduced [recently] the Proliant BL495c G5, the first blade designed to be a virtual machine-intensive host in a data center rack, along with other virtualization products to enhance the offerings of VMware and Citrix Systems.

As system administrators achieve savings by consolidating 8-10 virtual machines per server, HP is saying its new blade will host up to 32 virtual machines, based on each virtual machine needing a minimum of four Gigabytes of memory. When 16 of the blades are stacked in an HP C7000 enclosure, a total of 512 virtual machines can be run from a single rack, said Jim Ganthier, director of HP BladeSystem, its blade server division.

Network & Storage:

The Cisco Nexus 7000 Series is the flagship member of the Cisco Nexus Family, the first in a new data center class of switching products. The Nexus 7000 is a highly scalable modular platform that delivers up to 15 terabits per second of switching capacity in a single chassis, supporting up to 512 10-gigabits-per-second (Gbps) Ethernet and future delivery of 40- and 100-Gbps Ethernet. Its unified fabric architecture combines Ethernet and storage capabilities into a single platform, designed to provide all servers with access to all network and storage resources. This enables data center consolidation and virtualization. Key components of the unified fabric architecture include unified I/O interfaces and Fibre Channel over Ethernet support to be delivered in the future.

Security:

The Crossbeam X-Series is a carrier-class modular security services switch.  The X80 platform is Crossbeam's flagship high-end security services platform for complete network, security.  The X80 provides up to 40 Gigabit Ethernet ports and 8 x 10 Gigabit Ethernet ports or up to 64 Fast Ethernet ports and up to 40 Gbps of full duplex firewall throughput.  Each network processor module features an integrated 16-core MIPS-64 security processor, a high speed network processor and a custom-designed switch fabric FPGA.  The X80 supports up to 10 application processor modules which are based on Intel technology running a hardened version of Linux supporting best-in-breed security software from leading vendors in highly resilient, load-balanced configurations.

These are just a few examples.

Each of these solutions delivers the benefits of hefty amounts of virtualized service, but what you'll notice is that they do so in massive scale, offering consolidated services in high-density "big iron" configurations for scale, resilience, manageability and performance.

In this period of the technology maturity cycle, we'll see this trend continue until we hit a plateau or an inflection point -- whether it is triggered due to throughput, power, heat, latency, density or whatnot.  Then we'll start anew and squeeze the balloon once more, perhaps given what I hinted at above with clusters of clouds that define an amporphous hive of virtualized big iron.

But for now, until service levels, reliability, coherence and governance are sorted, I reckon we'll see more big iron flexing it's muscle in the data center.

What about you?  Are you seeing the return of big iron in your large enterprise.  Perhaps it never left?

I for one welcome my new blinking dark overlord...

/Hoff

* There's even a resurgence of the mainframe itself lately.  See IBM's z/10 and Unisys' ClearPath for example.

No DNS Disclosure Debacle Here: Stiennon Pens the Funniest Thing I've Read in 2008...

Hat tip to Rothman for this.

I don't know if Stiennon is off his meds or simply needed to re-post something from 2001 to meet an editorial quota, but his Network World article titled "The Most Important Networking Trend of 2008" ties thus far with the "Evolution of Dance" as my vote for most entertaining Internet content.

Richard's epiphany goes something like this:

• Multifunction network devices that have the ability to "route" traffic and combine security capabilities are the 'next big thing'
  
  
• If a company offers a multifunction network device that has the ability to "route" traffic and combine security capabilities but have the misfortune of using Linux as the operating system, they will "...forever be pigeon-holed as SMB solutions, not ready for enterprise prime time."
  
  
• The Wall Street Journal issued "... the year's most important article on networking" in an article titled "New Routers Catch the Eyes of IT Departments" which validates the heretofore undiscovered trend of convergence and commoditization!
   
  
• "Real" network security players such as Cisco, Juniper and Redback are building solutions to this incredible new trend and because of the badge on the box, will be considered ready for "...enterprise prime time."
   
  
• The WSJ article talks about the Cisco ASR1000 router as the penultimate representation of this new breed of converged "network security" device.
   
  
• Strangely, Stiennon seems to have missed the fact that the operating system (IOS-XE) that the ASR1000 is based on is, um, Linux.  You know, that operating system that dictates that this poor product will "...forever be pigeon-holed as SMB solutions, not ready for enterprise prime time."
  

Oh, crap!  Somebody better tell Cisco!

So despite the fact that Cisco ASR1000 is positioned as an edge device as are these crazy solutions called UTM devices, it seems we're all missing something because somehow a converged edge device now counts as being able to provide a "secure network fabric?"

In closing, allow me to highlight the cherry on top of Stiennon's security sundae:   

Have you ever noticed how industry "experts" tend to get stuck in a rut and continue to see everything through the same lens despite major shifts in markets and technology?

Yes, Richard, I do believe I have noticed this...

Funny stuff!

/Hoff

I Love the Smell of Big Iron In the Morning...

Does Not Compute...

I admit that I'm often fascinated by the development of big iron and I also see how to some this seems at odds with my position that technology isn't the answer to the "security" problem.  Then again, it really depends on what "question" is being asked, what "problem" we're trying to solve and when we expect to solve them.

It's pretty clear that we're still quite some time off from having secure code, solid protocols, brokered authentication and encryption and information-centric based controls that provide the assurance dictated by the policies described by the information itself. 

In between now and then, we see the evolution of some very interesting "solutions" from those focused on the network and host perspectives.  It's within this bubble that things usually get heated between those proponents who argue that innovation in networking and security is constrained to software versus those who maintain that the way to higher performance, efficacy and coverage can only be achieved with horsepower found in hardware.

I always find it interesting that the networking front prompts argument in this vein, but nobody seems to blink when we see continued development in mainframes -- even in this age of Web3.0, etc.  Take IBM's Z10, for example.  What's funny is that a good amount of the world still ticks due to big iron in the compute arena despite the advances of distributed systems, SOA, etc., so why do we get so wrapped up when it comes to big iron in networking or security?

I dare you to say "value." ;)

I've had this argument on many fronts with numerous people and realized that in most cases what we were missing was context.  There is really no argument to "win" here, but rather a need for examination of what most certainly is a manifest destiny of our own design and the "natural" phenomena associated with punctuated equilibrium.

An Example: Cisco's New Hardware...and Software to Boot [it.]

Both camps in the above debate would do well to consider the amount of time and money a bellwether in this space -- Cisco --  is investing in a balanced portfolio of both hardware and software. 

If we start to see how the pieces are being placed on Cisco's chess board, it makes for some really interesting scenarios:

• 40 core QuantumFlow processor
• The 7000 series Nexus switch
• The ASR 1000 featuring the QuantumFlow
• IOS-XE Virtualization for the ASR 1000  powered by KVM/Linux

Many will look at these developments and simply dismiss them as platforms that will only solve the very most demanding of high-end customers and that COTS hardware trumps the price/performance index when compared with specialty high-performance iron such as this. 

This is a rather short-sighted perspective and one that cyclically has proven inaccurate.   

The notion of hardware versus software superiority is a short term argument which requires context.  It's simply silly to argue one over the other in generalities.  If you'd like to see what I mean, I refer you once again to Bob Warfield's "Multi-Core Crisis" meme.  Once we hit cycle limits on processors we always find that memory, bus and other I/O contention issues arise.  It ebbs and flows based upon semiconductor fabrication breakthroughs and the evolution and ability of software and operating systems to take advantage of them.

Toss a couple of other disruptive and innovative technologies into the mix and the landscape looks a little more interesting. 

It's All About the Best Proprietary Open Platforms...

I don't think anyone -- including me at this point -- will argue that a good amount of "security" will just become a checkbox in (and I'll use *gasp* Stiennon's language) the "fabric."  There will always be point solutions to new problems that will get bolted on, but most of the security solutions out there today are becoming features before they mature to markets due to this behavior.

What's interesting to me is where the "fabric" is and in what form it will take. 

If we look downrange and remember that Cisco has openly discussed it's strategy of de-coupling its operating systems from hardware in order to provide for a more modular and adaptable platform strategy, all this investment in hardware may indeed seem to support this supposition.

If we also understand Cisco's investment in virtualization (a-la VMware and IOS-XE) as well as how top-side investment trickles down over time, one could easily see how circling the wagons around both hardware for high-end core/service provide platforms [today] and virtualized operating systems for mid-range solutions will ultimately yield greater penetration and coverage across markets.

We're experiencing a phase shift in the periodic oscillation associated with where in the stack networking vendors see an opportunity to push their agenda, and if you look at where virtualization and re-perimeterization are pushing us, the "network is the computer" axiom is beginning to take shape again. 

I find the battle for the datacenter OS between the software-based virtualization players and the hardware-based networking and security gianst absolutely delicious, especially when you consider that the biggest in the latter (Cisco) is investing in the biggest of the former (VMware.)

They're both right.  In the long term, we're all going to end up with 4-5 hypervisors in our environments supporting multiple modular, virtualized and distributed "fabrics."  I'm not sure that any of that is going to get us close to solving the real problems, but if you're in the business of selling tin or the wrappers that go on it, you can smile...

Imagine a blade server from your favorite vendor with embedded virtualization capabilities coupled with dedicated network processing hardware supporting your favorite routing/switching vendor's networking code and running any set of applications you like -- security or otherwise -- with completely virtualized I/O functions forming a grid/utility compute model.*

Equal parts hardware, software, and innovation.  Cool, huh?

Now, about that Information-Centricity Problem...

*The reality is that this is what attracted me to Crossbeam: custom-built high-speed networking hardware, generic compute stacks based on Intel-reference designs, both coupled with a Linux-based operating system that supports security applications from multiple sources as an on-demand scalable security services layer virtualized across the network.

Trouble is, others have caught on now...

I/O Virtualization: The Battle for the Datacenter OS and What This Means to Security

One of the very profound impacts virtualization will have on security is the resultant collateral damage caused by what I call the "battle for the datacenter OS" framed by vendors who would ordinarily not be thought of as "OS vendors." 

I call the main players in this space the "Three Kings:" Cisco, VMware and EMC. Microsoft is in there also, but that's a topic for another post as I bifurcate operating system vendors in the classical sense from datacenter infrastructure platforms.  Google deserves a nod, too.

The "Datacenter OS" I am speaking of is the abstracted amalgam of virtualization and converged networking/storage that delivers the connected and pooled resource equivalent of the utility power grid.   Nick Carr reflects in his book "The Big Switch":

A hundred years ago, companies stopped producing their own power with steam engines and generators and plugged into the newly built electric grid.”

The "datacenter" and its underlying "operating system," in whatever abstracted form they will manifest themselves, will become this service layer delivery "grid" to which all things will connect; services will be merely combinations of resources and capabilities which are provisioned dynamically.

We see this starting to take form with the innovation driven by virtualization, the driving forces of convergence, the re-emergence of grid computing, the architectures afforded by mash-ups and the movements and investments of the Three Kings in all of these areas.

It's pretty clear that that these three vendors are actively responsible for shaping the future of computing as we know it.  However, It's not at all clear to me how much of the strategic overlap between them is accidental or planned, but they're all approaching the definition of how our virtualized computing experience will unfold in very similar ways, albeit from slightly different perspectives.

One of the really interesting examples of this is how virtualization and convergence are colliding to produce the new model of the datacenter which blurs the lines between computing, networking and storage.

Specifically, the industry -- as driven by customers -- is trending toward the following:

• Upgrading from servers to blades
• Moving from hosts and switches to clusters and fabrics
• Evolving from hardware/software affinity to grid/utility computing
• Transitioning from infrastructure to service layers in “the cloud”

The topic of this post is really about the second bullet, moving from the notion of the classical hosts/servers plugging into separate network and storage switches to instead clusters of resources connecting to fabric(s) such that what we end up with are pools of resources to be provisioned, allocated and dispatched where, when and how needed. 

This is where I/O virtualization enters the picture.  I/O virtualization at the macro level of the datacenter describes the technology which enables the transition from the discrete and directly-connected model of storage versus networking to a converged virtualized model wherein network and storage resources are aggregated into a single connection to the "fabric."

Instead of having separate Ethernet, fiber channel and Infiniband connections, you'd have a single pipe connected to a "virtual connectivity switch" that provides on-demand, dynamic and virtualized allocation of resources to anything connected to the fabric.  The notion of physical affinity from the server/host's perspective goes away.

Andy Dornan from Information Week just did a nice write-up titled "Cisco pitches virtual switches for next-gen data centers." 

It's obviously focused on Cisco's Nexus 7000 Series switch, but also gives some coverage of Brocade's DCX Backbone, Xsigo's Director and 3Leaf's v-8000 products.

Check out what Andy had to say about Cisco's strategy:

Cisco's vision is one in which big companies off-load an increasing number of server tasks to network switches, with servers ultimately becoming little more than virtual machines inside a switch.*

The Nexus doesn't deliver that, but it makes a start, aiming to virtualize the network interface cards, host bus adapters, and cables that connect servers to networks and remote storage. At present, those require dedicated local area networks and storage area networks, with each using a separate network interface card and host bus adapter for every virtual server. The Nexus aims to consolidate them all into one (or two, for redundancy), with virtual servers connecting through virtual NICs.

This stuff isn't vaporware anymore.  These products are real...from numerous entities.  These companies -- and especially Cisco -- are on a mission to re-write the datacenter blueprint and security along with it.  VMware's leading the virtualization charge and Cisco's investing for the long run.  When you look at their investment in VMware, the I/O virtualization play and what they're doing with vFrame, it's impressive -- and scary at the same time.

Them's a lot of eggs in one basket, and it's perfectly clear that there is a huge sucking sound coming from the traditional security realm as we look out over the horizon.  How do you apply a static security sensibility grounded in the approaches of 20 years ago to an amorphous, fluid, distributed and entirely dynamic pooled set of resources and information?

Cisco has thrown their hat in the ring to address the convergence of role-based admission and access control with the announcement of TrustSec which will be available in the Nexus as it is in the higher-end Catalyst switches.  Other vendors such as HP, Extreme and now Juniper as well as up-starts like Nevis and Consentry have their perspectives.  What each of these infrastructure networking vendors have in store for how their solutions will play in the world of virtualized and distributed computing is still to unfold.

How might this emerging phase of technology, architecture, provisioning, management, deployment and virtualization of resources impact security especially since we've barely even started to embrace the impact server virtualization has?  One word:

Completely.

More on this topic shortly...

/Hoff

*Update: A colleague of mine from Unisys, Michael Salsburg, prompted me via discussion to clarify a point.  I think that  for at least the short term, the "server tasks" that will be offloaded to I/O virtualization solutions such as Cisco's will be fairly narrow in scope and logically defined.  However, given that NX-OS is Linux based, one might expect to see a Hypervisor-like capability within the switch itself, enabling VM's and applications to be run directly within it.

Certainly we can expect and intermediary technology derivation which would include Cisco developing their own virtual switch that complements/replaces the vSwitch present in the VMM today; at this point given the heft/performance of the Nexus, one could potentially see it existing "outside" the vHost and using a high-speed 10Gb/s connection, redirect all virtual network functions to the external switch...

Hypervisors Are Becoming a Commodity...Virtualization Is a Feature?

A couple of weeks ago I penned a blog entry titled "The Battle for the HyperVisor Heats Up" in which I highlighted an announcement from Phoenix Technologies detailing their entry into the virtualization space with their BIOS-enabled VMM/Hypervisor offering called HyperCore.

This drew immediate parallels (no pun intended) to VMware and Xen's plans to embed virtualization capabilities into hardware.

The marketing continues this week with interesting announcements from Microsoft, Oracle and VMware:

1. VMware offers VMware Server 2 as a free virtualization product to do battle against...
2. Oracle offering "Oracle VM" for free (with paid support if you like) which claims to be 3 times as efficient than VMWare -- based on Xen.
3. Microsoft officially re-badged its server virtualization technology as Hyper-V (nee Veridian)
   detailing both a stand-alone Hyper-V Server as well technology integrated into W2K8 Server.
   

It seems that everyone and their mother is introducing a virtualization platform and the underpinning of commonality between basic functionality demonstrates how the underlying virtualization enabler -- the VMM/Hypervisor -- is becoming a commodity.

We are sure to see fatter, thinner, faster, "more secure" or more open Hypervisors, but this will be an area with less and less differentiation.  Table stakes.  Everything's becoming virtualized, so a VMM/Hypervisor will be the underlying "OS" enabling that transformation.

To illustrate the commoditization trend as well as a rather fractured landscape of strategies, one need only look at the diversity in existing and emerging VMM/Hypervisor solutions.   Virtualization strategies are beginning to revolve around a set of distinct approaches where virtualization is:

1. Provided for and/or enhanced in hardware (Intel, AMD, Phoenix)
2. A function of the operating system (Linux, Unix, Microsoft)
3. Delivered by means of an enabling software layer (nee platform) that is deployed across your entire infrastructure (VMware, Oracle)
4. Integrated into the larger Data Center "Fabric" or Data Center OS (Cisco)
5. Transformed into a Grid/Utility Computing model for service delivery

The challenge for a customer is making the decision on whom to invest it now.  Given the fact that there is not a widely-adopted common format for VM standardization, the choice today of a virtualization vendor (or vendors) could profoundly affect one's business in the future since we're talking about a fundamental shift in how your "centers of data" manifest.

What is so very interesting is that if we accept virtualization as a feature defined as an abstracted platform isolating software from hardware then the next major shift is the extensibility, manageability and flexibility of the solution offering as well as how partnerships knit out between the "platform" providers and the purveyors of toolsets.

It's clear that VMware's lead in the virtualization market is right inline with how I described the need for differentiation and extensibility both internally and via partnerships. 

VMotion is a classic example; it's clearly an internally-generated killer app. that the other players do not currently have and really speaks to being able to integrate virtualization as a "feature" into the combined fabric of the data center.  Binding networking, storage, computing together is critical.  VMware has a slew of partnerships (and potential acquisitions) that enable even greater utility from their products.

Cisco has already invested in VMware and a recent demo I got of Cisco's VFrame solution shows they are serious about being able to design, provision, deploy, secure and manage virtualized infrastructure up and down the stack, including servers, networking, storage, business process and logic.

In the next 12 months or so, you'll be able to buy a Dell or HP server using Intel or AMD virtualization-enabled chipsets pre-loaded with multiple VMM/Hypervisors in either flash or BIOS.  How you manage, integrate and secure it with the rest of your infrastructure -- well, that's the fun part, isn't it?

I'll bet we'll see more and more "free" commoditized virtualization platforms with the wallet ding coming from the support and licenses to enable third party feature integration and toolsets.

/Hoff

Cisco & Trend Micro: Friends, Lovers or Still Contemplating the 29 Dimensions of Compatibility on eHarmony.com?

Cisco Turns to Trend Micro for Router Security

Interesting title -- and one that's appropriately bold (pun intended.)

I found this story (below) regarding the apparent renewal of vows between Cisco and Trend interesting because of what is perceived by many as somewhat of a strange on-going dating relationship between the two companies. 

Some might suggest that over the last few years, with Trend's inclusion as the A/V function of choice across many Cisco platforms and the NAC partnership, etc., that TM was looking to ultimately get bought by Cisco. It certainly appeared that way to me.  Perhaps the dowry was just too great, but it certainly looked like Cisco decided that monogamy wasn't in the cards.

When Cisco acquired IronPort, many felt that while they were specifically focused on messaging security, that the technology would be leveraged heavily across Cisco's product lines and the Trend partnership would eventually wane.

Trend is well known for both it's anti-virus/spyware/spam solutions as well as its web-based security gateways while IronPort is known mostly for the former (see below, however.) 

It's interesting to try and reconcile the commonalities between the two company's product offerings.  On the surface, they both claim to do similar sets of things -- even down to the reputation services elements of their products.

Here's what IronPort suggests they provide:

Email Security

The IronPort email security appliances are the most sophisticated systems available today. In production at eight of the ten largest ISPs and more than 20 percent of the world's largest enterprises, these systems have a demonstrated record of unparalleled security and reliability. The same code base that powers IronPort's most sophisticated customers is available in all of IronPort's email security appliances, to protect the email systems of enterprises of all sizes. More.

Web Security

The IronPort S-Series™ is the industry's fastest Web security appliance. The IronPort S-Series appliances combine a high-performance security platform with IronPort's exclusive Web Reputation technology and IronPort's breakthrough Dynamic Vectoring and Streaming™ (DVS) engine, a new scanning technology that enables signature-based spyware filtering. Robust management and reporting tools deliver ease of administration and complete visibility into threat-related activity. More.

...and yet exclusing the desktop reach, it's almost identical to what Trend Micro suggests they bring to the party. 

 

So if IronPort was supposed to be the content security play for Cisco, does this mean that their adaptabilty beyond messaging was either never in the cards or just isn't panning out as quickly as was hoped?

Specific activity in the Channel from Trend certainly seemed to imply there was a wave of panic regarding the long strategic partnership between the two companies after the acquisition and it was unclear how Trend might proceed should the couple "become friends" instead of lovers. 

That's not to say that Trend isn't a healthy company, but there was, and is, a lot riding on this relationship.

So today, we see this announcement (from CRN/ChannelWeb):

Cisco Systems Thursday unveiled plans to add content security services to its routers via an extended partnership with Trend Micro.

The San Jose, Calif.-based networking vendor plans soon to integrate Trend Micro technology into the operating system of its Integrated Services Routers (ISRs), adding services such as content filtering to its family of branch office routers, said Tom Russell, senior director of Cisco's Security Technology Group.

The new offering, which will be available "in the near future," will make it easier for channel partners to build layered security solutions, as the ISR family already supports several integrated security options, Russell said. It will also help push content security out to remote locations, he added.

"You need to have content security at the central site, but you also have to distribute it to all of the points in the network," he said.

Cisco and Cupertino, Calif.-based Trend Micro have been working together since 2004. Trend Micro content security technology is already incorporated into Cisco's Adaptive Security Appliance family of unified threat management wares.

Trend Micro is also a partner in Cisco's Network Admission Control initiative and offers its own Damage Cleanup Services for the Cisco MARS (Mitigation, Analysis and Response System) platform.

Interesting, eh?  The ASA's were looking like the beginning of a UTM platform of choice for Cisco, but given the popularity of the ISR and the integration of certain WAN/Branch Office functionality (not to mention install base,) this makes sense.

So we're back to figuring out where the intersection of IronPort and Trend lays.  It certainly seems that this announcement sees the happy couple holding hands again and leaves me more confused about IronPort in the long term now instead of Trend.  I also seem to recall that IronPort utilized Sophos' AV engine...perhaps that will/has changed?

I continue to go to shows where the IronPort brand (and booth) is still separate from Cisco's and the IronPort website is still brand discrete (albeit with a "...part of Cisco" graphic) which is a little odd.  I thought IronPort was going to be the leveraged integrated content security play for them?

It wouldn't be the first time I'm confused by Cisco's acquisition integration strategy.

/Hoff

VMware to Open Development of ESX Virtual Switches to Third Parties...Any Guess Who's First?

On the tail of my posts from a week or so ago regarding to Cisco's Data Center 3.0 announcement, Mr. Chamber's keynote at VMWorld and the follow-on $150Million investment in VMware, here's something that really gets my goose honking because the force is strong with this one...

Virtualization.info broke the news last week that VMware will "...allow 3rd party vendors to develop their virtual switches for ESX Server virtual network, and Cisco is expected to be the first company announcing such product (Virtual Catalyst?)"

This may sound like a no-brain yawner, but it's quite profound...not just for Cisco, but for any of the switch vendors who want in on the lucrative virtualization market.

For a quick refresher, let's review the concept of virtual switches (vSwitches).  From VMware's definition:

A virtual switch, vSwitch, works much like a physical Ethernet switch. It detects which virtual machines are logically connected to each of its virtual ports and uses that information to forward traffic to the correct virtual machines. A vSwitch can be connected to physical switches using physical Ethernet adapters, also referred to as uplink adapters, to join virtual networks with physical networks. This type of connection is similar to connecting physical switches together to create a larger network. Even though a vSwitch works much like a physical switch, it does not have some of the advanced functionality of a physical switch. For more information on vSwitches, see Virtual Switches.

Given my previous posts on the matter, this offers two interesting and profound perspectives on the virtualization front:

1. If you recall, I blogged back in February about my participation in a Goldman Sachs Security conference where Jayshree Ullal presented Cisco's vision of virtualized security.  During the Q&A period after her presentation, I asked her a somewhat loaded question that went something like this:
   
   If now we see the consolidation of multiple OS and applications on a single VM host in which the bulk of traffic and data interchange is between the VM's themselves and utilize the virtual switching fabrics (ed: software) in the VM Host and never hit the actual physical network infrastructure, where, exactly, does this leave the self-defending "network" without VM-level security functionality at the "micro perimeters" of the VM's?
   
   I think that this announcement pretty much answers this question.  Cisco will take the concept that I blogged about previously wherein they will abstract the software from the hardware and provide a virtualized version of a catalyst as the ESX vSwitch.  I wager we will see a subset of security functionality in the vSwitch natively that one might expect in the "physical" Catalyst hardware products as much of the capabilities still hinge on new components such as the ACE.
   
   Now, if the virtual switch is Cisco's, you can expect a bevy of interaction between the "virtual switch(es)" and the physical ones that the VM Hosts connect to.  This would provide interfaces between all manner of network controls and monitoring capacities such as firewalls, IDS, IPS, SEIM, and solve the issue above by merely "offloading" this functionality via API's to the physical boxes plumbed into the network.
   
   Combine that with NAC agents on the hosts and...whether or not it actually works is neither here nor there.  They told they story and here it is.  It's good to be king.
   
   
2. This brings us to point numero dos...and it's a doozy.  If you think that the current crop of L2/L3 switching and routing infrastructure is fragile enough, just imagine how much fun it's going to be trying to detect and defend against infrastructure attacks on virtual switches that open up the guts of the VM hosts and hypervisors to third parties.
   
   We won't need a Blue Pill, I'll take one of these below, instead (it's a cyanide capsule, btw):
   
   Ettercap and arp-twiddling, anyone?  If you don't have the capability to virtualize the functional equivalent of IDS taps and/or utilize "IPS" plugins to the hypervisors, compromising a single guestOS on a VM could spell disaster that goes undetected.  We already have issues protecting physically isolated critical infrastructure, can you imagine how much fun this is going to be? 
   
   I'm not talking about application layer attacks here, I'm talking layer 2/layer 3.  The vicious circle begins anew.  You'll be worrying about XSS and AJAX attacks on your virtualized web servers whilst the same attacks from 10 years ago will give your shiny new virtual infrastructure a wedgie.
   
   And since it's likely we'll see a repeat of architectural car crashes as we have in the past, most of the inter-VM traffic won't be mutually authenticated or encrypted, either.  So you've got that going for you...

So, I think that this model is what Reflex was aiming for with their vIPS (from Virtual Iron) software for the virtual switch which I blogged about here, but Cisco's going to one-up them because of their investment in VMware, their switching acumen and the unfair advantage of owning both the virtual/logical switching/routing plane as well as the physical.

Good times are comin', for sure.  I'm trying not to be cynical.  I think it's fairly obvious as to what ought to be done to secure this mess before it becomes one, but I'm not sure we're going to be able to step out in front of this train and stop it before it reaches the station.

/Hoff

Follow-Up to My Cisco/VMWare Commentary

 

Thanks very much to whomsoever at Cisco linked to my previous post(s) on Cisco/VMware and the Data Center 3.0 on the Cisco Networkers website! I can tell it was a person because they misnamed my blog as "Regional Security" instead of Rational Security... you can find it under the Blogs section here. ;)

The virtualization.info site had an interesting follow-up to the VMware/Cisco posts I blogged about previously.

DataCenter 3.0 is Actually Old?

Firstly, in a post titled "Cisco announces (old) datacenter automation solution" in which they discuss the legacy of the VFrame product in which they suggest that VFrame is actually a re-branded and updated version software from Cisco's acquisition of TopSpin back in 2005:

Cisco is well resoluted to make the most out of virtualization hype: it first declares Datacenter 3.0 initiative (more ambitiously than IDC, which claimed Virtualization 2.0), then it re-launches a technology obtained by TopSpin acquisition in April 2005 and offered since September 2005 under new brand: VFrame.

Obviously the press release doesn't even mention that VFrame just moved from 3.0 (which exist since May 2004, when TopSpin was developing it) to 3.1 in more than three years.

In the same posting, the ties between Cisco and VMWare are further highlighted:

A further confirmation is given by fact that VMware is involved in VFrame development program since May 2004, as reported in a Cisco confidential presentation of 2005 (page 35).

Cisco old presentation also adds a detail about what probably will be announced at VMworld, and an interesting claim:

...VFrame can provision ESX Servers over SAN.

...VMWare needs Cisco for scaling on blades...

This starts helping us understand even further as to why Mr. Chambers will be keynoting at VMWorld'07.

Meanwhile, Cisco Puts its Money where its Virtual Mouth Is

Secondly, VMware announced today that Cisco will invest $150 Million in VMware:

Cisco will purchase $150 million of VMware Class A common shares currently held by EMC Corporation, VMware's parent company, subject to customary regulatory and other closing conditions including Hart-Scott-Rodino (HSR) review. Upon closing of the investment, Cisco will own approximately 1.6 percent of VMware’s total outstanding common stock (less than one percent of the combined voting power of VMware’s outstanding common stock).  VMware has agreed to consider the appointment of a Cisco executive to VMware's board of directors at a future date.

Cisco’s purchase is intended to strengthen inter-company collaboration towards accelerating customer adoption of VMware virtualization products with Cisco networking infrastructure and the development of customer solutions that address the intersection of virtualization and networking technologies. 

In addition, VMware and Cisco have entered into a routine and customary collaboration agreement that expresses their intent to expand cooperative efforts around joint development, marketing, customer and industry initiatives.  Through improved coordination and integration of networking and virtualized infrastructure, the companies intend to foster solutions for enhanced datacenter optimization and extend the benefits of virtualization beyond the datacenter to remote offices and end-user desktops.

If should be crystal clear that Cisco and EMC are on a tear with regards to virtualization and that to Cisco, "bits is bits" and virtualizing those bits across the app. stack, network, security and storage departments coupled with a virtualized service management layer is integral to their datacenter strategy.

It's also no mystery as to why Mr. Chambers is keynoting @ VMWorld now, either.

/Hoff

Cisco Responds to My Data Center Virtualization Post...

"...I will squash him like a liiiiittle bug, that Hoff!"

OK, well they weren't responding directly to my post from last night, but as they say in the big show, "timing is everything."

My last blog entry detailed some navel gazing regarding some interesting long term strategic moves by Cisco to further embrace the virtualized data center and the impact this would have on the current and future product roadmaps.  I found it very telling that Chambers will be keynoting at this year's VMWorld and what this means for the future.

Not 8 hours after my posting (completely coincidental I'm sure ;) the PR machine spit out the following set of announcements from Networkers Cisco Live titled "Cisco Unveils Plans to Transform the Data Center."    You can find more detailed information from Cisco's web here.

This announcement focused on outlining some of the near-term (2 year) proofpoints and touts the introduction of "...New Data Center Products, Services and Programs to Support a Holistic View of the Data Center." 

There's an enormous amount of data to digest in this announcement, but the interesting bits for me to focus on are the two elements pertaining to security virtualization as well as service composition, provisioning and intelligent virtualized service delivery.   This sort of language is near and dear to my heart.

I'm only highlighting a small subsection of the release as there is a ton of storage, data mobility, multiservice fabric and WAAS stuff in there too.  This is all very important stuff, but I wanted to pay attention to the VFrame Data Center orchestration platform and the ACE XML security gateway functions since they pertain to what I have been writing about recently:

If you can choke back the bile from the  "Data Center v3.0" moniker:

...Cisco announced at a press conference today its vision for next-generation data centers, called Data Center 3.0. The Cisco vision for Data Center 3.0 entails the real-time, dynamic orchestration of infrastructure services from shared pools of virtualized server, storage and network resources, while optimizing application performance, service levels, efficiency and collaboration.
...

Over the next 24 months, Cisco will deliver innovative new products, programs, and capabilities to help customers realize the Cisco Data Center 3.0 vision. New products and programs announced today support that vision, representing the first steps in helping customers to create next-generation data centers.

Cisco VFrame Data Center

VFrame Data Center (VFrame DC) is an orchestration platform that leverages network intelligence to provision resources together as virtualized services. This industry-first approach greatly reduces application deployment times, improves overall resource utilization, and offers greater business agility. Further, VFrame DC includes an open API, and easily integrates with third party management applications, as well as best-of-breed server and storage virtualization offerings.

With VFrame DC, customers can now link their compute, networking and storage infrastructures together as a set of virtualized services. This services approach provides a simple yet powerful way to quickly view all the services configured at the application level to improve troubleshooting and change management. VFrame DC offers a policy engine for automating resource changes in response to infrastructure outages and performance changes. Additionally, these changes can be controlled by external monitoring systems via integration with the VFrame DC web services application programming interface (API).

I think that from my view of the world, these two elements represent a step in the right direction for Cisco.  Gasp!  Yes, I said it.  While Chambers prides himself on hyping Cisco's sensitivity to "market transitions" it's clear that Cisco gets that virtualization across both the network, host and storage is actually a real market.  They're still working the security piecem however they, like Microsoft, mean business when they enter a space and it's no doubt they're swinging to fences with VFrame. 

I think the VFrame API is critical and how robust it is will determine the success of VFrame.  It's interesting that VFrame is productized as an appliance, but I think I get what Chambers is going to be talking about at VMWorld -- how VFrame will interoperate/interact with VMWare provisioning and management toolsets. 

Interestingly, the UI and template functionality looks a hell of a lot like some others I've blogged about and is meant to provide an umbrella management "layer" that allows for discovery, design, provisioning, deployment and automation of services and virtualized components across resource pools of servers, network components, security and storage:

Cisco VFrame Data Center components include:

• Cisco VFrame Data Center Appliance: Central controller that connects to Ethernet and Fibre Channel networks
• Cisco VFrame Data Center GUI: Java-based client that accesses application running on VFrame Data Center Appliance
• Cisco VFrame Web Services Interface and Software Development Kit: Programmable interface that allows scripting of actions for Cisco VFrame Data Center
• Cisco VFrame Host Agent: Host agent that provides server heartbeat, capacity utilization metrics, shutdown, and other capabilities
• Cisco VFrame Data Center Macros: Open interface that allows administrators to create custom provisioning actions

That's ambitious to say the least.

It's still a raucous debate with me regarding where a lot of this stuff belongs (in the network or as a service layer) and I maintain the latter.  Innovation driven by companies such as 3Tera demonstrate that the best ideas are always copied by the 800 pound gorillas once they become mainstream.

Enhanced Cisco ACE XML Gateway Software

The new Cisco Application Control Engine (ACE) Extensible Markup Language (XML) Gateway software delivers enhanced capabilities for enabling secure Web services, providing customers with better management, visibility, and performance of their XML applications and Web 2.0 services. The new software includes a wide variety of new capabilities and features plus enhanced performance monitoring and reporting, providing improved operations and capacity planning for Web services secured by the Cisco ACE XML Gateway.

I'd say this is a long overdue component for Cisco; since Chambers has been doing nothing but squawking about Web2.0, collaboration, etc., the need to integrate XML security into the security portfolio is a must, especially as we see XML as the Internet-based messaging bus for just about everything these days.

All in all I'd say Cisco is doing a good job of continuing to push the message along and while one shouldn't see this faint praise as me softening my stance on Cisco's execution potential, it's yet to be seen if trying to be everything to everyone will deliver levels of service commensurate with what customers need.

Only time will tell.

/Hoff

 

Cisco & VMWare - The Revolution will be...Virtualized?

During my tour of duty at Crossbeam, I've closely tracked the convergence of the virtualization strategies of companies such as VMWare with Cisco's published long term product direction. 

One of the selfish reasons for doing so is that from a product-perspective, Crossbeam's platform provides a competitively open, virtualized routing and switching platform combined with a blade-based processing compute stack powered by a hardened, Linux based operating system that allows customers to run the security applications of their choice. 

This provides an on-demand security architecture allowing customers to simply add a blade in order to add an application service component when needed.

Basically this allows one to virtualize networking/transport, applications/security contexts and security policies across any area of the network into which this service layer is plumbed and control the flows in order to manipulate in serial or parallel the path traffic takes through these various security software components.

So that's the setup.  Yes, it's intertwined with a bit of a commercial, but hey...perhaps liberty and beer are your idea of "free," but my blogoliciousness ain't.  What's really interesting is some of the deeper background on the collision of traditional networking with server virtualization technology.

While it wasn't the first time we've heard it (and it won't be the last,) back in December 2006, Phil Hochmuth from Network World wrote an article that appeared on the front page which was titled "Cisco's IOS set for radical pricing, feature changes."  This article quoted Cliff Metzler, senior vice president of the company’s Network Management Technology Group as saying these very important words:

Cisco’s intention is to decouple IOS software from the hardware it sells, which could let users add enhancements such as security or VoIP more quickly, without having to reinstall IOS images on routers and switches. The vendor also plans to virtualize many of its network services and applications, which currently are tied to hardware-specific modules or appliances.

This shift would make network gear operate more like a virtualized server, running multiple operating systems and applications on top of a VMware-like layer, as opposed to a router with a closed operating system, in which applications are run on hardware-based blades and modules. Ultimately, these changes will make it less expensive to deploy and manage services that run on top of IP networks, such as security, VoIP and management features, Cisco says.

“The way we’ve sold software in the past is we’ve bolted it onto a piece of hardware, and we shipped [customers] the hardware,” Metzler said. “We need more flexibility to allow customers to purchase software and to deploy it according to their terms.” 

IOS upgrades require a reinstall of the new software image on the router or switch — which causes downtime — or, “we say, not a problem, UPS will arrive soon, here’s another blade” to run your new service or application, Metzler said. “This adds months to the deployment cycle, which is not good for customers or Cisco’s business.”

The article above fundamentally demonstrates the identical functional software-based architecture that Crossbeam offers for exactly the right reasons; make security simpler, less expensive, easier to manage and more flexible to deploy on hardware that scales performance-wise.

Now couple this with the announcement that John Chambers will be delivering a keynote at VMWorld and things get even more interesting in a hurry.  Alessandro Perilli over at the Virtualization.info blog shares his perspective on why this is important and what it might mean:

Chambers presence possibly means announcement of a major partnership between VMware and Cisco, which may be related to network equipment virtualization or endpoint security support.

Many customers in these years prayed to have capability to use virtual machines as routers inside VMware virtual networks. So far this has been impossible: despite Cisco proprietary IOS relies on standard x86 hardware, it still requires a dedicated EEPROM to work, which VMware doesn't include in its virtual hardware set. Maybe Cisco is now ready to virtualize its hardware equipment.

On the other side VMware may have a deal in place with Cisco about its Assured Computing Environment (ACE) product: Cisco endpoint security solution called Network Admission Control (NAC) may work with VMware ACE as an endpoint security agent, eliminating any need to install more software inside host or guest operating systems.

In any case a partnership between VMware and Cisco may greatly enhance virtual infrastructures capabilities.

This is interesting for sure and if you look at the way in which the demand for flexibility of software combined with generally-available COTS compute stacks and specific network processing where required, the notion that Cisco might partner with VMWare or a similar vendor such as SWSoft looks compelling.  Of course with functionality like KVM in the Linux kernel, there's no reason they have to buy or ally...

Certainly there are already elements of virtualization within Cisco's routing, switching and security infrastructure, but many might argue that it requires a refresh in order to meet the requirements of their customers.  It seems that their CEO does.

I think that this type of architecture looks promising.  Of course, you could have purchased it 6 years ago -- as you can today -- by talking to these folks. But I'm biased. ;)

/Hoff

Network Intelligence is an Oxymoron & The Myth of Security Packet Cracking

[Live from Interop's Data Center Summit]

Jon Oltsik crafted an interesting post today regarding the bifurcation of opinion on where the “intelligence” ought to sit in a networked world: baked into the routers and switches or overlaid using general-purpose compute engines that ride Moore’s curve.

I think that I’ve made it pretty clear where I stand.   I submit that you should keep the network dumb, fast, reliable and resilient and add intelligence (such as security) via flexible and extensible service layers that scale both in terms of speed but also choice.

You should get to define and pick what best of breed means to you and add/remove services at the speed of your business, not the speed of an ASIC spin or an acquisition of technology that is neither in line with the pace and evolution of classes of threats and vulnerabilities or the speed of an agile business. 

The focal point of his post, however, was to suggest that the real issue is the fact that all of this intelligence requires exposure to the data streams which means that each component that comprises it needs to crack the packet before processing.   Jon suggests that you ought to crack the packet once and then do interesting things to the flows.  He calls this COPM (crack once, process many) and suggests that it yields efficiencies -- of what, he did not say, but I will assume he means latency and efficacy.

So, here’s my contentious point that I explain below:

Cracking the packet really doesn’t contribute much to the overall latency equation anymore thanks to high-speed hardware, but the processing sure as heck does!  So whether you crack once or many times, it doesn’t really matter, what you do with the packet does.

Now, on to the explanation…

I think that it’s fair to say that many of the underlying mechanics of security are commoditizing so things like anti-virus, IDS, firewalling, etc. can be done without a lot of specialization – leveraging prior art is quick and easy and thus companies can broaden their product portfolios by just adding a feature to an existing product.

Companies can do this because of the agility that software provides, not hardware.  Hardware can give you scales of economy as it relates to overall speed (for certain things) but generally not flexibility. 

However, software has it’s own Moore’s curve or sorts and I maintain that unfortunately its lifecycle, much like what we’re hearing @ Interop regarding CPU’s, does actually have a shelf life and point of diminishing return for reasons that you're probably not thinking about...more on this from Interop later.

John describes the stew of security componenty and what he expects to see @ Interop this week:

I expect network intelligence to be the dominant theme at this week's Interop show in Las Vegas. It may be subtle but its definitely there. Security companies will talk about cracking packets to identify threats, encrypt bits, or block data leakage. The WAN optimization crowd will discuss manipulating protocols and caching files, Application layer guys crow about XML parsing, XSLT transformation, and business logic. It's all about stuffing networking gear with fat microprocessors to perform one task or another.

That’s a lot of stuff tied to a lot of competing religious beliefs about how to do it all as Jon rightly demonstrates and ultimately highlights a nasty issue:

The problem now is that we are cracking packets all over the place. You can't send an e-mail, IM, or ping a router without some type of intelligent manipulation along the way.

<nod>  Whether it’s in the network, bolted on via an appliance or done on the hosts, this is and will always be true.  Here’s the really interesting next step:

I predict that the next bit wave in this evolution will be known as COPM for "Crack once, process many." In this model, IP packets are stopped and inspected and then all kinds of security, acceleration, and application logic actions occur. Seems like a more efficient model to me.

To do this, it basically means that this sort of solution requires Proxy (transparent or terminating) functionality.  Now, the challenge is that whilst “cracking the packets” is relatively easy and cheap even at 10G line rates due to hardware, the processing is really, really hard to do well across the spectrum of processing requirements if you care about things such as quality, efficacy, and latency and is “expensive” in all of those categories.

The intelligence of deciding what to process and how once you’ve cracked the packets is critical. 

This is where embedding this stuff into the network is a lousy idea. 

How can a single vendor possibly provide anything more than “good enough” security in a platform never designed to solve this sort of problem whilst simultaneously trying to balance delivery and security at line rate? 

This will require a paradigm shift for the networking folks that will either mean starting from scratch and integrating high-speed networking with general-purpose compute blades, re-purposing a chassis (like, say, a Cat65K) and stuffing it with nothing but security cards and grafting it onto the switches or stack appliances (big or small – single form factor or in blades) and graft them onto the switches once again.   And by the way, simply adding networking cards to a blade server isn't an effective solution, either.  "Regular" applications (and esp. SOA/Web 2.0 apps) aren't particularly topology sensitive.  Security "applications" on the other hand, are wholly dependent and integrated with the topologies into which they are plumbed.

It’s the hamster wheel of pain.

Or, you can get one of these which offers all the competency, agility, performance, resilience and availability of a specialized networking component combined with an open, agile and flexible operating and virtualized compute architecture that scales with parity based on Intel chipsets and Moore’s law.

What this gives you is an ecosystem of loosely-coupled BoB security services that can be intelligently combined in any order once cracked and ruthlessly manipulated as it passes through them governed by policy – and ultimately dependent upon making decisions on how and what to do to a packet/flow based upon content in context.

The consolidation of best of breed security functionality delivered in a converged architecture yields efficiencies that is spread across the domains of scale, performance, availability and security but also on the traditional economic scopes of CapEx and OpEx.

Cracking packets, bah!  That’s so last Tuesday.

/Hoff

Cisco as a Bellweather...where's all the commentary?

(Ed.: I wanted to clarify that issues external to security vulnerabilities and advanced technology most definitely caused the impact and commentary noted here -- global economic dynamics nothwithstanding, I'm just surprised at the lack of chatter around the ol' Blogosphere on this)

From the "I meant to comment on this last week" Department...

A couple of weeks ago, analyst reports announced that Cisco was indicating a general slow-down of their enterprise business and they were placing pressure on the service provider business units to make up the difference.  Furthermore, deep discounts to the channel and partners were crafted in order to incentivize  Q2 customer purchases:

Cisco is headed for a disappointing quarter, according to a cautionary research note issued Monday from a research analyst, reports Barron's Online.

Samuel Wilson, an analyst at JMP Securities writes that the slow down in U.S. enterprise business during Cisco's fiscal second quarter has continued into its current quarter, according to Barron's.

According to the Barron's story: "Wilson writes that 'according to resellers, top Cisco sales staff have recently expressed concerns about making their April quarter numbers.” He says that the company has apparently increased “partner-focused incentives' designed to shift business in from the July quarter. 'Based on the past three months, many resellers now believe that U.S. enterprises have begun to delay discretionary spending above and beyond normal seasonality typical of the [calendar] first quarter.'

Wilson also wrote that Cisco has cut headcount and expenses in its enterprsie switching business unit. He forecasts Cisco's fiscal third quarter revenue to be $38.1 billion, down from the consensus estimates of $39.4 billion, according to Barron's.

Given how Cisco is a bellweather stock for not only IT but in many case an indicator of overall enterprise spend trends, why isn't there more concern in the air?  Maybe it's just rumor and innuendo, but when analysts start press releases about Mr. Chambers' neighborhood, they're usually pretty conservative.

Rothman practically needed a Wet-Nap when he commented on Cisco's Q1 announcement (Cisco Takes it to the Next Level) but nary a word from the "All things including the kitchen sink will go into a Cat65K" camp on this news?  What, no gleeful prognostication on rebounds or doom?

Interestingly, from here, Goldman advises to buy ahead of Q3 announcement:

We believe that management will put concerns around slower U.S. large cap tech spending to rest. It represents only 13% of sales and we believe is seeing indications of a rebound. We believe management is likely to reaffirm positive longer-term trends in emerging markets, new technologies and the impact of video on networks as key drivers of sustained double-digit top-line growth.

We'll see.  Focusing on all the advanced technology projects and not focusing on core competencies can bite a company -- even Cisco -- when they least expect it.  Couple that with the continued vulnerabilities in their security products (another one today across Pix/ASA) and I'd say folks might start talking...

I wonder how the security products have weathered through all this?

...but that's just me.  Lash away, boys.

/Hoff