OpenFlow is one of the most widely talked about protocols in the world of SDN. It is simply an *open* protocol that enables the separation of the control and data planes of a network device. Most commonly, it is a protocol used between a controller and physical/virtual switch to remotely program device forwarding tables.
vPath on the other hand, isn’t as popular (yet?) and rarely discussed in SDN conversations, so what is it?
This means vPath makes it possible for the 1000V to get traffic that matches a certain policy (IP SRC / DEST) to then perform an action to forward that traffic to a virtual services node (VSN). Doesn’t this sound familiar? OpenFlow uses a MATCH/ACTION methodology. An OF action could be to forward out to a certain port or out a certain overlay.
Getting a big deeper…
vPath intercepts traffic coming from a VM, examines the associated service policy mapped to a VM port profile, and makes a decision. The traffic will be forwarded according to the MAC table or be re-directed by vPath. Using VSG as an example and assuming the traffic matches the policy defined, a single packet is re-directed to the VSG for inspection. Based on the policy rules defined on the VSG, an ACL is downloaded from the VSG to the 1000V Virtual Ethernet Module (VEM). This means that the first packet is in the “slow path” and all subsequent packets are in the “fast path.” Doesn’t this sound like an OpenFlow/SDN environment again?
In case you were wondering... “vPath maintains the state of the TCP flows. In the event of a reset (RST) event or a finish (FIN) flag in the TCP flow, vPath purges the entry of that flow from the table. Inactivity in any flow will also cause the entry to be cleared from the flow table.” Source: VSG Deployment Guide.
For a company like Cisco who probably wants to continue to sell large amounts of hardware, wouldn’t it make sense to offer vPath on physical Nexus switches (2K/5K/6K/7K) and physical network services (ASA, 3rd party LB)?
OpenFlow and vPath Recap
OpenFlow is a protocol that is used between a controller and switch to remotely program a forwarding table. Applications are written on top of a controller using Northbound APIs. One such application could be a packet filtering application or a light-weight firewall like VSG. In this model, another interface to the network device is still needed to configure the device, i.e. ovsdb, SNMP, CLI.
vPath is a technology that is used between Nexus virtual switches and virtual services nodes. Only a single packet (just like OF reactive flow policy) is sent to a VSN making it analogous to a OF/SDN controller. Slow path/Fast path exist in this model just like with SDN controller deployments. The Virtual Supervisor Module (VSM) for the 1000V is the means to configure the virtual switch just like CLI, of-config, ovsdb is required to still configure switches in the standard SDN model.
My Take
Cisco has developed what they should be calling SDN technology. I don’t think it would be SDN washing. Competitors would clearly use it as FUD though because it is Cisco proprietary, but there is nothing wrong with that. It could always end up as a standard if it catches on. The same goes for the Cisco Virtual Supervisor module (VSM) in the 1000V solution; while not being called a controller, it will be the device managing VXLAN overlays very soon (common role of a SDN controller). vPath and VSM are two cases where a vendor needs to re-market or re-brand because unfortunately perception is reality. Cisco isn’t shipping any data center SDN products today. BTW, VMware’s equivalent products are definitely part of the Software Defined Data Center.
While my point was to draw some analogies between OpenFlow SDN and Cisco vPath environments, you can see the architectures are different. In the “open SDN” world, 3rd parties integrate network services on top of an OpenFlow controller. In the Cisco world, 3rd parties integrate talking directly to virtual switches using vPath overlays.
Closing Random Thoughts
Which is more scalable and allows for faster integration of 3rd party services/applications? Both seem to accomplish dynamic service insertion, but could vPath be opened up to do more than just steer traffic to virtual services nodes and take on more control plane functions? I wonder if another model is to leverage vPath between VEM and VSM and build services/applications on top of the VSM. Or, yet another option could be to put a virtual appliance onto VXLAN segments (dot1q for VXLAN?? or multiple vnics) and build service-chains by dynamically manipulating VXLAN overlays to get to a particular service. This could make it possible to use off the shelf virtual appliances without requiring weeks/months of development with 3rd party vendors rather to focus on building standard overlays as needed (as we can tell vPath is already doing this; it’s just changing the slow path by dynamically changing overlay associations to vswitch ports).
And how will Cisco’s ONE controller fit into all of this in the data center? That’s even a bigger question. Keep it simple: DC controller is VSM and Campus controller is ONE.