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.
Other methods to make sure of logical traffic isolation include firewalls or virtual private networks (VPNs). However, since network overlays need to be independent of the physical network, these security services need to be virtual, as well. In the Nexus 1000V portfolio, the virtual security services include the virtual security gateway (VSG) and ASA 1000V cloud firewall, as well as the Imperva SecureSphere web application firewall (WAF) announced this week and coming later this year.
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.
Finally, our good friend Andre Kindness over at Forrester Research, who we have a lot of respect for, tweeted this out last week regarding SDN:
What do you think? Are you ready for SDN? What about virtual overlays?