Separate the control plane from the data plane by hand

short · 35 min · Objective 1.8

Task

Use your lab router to see the two planes as separate things: change the control plane and watch the data plane's behaviour follow. SDN is defined by that separation, and the definition is much easier to hold once you have moved one without the other.

Steps

  1. On the router, look at the control plane: ip route show. That table is the router's decisions. Nothing in it moves a packet.
  2. Look at the data plane's effect instead: from Host A, ping -c 2 192.168.20.10, which succeeds because the forwarding hardware (here, the kernel) acts on those decisions.
  3. Change the control plane without touching any interface. Add a more specific route that sends one destination nowhere: sudo ip route add 192.168.20.10/32 blackhole.
  4. Ping again from Host A. It now fails, while 192.168.20.11 — if you have a second host there — still works. You changed a decision, and forwarding followed it, with no cable touched.
  5. Remove it: sudo ip route del 192.168.20.10/32. Confirm the ping recovers. Then write one sentence describing what an SDN controller would be doing in step 3 if this were a hundred switches rather than one.

Verify

ip route show
sudo ip route add 192.168.20.10/32 blackhole && ip route get 192.168.20.10
ping -c 1 -W 1 192.168.20.10; echo "exit $?"
sudo ip route del 192.168.20.10/32 && ip route get 192.168.20.10

ip route get is the key command: it asks the router what it would do with a packet for that destination. With the blackhole in place it must report unreachable, and the ping must fail; after the delete it must report the normal next hop again.

Notes

ip route get is the closest thing Linux has to asking the control plane a question directly, and it is the model for what an SDN controller offers at scale: one place that holds the decisions for the whole fabric, pushing forwarding entries down to devices that do nothing but forward.

The three planes the objective names map neatly here. Control is the route table. Data is the forwarding that acted on it. Management is the SSH session you typed the command into — which is why out-of-band management matters: losing the data plane should not lose your way in.