One rule, a hundred switches
A school decides that the guest Wi-Fi must never reach the finance computers. In an ordinary network somebody logs in to each switch and changes it by hand. In a software-defined network the switches only follow a table, and one program writes that table for all of them.
By the end of this lesson
Note
I can say what a flow does and what a controller adds.
Key words
- Flow: one rule in a switch, made of a match and an action.
- Flow table: the list of flows a switch looks through for each packet.
- Match: the part of a flow that says which packets it is for.
- Action: what the switch does with a packet that matches.
- Controller: a program that writes the flows for a switch.
- OpenFlow: the language a switch and its controller speak.
Starter: what you already know
Note
Answer in your head. 1. What does ping tell you? 2. What is a MAC address? 3. What does an ordinary switch do with a frame it has not seen before? You need the third answer in a moment.
Before you start
Note
Press Start the lab on the bar at the top of this lesson. This lab is a whole Ubuntu machine of your own, with a small network built inside it, so it takes a little longer to come up than a container. Each Run button types its command into the machine's terminal, one after another in the same session. If one says the machine is still starting, wait a few seconds and press it again. To watch them, or to type your own, press Open terminal on the bar.
A switch is a table you can read
Here the switch is br0, made by Open vSwitch. Three computers are plugged into it: h1, h2 and h3, each a separate network namespace with its own address. sdnlab status lists the switch, its three numbered ports, the computers and the flows. The last part is empty. Notice that the switch is in fail-mode secure, which says: do nothing the flows do not allow.
sudo sdnlab statusShown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
An empty table drops everything
An ordinary switch learns on its own. An OpenFlow switch does only what its flow table says. ovs-ofctl dump-flows prints that table, and it has no flows: only the header line comes back. So when h1 pings h2, the first packet finds no flow that matches and is dropped. The ping prints 100% packet loss.
sudo ovs-ofctl -O OpenFlow13 dump-flows br0Shown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
sudo ip netns exec h1 ping -c 1 -W 1 10.0.0.2Shown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
Check
Tip
Why did the ping fail when nothing is broken? Answer: the flow table is empty, so no flow matched the packet and the switch dropped it.
A common mistake
Warning
Many people think every switch learns where the computers are by itself. An ordinary Ethernet switch does. An OpenFlow switch does only what its flows say, and with no flows it forwards nothing. Whatever should learn, you or a controller has to write the flows.
Mininet builds a whole network
Mininet makes a test network on one machine: hosts, a switch and a controller, started and stopped for you. --test pingall pings between every pair of hosts and prints how many pings were dropped. Here the answer is 0% dropped (2/2 received). Its controller wrote the flows the switch needed. When Mininet ends it clears away every Open vSwitch switch, br0 included, so the next step builds the lab again.
sudo mn --mac --test pingallShown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
Check
Tip
Who made the pings work in Mininet? Answer: its controller, which told the switch what to do with the packets it did not know.
A controller writes the flows
sdnlab controller builds the lab again and connects br0 to a controller program on this machine. It is the unfinished one from your lab, and as given it sends every packet out of every other port, like a hub. Now the ping from h1 to h3 works. The table has one flow: priority=0 actions=CONTROLLER. It sends any packet with no better flow to the controller, and n_packets rises with every packet. Finishing this controller is part 3 of the lab.
sudo sdnlab controllerShown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
sudo ip netns exec h1 ping -c 2 -W 1 10.0.0.3Shown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
sudo ovs-ofctl -O OpenFlow13 dump-flows br0Shown here, not run. Create a free account to press Run and type it into your own lab’s terminal.
Now do the lab
Tip
You have seen an empty table, a controller and a switch that asks it about every packet. Your lab asks you to write the table by hand and then to teach the controller to learn, so most packets never leave the switch. Open the README.md in your home folder with cat README.md in the terminal.
Exit check
Tip
Answer without looking back. 1. What are the two parts of a flow? 2. What does an OpenFlow switch do with a packet when its table is empty? 3. What does a controller write? 4. Which command prints the flow table? Answers: a match and an action; it drops it; flows; ovs-ofctl dump-flows.
For teachers
Tip
This lesson is a small example of a lesson worked in a lab: the steps and the Run buttons are the lesson, and the lab is each student's own copy. This lesson is worked in a VM lab: each student has an Ubuntu machine of their own with a switch and three computers inside it, and a Run types into its terminal and shows what it printed. Key learning points: 1. A flow is a match and an action. 2. An OpenFlow switch with no flows drops everything. 3. A controller writes the flows. Common mistake: believing every switch learns by itself. Equipment: the lab and a browser. Tip: before the ping, ask the class what will happen and why. The lab itself has a check that marks the flow table and the learning switch. Copy it into your own module and change it, or build one from scratch with the Lab menu in the lesson builder.