Real-World SDN, Lesson 2: Conquer The Enemy Within

Organizations often face internal struggles when getting started with software-defined networking (SDN). Even if an enterprise has decided to use SDN, it does not mean they have agreed on how to implement it, and this can create conflict. Microsoft has experienced many of these issues firsthand operating its own SDN for Azure, Office365, and its other cloud services, which I introduced in the first part of this series.

When Microsoft Azure was in development in the mid-2000s, our architects asked themselves the same questions you should be asking yourself about SDN. Nowadays, Azure supports thousands of new customers and tens-of-thousands of network changes every single day. I'd like to share some of the best practices our architects created. They can help you make educated recommendations to your team and eliminate ambiguity.

Should I use hardware-based or software-based networking components?
Unless you move your entire infrastructure to the cloud, you will never replace all your physical networking devices. However, you should try to buy the software version of any new networking component as changes can be delivered faster though software. Many vendors have built the physical device's logic, such as load-balancing algorithms, directly into a software application that can be run inside a virtual machine, known as network functions virtualization (NFV).

This means that when the infrastructure needs to scale out and deploy a new networking component, it can be done immediately and automatically by the highly-available and centralized SDN management solution. Hardware devices are usually faster, and if you go this route, ensure the device can be remotely and automatically managed.

Should I use STT, NVGRE, VXLAN, or some other protocol?
One of the biggest debates within companies is over which protocol to use for SDN. Often this is due to the misassumption that the company's hypervisor will define the protocol, which can guide the organization in the wrong direction. In the animal world, there is a parasite called the green-banded broodsac, which grows inside a snail and gradually takes over its body, creating a "zombie snail." Once the parasite is large enough, it changes the snail's behavior and guides it into unnatural areas where it is exposed to predators. When picking a protocol, don't let previous hardware investments or people in your own organization misguide you to the wrong protocol, like the zombie snail.

There are three competing protocols that have been submitted to the Internet Engineering Task Force (IETF), the Internet standards organization. Stateless Transport Tunneling (STT) is an encapsulation protocol from Nicera, a company acquired by VMware. Virtual eXtensible Local Area Network (VXLAN) is a tunneling protocol supported by VMware, Cisco, Citrix, and Red Hat. Network Virtualization using Generic Routing Encapsulation (NVGRE) is another tunneling protocol supported by Microsoft, Intel, HP, and Dell. A few companies have even contributed to multiple protocols, making it tough to predict which will win the protocol war.

I recommend using the protocol that is the most interoperable with your current and planned investments, focusing on what is required for your business application or solution. These vendors in question are seeing the benefits of helping their customers realize the simplicity and economics that SDN offers and are moving towards supporting multiple protocols that can exist on the same network.

There is a misassumption that Microsoft's System Center Virtual Machine Manager will only ever work with NVGRE and that VMware's vCenter will only ever work with VXLAN, but now both companies are promoting interoperability. They have realized that none of their customers benefit from creating fragmented networking architectures, especially when many of them are using multiple hypervisors.

Microsoft and VMware are both participating in industry standards groups like the IETF, the Open Networking Foundation (ONF), Distributed Management Task Force (DMTF), and the OpenDaylight Project. In February, these companies, along with Intel and Red Hat, jointly submitted a draft for the Generic Network Virtualization Encapsulation (GENEVE) protocol, which will enable networks to span diverse infrastructure. Cisco and Microsoft have also proposed a draft for the ACI OpFlex Protocol, another open, standards-based protocol for Cisco's networking infrastructure. You should consider using whichever protocol becomes accepted as the most open and interoperable.

To summarize today's lesson, Symon says to use virtualized networking devices, use the most interoperable protocol to conquer the enemy within, and not become a zombie snail! Next I will be discussing the importance of the application when deploying software-defined networking.