Manage Learn to apply best practices and optimize your operations.

An introduction to SDN can help server admins reach across silo lines

At a time when the software-defined data center promises to blur the lines of IT silos, it's important for server admins get an introduction to SDN.

Software-defined networking (SDN) is blurring the lines between traditional IT silos. Today, even server admins should get an introduction to SDN to help the business grow and to avoid conflicts that are likely to arise between server and networking teams.

Popular server virtualization suites offer advanced networking features and the option of a distributed switch, so what's the reason behind the push for deeper SDN, and why would the network team be interested, beyond connecting the virtual server infrastructure to the physical network?

Keith TownsendKeith Townsend

The answer to the question lies in the fact that the virtual infrastructure is becoming the default infrastructure -- a concept I'm calling the virtual-first data center. It's a big feather in the virtualization industry's cap to note that virtual ports outnumber physical ports. This is important, not just because of the growing importance of managing the virtual network but also because the requirements of virtual-first data centers for interacting with the physical networking infrastructure differ from the requirements of non-virtualized or partially virtualized data centers.

Network-specific challenges include tracking the location of production workloads within the physical infrastructure. Orchestration and automation enable horizontal scaling and can request both network and compute services based on the needs of the application. This isn't an approach for just virtual servers; it also allows for big data applications that scale their physical footprints based on the size of the data. The ability to have what are called northbound and southbound application programming interfaces (APIs) from the virtual network to the physical network is what enables these new capabilities. Vendors have two basic methods to provide this advanced networking: software-based and hardware-based approaches.

Software-based products, such as VMware's NSX and the Juniper-sponsored OpenContrail, implement a virtual overlay of the networking fabric. You can take the concept of the distributed switch and expand it not only to the virtual hosts, but also to the physical network.

VMware recently noted that it has a customer with more than 7,000 ports on a single virtual switch. So, software-based virtual networks are very scalable, and you can build a virtual network that meets the needs of just about any enterprise footprint.

Vendors such as Cisco prefer to take a hardware approach to a software-based overlay. In a hardware-based approach, the programmable nature of SDN is provided via northbound APIs to the hardware. Cisco's Application Centric Infrastructure (ACI) is scheduled to be released later this year.

Choosing a software or hardware approach

There are some challenges in selecting one approach over another. Basically, it's a debate about Cisco application-specific integrated circuits versus software. Hardware-based solutions have the advantage of supporting multiple hypervisors. The wider hypervisor support is due to the separation of the controller from the hypervisor. The drawback, of course, is that you are relying on hardware, which requires hardware upgrades. Software-based approaches can be implemented on almost any physical network as long as the hypervisor is supported.

If you are part of an organization that has a large virtual server footprint and you haven't embraced SDN or are still using basic virtual switches, it may be time to have a conversation with the network team to discuss a more involved, collaborative relationship. There's a misconception that networking teams don't understand virtualization, and this introduction to SDN can be helpful for both sides.

Network professionals have understood and even embraced virtualization concepts for years. The concepts of virtual LANs, Multiprotocol Label Switching overlays and VPNs have been around much longer than x86-based compute virtualization. The difference and the friction come in the complete abstraction of the underlying hardware within the physical data center.

In the case of software-based network virtualization, it's an operational challenge for two different teams to manage different aspects of the logical network. While the overall logical network remains under the domain of the network team, the physical underlay is split: The network team manages the physical switches and routers that provide connectivity, but the server team often manages the virtual switch, which is provided by the hypervisor. This can create the appearance of control issues.

It's important to include the network team in discussions with potential SDN vendors. The topic of discussion should be the challenges and solutions to operational (and political) issues that might arise. This shouldn't be too foreign a concept to network teams. Hardware vendors have been using virtualized switch platforms for a long time at this point. So, it's not uncommon for the network team to have a similar operating model for large switching environments, such as virtual device contexts in a Cisco Nexus fabric. It's a conversation that can be successful if you are well prepared and are willing to do a little research in your introduction to SDN.

Software-defined networking is the next logical technology for the virtual-first data center. Armed with the proper use cases and conversation points for you network counterparts, SDN can be a realistic option for most organizations.

Dig Deeper on Network virtualization

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Is VMware (NSX) or Cisco (ACI) taking the better approach to software-defined networking?
Interesting to see the view from a virtualization maestro's perspective. I think the salient punch line - that the networking and virtualization teams need to be in cahoots rather than act as adversaries - is correct. As the world moves closer to overlays, the virtual and physical worlds will need to come together. Things like underlay pinning will be important in helping manage the underlying transport. And the implications to monitoring and troubleshooting are profound if the virtual and physical are not connected.

This means that customers need to be somewhat clever about the questions they ask. It is not just about abstracting out the network. People need to think through the operational implications:
- How does this impact my provisioning workflows?
- What about troubleshooting?
- Monitoring and billing?
- How will my network evolve from a scale perspective?
- Can I use any converged management tools?

Good stuff though. This is exciting.

Mike Bushong (@mbushong)