faz1.com blog

There has been a lot of discussion about the Enterprise Stack and if any one vendor will ever own the whole thing. While that is a grand vision for any of the companies named below (and sure to bring applause from their shareholders on “analyst” day), I simply don’t see customers ever allowing it to become reality.  Customers don’t want to be locked in.  In my opinion, the virtual enterprise stack is what will win, but there will be lots of different vendor choices up and down that stack….and by the way, it probably won’t actually be hosted in the Enterprise DC (but that is another discussion).

Via: What is the Enterprise Stack?

For the first part of this year, customers are voting with their wallets and they are choosing…..drum role…..everyone (see How Much Integration Is Too Much in the Cloud?).  Unlike the Internet bubble burst back in 2000/2001 where companies like Cisco stole market and revenue share from the rest of the networking industry during the recovering, this recovery looks like it might be shaping up to be a little different.  Back in 2001, the technology didn’t really evolve very much between the time of the burst to the point where the recovery really kicked in.  Sure, it got faster and cheaper, but architectures fundamentally stayed the same (they just got some new bells and whistles).  Blade servers started to emerge and networks saw a lot of movement from 100M to 1G at the access layer but virtualization hadn’t really kicked in yet.  Since November of 2008, customers have had a lot of time to reevaluate their entire IT stack AND a lot of new architectural solutions have emerged.  Amazon’s EC2 and Rackspace’s Cloud Hosting have given customers direct access to more cost effective data center resources that they can access on demand.  Google Apps have given companies big and small complete business solutions (email, docs, spreasheets, sites, etc) that can be spun up and online the same hour the company opens it’s doors.  VMware’s vNetwork Distributed Swith/Cisco’s Nexus 1000V, OpenFlow & Open vSwitch, HP’s Virtual Connect, Palo Alto Networks NG Enterprise Firewalls, Cisco’s Nexus 5000/2000 combination (foundational to Cisco UCS)  and Arista’s 7×00 w/ vEOS are all examples of fundamentally new capabilities introduced since the downturn which customers can now leverage to harness their increasingly complex and highly virtualized data centers.

The point is that customers today are faced with much greater IT challenges than they were in 2008 and the technologies are dramatically different…not necessarily all of them better, but definitely different.  And, there are a lot of new IT solutions warming up their engines to go out on track for the first time and see what types of lap times they can turn in.  Should be fun!

I am trying to get my company’s session approved for this year’s VMWorld.  When you aren’t a Platinum sponsor, it is a little bit more difficult to get these things pushed though.  So, I am asking for help from anyone who has a VMWorld account to go and vote for the session.  Many of you have been asking me what Nicira is up to.  This session is a great way to find out.  Here are the session details and link to cast your vote.

Cast your vote here

Title: Reworking the Network to Support Today’s Virtualization & Cloud Demands

I have been a little quiet here for the past 2 months since VMWorld in San Francisco in September. The Nexus 1000V team has been very busy this past quarter working with customer (we have added over 400 new customers in this period) and preparing for our next release which is going to post to Cisco CCO in the first part of December.  I am happy to report that HP got it’s facts straight about how the Nexus 1000V really does work with their Virtual Connect and Flex-10 solutions (it might have been the Cisco video we posted showing the solutions working together that helped things along – see below).

Also, I have been surprised that there has not been much noise following all the announcements made at VMworld 2009 about an “open” vswitch or any of the management veneers that promised to make a standard VMware vSwitch support all of the features of the Nexus 1000V.  Maybe Santa will bring us a gift and deliver some specific product details this holiday season so we can understand what these solutions really can or can’t do.

Over the past few months, I have gotten a lot of request for information about leveraging the Nexus 1000V and vSphere to support a DMZ environment.  In my previous post, I discussed many of the security features of the Nexus 1000V that enable customers to virtualize their DMZ servers and applications.

Once of the questions that I did not address in my previous post and will attempt to address in this post is the following: 

