Have you heard of OpenFlow? Have you heard of vPath? Over the past few months, I’ve been thinking about how they are related to each other when it comes to, yup, you guessed it --- Software Defined Networking (SDN).
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?
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?
vPath is a strategic Cisco technology used in Cisco virtual switch deployments; it is a semi *closed* or proprietary technology that offers a way to redirect or steer traffic flows in Nexus 1000V environments. It is not directly doing this communicating to the forwarding table, but rather using a service policy. Similar result, but done different when compared to OpenFlow environments. While it is a Cisco technology, Cisco is allowing 3rd parties to integrate virtual services with vPath. Two of these include Citrix and Imperva. You will start to see vPath is Cisco’s way to enable policy based traffic steering in virtual environments. However, it isn’t used to broadly enable traffic steering or take over full control plane functionality – rather, it is used to steer traffic to and between virtual service nodes (VSN) such as the Cisco Virtual Security Gateway (VSG).
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?
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.
vPath uses an overlay tunnel to transport traffic from each VEM (1000V linecard) to and between virtual service nodes (VSN). This enables the VSN to be Layer 3 adjacent to the virtual switch. Using an overlay approach also allows service-chaining of various virtual services. Using vPath defined policies, traffic is steered in the direction that is required to offer a particular service or chain of services. Since overlays are used as part of vPath, the physical network requires only L3 forwarding between virtual services. vPath overlays inter-connect software virtual switches to software virtual service network appliances. Interesting and cool use of overlays, right? This can come in handy for dynamic service insertion.
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.
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.
RSS Feed
