Currently in Migration - Jason Edelman's Old Blog
  • Home
  • About
  • Contact

OpenFlow, vPath, and SDN

4/11/2013

1 Comment

 
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?
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?

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.

1 Comment
Maya Wardle link
12/1/2020 06:42:14 am

Thanks for writting

Reply



Leave a Reply.

    Author

    Jason Edelman, Founder of Network to Code, focused on training and services for emerging network technologies. CCIE 15394.  VCDX-NV 167.


    Enter your email address:

    Delivered by FeedBurner


    Top Posts

    The Future of Networking and the Network Engineer

    OpenFlow, vPath, and SDN

    Network Virtualization vs. SDN

    Nexus 7000 FAQ

    Possibilities of OpenFlow/SDN Applications 

    Loved, Hated, but Never Ignored #OpenFlow #SDN

    Software Defined Networking: Cisco Domination to Market Education

    OpenFlow, SDN, and Meraki

    CAPWAP and OpenFlow - thinking outside the box

    Introduction to OpenFlow...for Network Engineers


    Categories

    All
    1cloudroad
    2011
    2960
    40gbe
    7000
    Arista
    Aruba
    Big Switch
    Brocade
    Capwap
    Christmas
    Cisco
    Controller
    Data Center
    Dell Force10
    Embrane
    Extreme
    Fex
    Hadoop
    Hp
    Ibm
    Isr G2
    Juniper
    Limited Lifetime Warranty
    Meraki
    Multicast
    N7k
    Nexus
    Nicira
    Ons
    Opendaylight
    Openflow
    Openstack
    Presidio
    Qsfp
    Quick Facts
    Routeflow
    Sdn
    Sdn Ecosystem
    Security
    Ucs


    Archives

    May 2015
    April 2015
    February 2015
    January 2015
    December 2014
    November 2014
    October 2014
    September 2014
    August 2014
    June 2014
    May 2014
    March 2014
    February 2014
    January 2014
    December 2013
    November 2013
    October 2013
    September 2013
    August 2013
    July 2013
    June 2013
    May 2013
    April 2013
    March 2013
    February 2013
    January 2013
    December 2012
    November 2012
    October 2012
    June 2012
    May 2012
    April 2012
    March 2012
    February 2012
    January 2012
    December 2011
    November 2011


    RSS Feed


    View my profile on LinkedIn
Photo used under Creative Commons from NASA Goddard Photo and Video