With the Nexus 1000V which only supports 1 VEM per host, how can I replicate the security segmentation I have today with separate vSwitches inside the same ESX host?

In this case, the customer was using a common VMware infrastructure for both DMZ-based VM’s and Intranet-based VM’s.  They had separate physical networks for the DMZ and Intranet.  They use multiple vSwitches inside a single host assigned to separate NICs to isolate the different traffic types to the proper physical network from within the ESX host.

The customer was considering deploying the N1Kv and wanted to know how to accomplish this same type of virtual network separation.  Initially, they wanted the ability to run multiple VEM’s on the same ESX host, but this is not a supported deployment model for the N1KV VEM.  Now, there are a couple of ways to deploy the Nexus 1000V to support this deployment scenario.  The best way is to create multiple system uplink port-profiles (DMZ uplink profile, Intranet uplink profile and Mgmt uplink profile) and then map the DMZ VLANs to the DMZ uplink profile, Intranet VLANs to the Intranet uplink profile and Console and vMotion VLANs to the MGMT uplink profile.

Once the uplink port-profiles are properly configured, the customer can then leverage regular port profiles mapped to each of the “domains” that they want to support; one or more profiles for DMZ VM access and one or more for Intranet VM access.  To ensure HA, the customer can also leverage VPC-Host Mode and 1 port from each uplink port profile to each of 2 different upstream physical switches.  Here is a good diagram to demonstrate this connectivity (thanks to Jason Makar, a Cisco CSE for drawing it up and asking about this customer deployment scenario):

N1KV in a DMZ

Now while this does show how to support a DMZ deployment with the Nexus 1000V, it doesn’t specifically address the question “Can a single Nexus 1000V VEM implementation be as secure as if I were to leverage separate vSwitches for different connectivity requirements?”

The short answer is yes and we do get this question quite a bit since moving from vSwitches to VLANs is generally somewhat new to customers who started out with VMware networking.  Below is a great explanation provided by the primary architect behind the Nexus 1000V and general virtualization and linux expert Mark Bakke.  You can watch Mark describing the Nexus 1000V here.

“Software-wise, even though there is only one VEM on the host, the VEM is just the forwarding software, and having more than one won’t necessarily give the customer more separation, just like multiple VMware vSwitches all run through the same VMware forwarding software.  So separation of traffic just comes down to the piece of software (vSwitch or VEM) and how it keeps traffic separate.  The VMware vSwitch software keeps traffic separate by keeping track of multiple vSwitches.  Each vSwitch is just a data structure saying what ports are connected to it (along with other information).  Traffic is only forwarded between ports in the same vSwitch. The N1KV does the same thing with VLANs – each VLAN is a data structure that says which ports are members.  Traffic is forwarded only between ports in the same VLAN.  So while using vSwitches “sounds” more compartmentalized than N1KV VLANs, they provide equivalent separation, as long as VLANs and port profiles are set up correctly.  If the VLANs share physical ports via tagging, the N1KV takes care of all of the VLAN tagging so the networks stay separate in the physical switches as well.  All port channels keep this separation as well.  If a customer wants separate physical ports for the VLANs, this is also done through port profiles on the physical ports to limit which VLANs are allowed on each one.  The method described above of creating multiple uplink port profiles and VM port profiles to keep these separate is a solid design and is the most straightforward method for this environment.”

As you can see, the Nexus 1000V adds advanced switching and security features to it’s single “vSwitch per host” deployment model to support even the most demanding customer DMZ environments.  For secure segmentation, a single Nexus 1000V VEM implementation leveraging VLANs is equally secure to the multiple VMware vSwitch implementation.  Add in the Nexus 1000V advanced security, visibility and diagnostic features and customers can virtualize even more applications than ever before.  This is truly a case where less is more.  Now you’re cookin’ with gas!

For those looking for some more reading, a great white paper about leveraging the Nexus 1000V for DMZ virtualization can be found here.