NETWORKING

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

Microsoft's Symon Perriman offers advice about SDN implementation based on his own company's experience with SDN components and protocols.

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.

Reports

Comments

Network Computing

User Rank: Apprentice

Mon, 08/25/2014 - 11:16

VXLAN

Thank You for the blog @Symon, although i haven't got chance to work on VXLAN but my understanding says its lot similar to VLAN with added feature as that it can take complete advantage of layer 3 routing.

Nice introduction, Symon - I suspect you could have gone on for another hundred pages or so on this particular discussion ;-)

"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."

This is a fair enough position - we should always ideally use the solution that best suits our needs and our environment. I think though that while the market is still perceived as being highly segregated (and you touched on this with your comments about Microsoft and VMWare too) some may be afraid to commit to a particular solution because they're worried about making the "wrong" choice and being left behind. The sooner we see either a widely-agreed "winner" or wide-ranging multi-protocol support, the easier it is to commit to implementing.

Very true, it is hard to know which solution to invest in today. Just make sure it is one of those companies that has showed they're committed to open protocols, then you should always have the option to connect to a different procol or layer in the future.

In the fifth blog in this series I'll talk about how everyone can influence these vendors to support openness.

Some good points ClassC. I'm seeing a lot of progress in convincing software vendors to adopt open standards, but it will still take time. We encourage YOU (the customer) to make these requests of your different software vendors, as that helps build the momentum. Stay tuned for the fifth blog in this series where I'll talk about different ways to engage and influence these vendors.

"...I think though that while the market is still perceived as being highly segregated (and you touched on this with your comments about Microsoft and VMWare too) some may be afraid to commit to a particular solution because they're worried about making the "wrong" choice and being left behind."

@jgherbert A very point. This is very tough decision which might cause many not to act at all - if I had to choose between the two I would probably go with the MS solution though, but I could be wrong ( it wouldn't be the first time ) and then what ?

Social engineering, ransomware, and other sophisticated exploits are leading to new IT security compromises every day. Dark Reading's 2016 Strategic Security Survey polled 300 IT and security professionals to get information on breach incidents, the fallout they caused, and how recent events are shaping preparations for inevitable attacks in the coming year. Download this report to get a look at data from the survey and to find out what a breach might mean for your organization.