Networking Essentials: Software Defined Networking
This is the ninth in a series of class notes as I go through the free Udacity Computer Networking Basics course.
This is the first of a 3 part miniseries on Network Operations and Management.
Before we get to SDNs, a precursor on Network Management:
Network Management
Network Management is the process of configuring the network to achieve a variety of tasks:
- Load balancing
- Security
- Business Relationships
If the network is not configured correctly, many things can go wrong. Configuration mistakes can lead to problems like:
- Persistent Oscillation (routers dont agree how to route to a destination)
- Loops (packets get stuck between routers and don’t make it to a destination)
- Partitions (network split into two unconnected segments)
- Black Holes (packets reach a router that just drops it)
Configuration is hard because:
- Defining “correctness” is hard
- Interactions between protocols lead to unpredictability
- Humans make mistakes across hundreds of vendor specific low level configuration
Software Defined Networking changes this and centralizes logic in a single controller by providing:
- Network-wide views of Topology and Traffic
- Network-level objectives (eg Load balance and security)
- Direct Control
This means that the totally distributed model of routing we had before must end, routers no longer need to compute their own routes, aka Remove Routing from Routers.
Software Defined networking (SDN)
What is an SDN?
It helps to add a third dimension to the normally 2D conception of networks. We can define the basic job of the Data Plane of the network as forwarding traffic. But we can also define a Control Plane of the network which computes routing tables, which take into account the state of each router.
The Control Plane is the logic that controls forwarding behavior eg for routing protocols and network middlebox configuration.
The Data Plan simply forwards and switches traffic according to control plane logic.
In a traditional network, data and control planes are put on the routers. But in an SDN, control is centralized while data is still decentralized.
This idea started in 2004 as the Routing Control Platform for the BGP protocol and was generalized to 4 different planes soon after (”4D”):
- Decision Plane
- Dissemination/Discovery Planes
- Data Plane
This was made practical in 2008 with by switch vendors opening their API and adopting the Openflow protocol.
What are the advantages of SDN?
They are easier to:
- Coordinate
- Evolve (eg Virtual Machine migration in Data centers)
- Reason about
It is also easier to experiment by deploying experiments for research alongside existing networks.
Having a separate control plane allows us to apply software techniques to old networking problems. We write the Control Plane in a high level programming language like Python or C, and the Data Plane is programmable hardware that obeys OpenFlow control commands to operate the switch.
We can apply SDNs to Data centers, Backbone networks, Enterprise networks (where it is easier to write Security protocols), Internet Exchange Points, and Home Networks. We will focus on the first 3.
SDNs in Data Centers
Data centers consist of racks of servers (as many as 20k servers/cluster). If each server can run 400 VMs, thats 400k VMs in a cluster. It is a problem provisioning/migrating these machines in response to load. So the solution is to program switch state from a central database.
We also make the servers addressed with Layer 2 “flat” addressing - so a server can be migrated to another section of the data center without requiring the VM to obtain new addresses, and just updating the switch state, which is much easier to do.
SDNs and Internet Backbone Security
The goal is to filter attack traffic from DDoS attackers. If high traffic is detected, the controller (like RCP) might install a “null route” to ensure no more traffic reaches the victim from the attacker.
Challenges with SDNs
- Scalability: How do you scale > 1000’s of switches?
- Consistency: Ensuring different replicas see the same view
- Security/Robustness: how to recovery from failure/compromise?
More on OpenFlow, Nicira and its founder Martin Casado.
Different SDN Controllers
Some options
- Nox
- Ryu - a Python controller supporting OpenStack and 1.2+ versions of OpenFlow
- Floodlight - a Java controller
Higher level controllers
Nox
This is a first-generation OpenFlow controller. It is open-source, stable, and widely used. The NOX Architecture has a set of switches and a set of network-attached servers.
The basic abstraction that Nox supports is a switch control abstraction where OpenFlow is the prevailing protocol. Control is defined by the header of the packet as defined in the OpenFlow spec, which has:
- a header (10-tuple)
- counter: statistics on that flow
- actions: e.g. forward, drop, send to controller
When a switch receives a packet, it:
- updates its counter for that flow
- applies corresponding actions
NOX is event-based. The basic programmatic interface for the NOX controller which knows how to process different types of Events such as (Switch Join/Leave, or Packet In/Receive events). The controller also keeps a network view, which includes a view of the underlying topology, and also speaks a control protocol to the switches in the network, allowing it to update their state.
NOX provides good performance, but requires using low-level OpenFlow commands and C++. POX is a fork that uses Python and is higher level, for less good performance.
Next in our series
Hopefully this has been a good high level overview of how Software Defined Networking works. I am planning more primers and would love your feedback and questions on: