What software-defined networking changes
Software-defined networking (SDN) is a way of building a network in which one program decides the rules and the switches only carry them out. It matters because a hundred switches can then be changed by changing one place.
A school that blocks a website on every switch used to log in to every switch. With SDN it writes the rule once.
By the end of this lesson
Note
I can say what a controller decides and what a switch does.
Key words
| Word | What it means |
|---|---|
| Packet | one small piece of data sent over a network |
| Data plane | the part that moves each packet on its way |
| Control plane | the part that decides where packets should go |
| Flow table | the list of rules a switch looks through |
| Controller | a program that writes the rules for switches |
| Software-defined networking | a network whose rules are written by a controller |
The cells students fill in are left blank in this preview.
One part decides and one part carries
Every network device does two kinds of work.
The control plane decides: which port leads to which computer. The data plane carries out: it takes a packet in on one port and sends it out of another, fast, with no thinking.
Think of a bus station. The timetable office decides the routes. The drivers just follow them.
Worked example: the jobs of a school switch
| Job | Plane | Why |
|---|---|---|
| Work out that the library printer is on port 7 | Control | It is a decision |
| Send a print job out of port 7 | Data | It carries a packet |
| Add a rule that blocks a game server | Control | It changes the rules |
| Drop a packet from the game server | Data | It follows a rule |
The cells students fill in are left blank in this preview.
Why the two planes were split
In a traditional switch both planes sit in one box. Each box decides alone, so a hundred boxes mean a hundred separate settings.
SDN moves the deciding out into a controller, one program for the whole network. The switch keeps only the carrying. The controller sends it rules, and the switch stores them in its flow table.
A common mistake
Warning
Many people think the controller carries the traffic. It does not. The controller only writes rules. The switches carry every packet that a rule already covers, so most traffic never waits for the controller.
See the planes in your own lab
Your lab is one Ubuntu machine with a software switch called br0, made by Open vSwitch, and three computers named h1, h2 and h3.
First you build it with no controller and empty its flow table. Then you ask the switch two questions, and finally you connect a controller. Press Start the lab and run each command in turn.
Rebuild the lab with no controller
sudo sdnlab flowsShown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
Empty the flow table
sudo ovs-ofctl -O OpenFlow13 del-flows br0Shown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
List the flows
sudo ovs-ofctl -O OpenFlow13 dump-flows br0 --no-statsShown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
What the switch does with no rule
sudo ovs-vsctl get-fail-mode br0Shown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
Which controller is connected
sudo ovs-vsctl get-controller br0Shown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
A switch with no rules and no controller
The flow table is empty, so the list printed nothing. The fail mode is secure, which means the switch may do only what a flow allows.
The last command printed nothing either: no controller is connected. This switch has a data plane and nobody to give it rules, so it drops every packet.
Connect the lab's own controller
sudo sdnlab controllerShown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
Which controller is connected now
sudo ovs-vsctl get-controller br0Shown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
List the flows again
sudo ovs-ofctl -O OpenFlow13 dump-flows br0 --no-statsShown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
The controller wrote the first rule
The controller is now at tcp:127.0.0.1:6653: a TCP connection to port 6653 on this same machine. As soon as the switch connected, the controller wrote one rule.
It has priority 0, which is the lowest, and its action is CONTROLLER: send every packet that no better rule covers to me. The switch carries, and it asks the controller whenever it does not know. To put the lab back as it was, run sudo sdnlab flows.