VMware's NSX End Game

While I was at VMworld last week, NSX was the talk of the town. Server folks were excited that VMware was addressing a pain point for them in the build-out of applications. Network people were nervous because they were unsure what this meant for them in the long run. Almost everyone was talking about who VMware would (and more importantly wouldn't) be partnering with to bring NSX to the realm of switches.

This last point had me a bit confused at first. Why would a physical switch need to integrate with NSX to decapsulate packets? Aren't all communications in NSX essentially host-to-host? Thanks to the power of the Internet, I had my answer in a few minutes. That answer then really got me thinking about what VMware's end game is for network integration.

NSX agents on Top of Rack (ToR) switches have nothing to do with network integration at layer 2. It has everything to do with service enablement. Right now, if you want to pass traffic for a particular VM through a load balancer or firewall, you have to ensure the traffic path for that conversation transits those devices. That means a transparent bump in the wire or a layer 3 hop that forces the traffic through that device before coming back to the target host.

With NSX, I can encapsulate that traffic in a vWire, or a VXLAN tunnel, and send it hurtling toward the destination. If I want to make that traffic hit a physical switch or load balancer, I need to push the traffic out of the vWire somehow. As of today, that's done by loading an agent on a ToR switch and decapsulating the traffic there. Then, the switch pushes the traffic to the service appliance before sending it on its merry way.

[NSX makes a strong play for SDN, but there are drawbacks. Find out more in "VMware NSX Caution Signs."]

That's not what VMware wants in the end. VMware would be much happier having direct integration between the host and the service appliance. Rather than running an agent on the ToR switch for decapsulation, VMware would rather have the agent run directly on the firewall or load balancer. That way, a particular service policy in NSX could push traffic to the appropriate device and ensure delivery and compliance without disturbing the underlying network. The physical switching plant serves as a simple transmission network, not unlike the electrical power infrastructure.

This also makes it easy for VMware to integrate that device as a virtual resource down the road. If there is an agent on the physical firewall to decode NSX vWires, then having an agent running on a virtual instance of the same software is easy to do as well.

Eventually, VMware would rather have the virtual appliance running as a service instance that can be called rather than a full-fledged network function virtualization (NFV) device. A service plugin for NSX is much easier to configure than traffic rules pointing packets to a physical or virtual host with a routing table.

There are already instances of this starting to come into play for the VMware partner vendors. I talked to Silver Peak right before VMware. Reps showed me their Agility WAN optimization software and its integration with NSX. Rather than go through the traditional configuration that requires layer 3 hops and complicated logical wiring diagrams, Silver Peak has partnered with VMware to offload the traffic to an Agility instance running in concert with NSX. This is a point-and-click configuration for virtualization admins today. It enables service generation and configuration with a minimum of effort.

Silver Peak is aiming for a service-oriented approach to WAN optimization in the future. They want to handle everything for their customers without a second thought. VMware would like that too.

Imagine an "app store" approach to service instantiation. If you want to use Palo Alto firewalls with Silver Peak WAN optimization but use the standard NSX load balancer, you would be able to configure it all with a few clicks. If you don't have the Silver Peak software locally, the vApp Store would go out and download it after prompting you to setup a payment structure for the service. You could provision an entire enterprise network overlay with a few clicks and a credit card. NSX takes care of the gory details of configuring traffic redirection on the back end. The partner vendors are happy to be getting service revenue. Everyone is happy.

VMware wants to involve service platforms in NSX to give customers choice. The underlay transport is less important to them. Whether it be HP, Arista, or Cisco it will all function just like the electrical grid or the interstate highway system. It's all just a transport interconnection for higher level services. ToR switch agents are a means to an end, not the end goal. When more service platforms start integrating NSX agents, you'll see VMware start to integrate them more fully into NSX offerings in the future.

Would you use a third-party plugin for your NSX services? Do you think that NSX integration with the underlay network is the way forward for VMware? Let me know in the comments below.

[Emerging technologies are transforming networks. Don't miss Greg Ferro's workshop "Building Your Network for the Next 10 Years" at Interop New York this October to get insights into the technology foundations of the next-generation data center.]