Networking

07:00 AM
Symon Perriman
Symon Perriman
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
50%
50%

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.

As Microsoft's worldwide technical lead covering virtualization, infrastructure, management, and cloud, Symon Perriman is an internationally recognized industry expert, author, keynote presenter, and technology personality. He started in the technology industry in 2002 and ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Page 1 / 2   >   >>
SymonPerriman
50%
50%
SymonPerriman,
User Rank: Apprentice
9/24/2014 | 2:59:42 PM
Re: VXLAN
Hi Abe,

Thanks for the feedback.  Which certifications would you like to see Microsoft (and others) offer for free?

Thanks,
Symon
AbeG
50%
50%
AbeG,
User Rank: Ninja
9/24/2014 | 2:33:29 PM
Re: VXLAN
@Symon.  "I use the Microsoft solutions...but I may be biased :)"

 

I feel the same way.  This is why I argue that some vendor certifications should be free.  I'm a walking advertisement for the Microsoft products that I am certified in.
SymonPerriman
50%
50%
SymonPerriman,
User Rank: Apprentice
9/15/2014 | 1:11:11 PM
Re: VXLAN
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.
SymonPerriman
50%
50%
SymonPerriman,
User Rank: Apprentice
9/15/2014 | 1:06:43 PM
Re: VXLAN
I use the Microsoft solutions...but I may be biased :)
ClassC
50%
50%
ClassC,
User Rank: Ninja
9/13/2014 | 11:30:58 PM
Re: VXLAN
@Symon    I am really surprise we still have to convince companies to adopt an open standard. The IoT is pushing companies hard to no longer ignore the fact that openness will be the only way to go.

It won't be easy, since companies are based on "trade secretes" but it will be interesting to learn just how SDN will influence this perspective.
ClassC
50%
50%
ClassC,
User Rank: Ninja
9/13/2014 | 11:24:36 PM
Re: VXLAN
"...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 ?
SymonPerriman
50%
50%
SymonPerriman,
User Rank: Apprentice
9/2/2014 | 6:50:23 PM
Re: VXLAN
Thanks for sharing that link.
SymonPerriman
50%
50%
SymonPerriman,
User Rank: Apprentice
9/2/2014 | 6:47:35 PM
Re: VXLAN
Hi jgherbert,

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.

Thanks,
Symon
jgherbert
50%
50%
jgherbert,
User Rank: Ninja
8/27/2014 | 9:38:23 PM
Re: VXLAN
@aditshar1> Yes, but with caveats.

Ivan Pepelnjak wrote a nice piece about Layer 2 Data Center Interconnect technologies here (piece the URL back together yourself):

 blog.ipspace.net/2014/08/revisited-layer-2-dci-over-vxlan.html

Worth a read, especially to ensure that the issues around traffic 'tromboning' are understood.
aditshar1
50%
50%
aditshar1,
User Rank: Ninja
8/27/2014 | 2:33:22 PM
Re: VXLAN
As VXLAN can extend the address space, which will also help in moving VM's across across long distance.
Page 1 / 2   >   >>
Cartoon
Slideshows
Audio Interviews
Archived Audio Interviews
Jeremy Schulman, founder of Schprockits, a network automation startup operating in stealth mode, joins us to explore whether networking professionals all need to learn programming in order to remain employed.
White Papers
Register for Network Computing Newsletters
Current Issue
2014 Private Cloud Survey
2014 Private Cloud Survey
Respondents are on a roll: 53% brought their private clouds from concept to production in less than one year, and 60% ­extend their clouds across multiple datacenters. But expertise is scarce, with 51% saying acquiring skilled employees is a roadblock.
Video
Twitter Feed