Networking Guide

Software-defined networking (SDN) is an approach to computer networking that allows network administrators to manage network services through abstraction of lower-level functionality. While server workloads have been migrated into virtual environments, they’re still just servers looking for a network connection to let them send and receive data. SDN meets this need by moving networking equipment (such as routers and switches) into the same virtualized space. If you’re already familiar with basic networking concepts, then it’s not much of a leap to consider that they’ve now been virtualized just like the servers they’re connecting.

This book intends to give administrators an understanding of basic administration and troubleshooting tasks in Part 1, and explores the advanced capabilities of OpenStack Networking in a cookbook style in Part 2. If you’re already comfortable with general networking concepts, then the content of this book should be accessible to you (someone less familiar with networking might benefit from the general networking overview in Part 1).

Software-defined networking (SDN) allows engineers to deploy virtual routers and switches in their virtualization environment, be it OpenStack or RHEV-based. SDN also shifts the business of moving data packets between computers into an unfamiliar space. These routers and switches were previously physical devices with all kinds of cabling running through them, but with SDN they can be deployed and operational just by clicking a few buttons.

In many large virtualization environments, the adoption of software-defined networking (SDN) can result in political tensions within the organisation. Virtualization engineers who may not be familiar with advanced networking concepts are expected to suddenly manage the virtual routers and switches of their cloud deployment, and need to think sensibly about IP address allocation, VLAN isolation, and subnetting. And while this is going on, the network engineers are watching this other team discuss technologies that used to be their exclusive domain, resulting in agitation and perhaps job security concerns. This demarcation can also greatly complicate troubleshooting: When systems are down and can’t connect to each other, are the virtualization engineers expected to handover the troubleshooting efforts to the network engineers the moment they see the packets reaching the physical switch?

This tension can be more easily mitigated if you think of your virtual network as an extension of your physical network. All of the same concepts of default gateways, routers, and subnets still apply, and it all still runs using TCP/IP.

However you choose to manage this politically, there are also technical measures available to address this. For example, Cisco’s Nexus product enables OpenStack operators to deploy a virtual router that runs the familiar Cisco NX-OS. This allows network engineers to login and manage network ports they way they already do with their existing physical Cisco networking equipment. Alternatively, if the network engineers are not going to manage the virtual network, it would still be sensible to involve them from the very beginning. Physical networking infrastructure will still be required for the OpenStack nodes, IP addresses will still need to be allocated, VLANs will need to be trunked, and switch ports will need to be configured to trunk the VLANs. Aside from troubleshooting, there are times when extensive co-operation will be expected from both teams. For example, when adjusting the MTU size for a VM, this will need to be done from end-to-end, including all virtual and physical switches and routers, requiring a carefully choreographed change between both teams.

Network engineers remain a critical part of your virtualization deployment, even more so after the introduction of SDN. The additional complexity will certainly need to draw on their skills, especially when things go wrong and their sage wisdom is needed.