Nexus 1000V and Virtual Network Overlays Play Pivotal Role in Software Defined Networks

There’s an incredible amount of hype and excitement these days around Software Defined Networking (SDN), which promises to herald in a new age of flexibility, business agility and automation to our existing data center and campus networks. Since there are very few, if any, SDN networks in production environments today, though, we know there are a lot of implementation details to work out before the industry achieves the lofty benefits of network programmability. Cisco opened its kimono this week on its strategy around programmable networks (an even broader concept than what we believe the traditional definition of SDN is), called Cisco Open Network Environment. (Get Omar’s take on Cisco ONE).

If you are like a lot of people, you might think that SDN is synonymous with OpenFlow, the leading standards-based approach for SDN today. However, we are already seeing folks across the industry extending the SDN vision beyond what OpenFlow is currently envisioned to do, so we think the definition of SDN will probably evolve over the next year or so to include additional programming models and protocols. Cisco ONE, for example, includes three approaches to network programmability: 1) our own onePK set of API’s to Cisco network operation systems and devices, 2) a portfolio of agents and controllers that will support OpenFlow, among other things, and 3) our Nexus 1000V-based portfolio for building virtual network overlays.

If you are relatively new to the SDN concept, you probably already understand the OpenFlow model of separating the control plane and the forwarding plane, and building applications on top of the centralized controller. But, it may not be immediately obvious why overlay networks have arisen in parallel as a key complement or alternative to SDN/OpenFlow. Virtual network overlays partition a physical network infrastructure into multiple logically isolated networks that can be individually programmed and managed to deliver optimal network requirements. Virtual network overlays are the approach taken frequently by multitenant environments such as cloud service providers and multitenant data centers. Note that this description is not unlike the primary use case today for OpenFlow, which is campus network “slicing”, or partitioning the physical infrastructure with separately programmable OpenFlow overlays.

Much like OpenFlow defines a separate controller from the underlying network device, the Cisco Nexus 1000V virtual switch has two separate components, the virtual supervisor module (VSM) that acts as the control plane, and the virtual Ethernet module (VEM) that acts as the virtual switch forwarding plane. The concept and vision are very similar. In the new announcements this week, we are highlighting that the VSM will be programmable with northbound interfaces which will include OpenStack and REST API’s. Even OpenFlow, by comparison, has not nailed down what all of its northbound API’s will be for applications sitting on top of the controller.

One advantage of the Nexus 1000V towards building these virtual overlays is that it is consistent with the physical infrastructure from a management and policy perspective. Management consistency should apply across physical and virtual devices and scale to cloud proportions.

Another requirement is that since the network overlay is running on a shared network infrastructure, there must be a way to logically isolate network traffic and partition needed resources. This can be done with virtual local area network (VLAN) assignments, or in today’s modern scalable multitenant data centers, a more scalable version, VXLAN. VXLAN scales to over 16 million virtual networks in a single Layer 2 network domain, so we will not be running out of overlay partitions anytime soon in even the larger cloud environments. Other tunneling and partitioning approaches are viable as well.

Connecting traditional physical networks and campus LANs outside the data center requires the ability to connect the scalable VXLAN virtual networks to traditional VLAN segments. This effectively requires a VXLAN-VLAN gateway with the associated network identifier address translations and other services, which Cisco began discussing as part of its overlay infrastructure this week.

Cisco is excited about the new capabilities that network programmability will bring to our customers, as it promises to make the network a more strategic platform for business agility, even though this won’t be an overnight evolution. With the success that we’ve had with our Nexus 1000V portfolio over the last three years, and the new capabilities we are launching now, we think that these virtual network overlays are destined to play a key role in achieving the vision of programmable networks today and as this evolution plays out.

More details on Cisco’s virtual overlay technology can be found in our new white paper on the topic.

Some of the individuals posting to this site, including the moderators, work for Cisco Systems. Opinions expressed here and in any corresponding comments are the personal opinions of the original authors, not of Cisco. The content is provided for informational purposes only and is not meant to be an endorsement or representation by Cisco or any other party. This site is available to the public. No information you consider confidential should be posted to this site. By posting you agree to be solely responsible for the content of all information you contribute, link to, or otherwise upload to the Website and release Cisco from any liability related to your use of the Website. You also grant to Cisco a worldwide, perpetual, irrevocable, royalty-free and fully-paid, transferable (including rights to sublicense) right to exercise all copyright, publicity, and moral rights with respect to any original content you provide. The comments are moderated. Comments will appear as soon as they are approved by the moderator.