18  Lab: OpenFlow Controller

reference-architectures
sdn
of
hands

18.1 Start With One Observable Rule

A controller lab is not finished when a command runs. It is finished when one packet event, one rule-table change, one counter movement, and one receiver result can be tied together.

Start simple: begin with known switch state, send one test packet, install one rule, and record what changed. That small proof is the base for every larger SDN experiment.

In 60 Seconds

This lab practices the behavior of an OpenFlow-style SDN controller without depending on a fragile external simulator. You will trace a packet miss, create a controller decision, install a scoped match-action rule, verify local forwarding, test timeout cleanup, add a priority exception, inject a controller-unavailable condition, and write the proof record that shows what happened.

18.2 Learning Objectives

By the end of this lab, you will be able to:

  • Trace a packet miss from switch observation to controller decision and rule installation.
  • Build a match-action rule with scope, priority, action, timeout, owner, and cleanup record.
  • Distinguish first-packet controller involvement from later local forwarding.
  • Test how timeout and priority choices affect rule state and protected traffic.
  • Record a lab result that separates controller intent, device acknowledgement, counter movement, receiver behavior, and rollback.

18.3 Quick Check: Controller Lab Boundaries

18.4 Minimum Viable Understanding

The lab is successful when every network behavior result is tied to observed proof.

Lab check route from lab question through packet event, controller decision, rule table update, forwarding result, timeout cleanup, and proof record.

SDN hands-on lab check route

Use this route:

  1. Ask the lab question: which traffic behavior should change and which paths must remain protected?
  2. Create the packet event: record ingress switch, packet class, existing rule state, and table miss or hit.
  3. Make the controller decision: check policy, topology, host group, conflicts, and rollback need.
  4. Install the rule: define match, priority, action, timeout, owner, and target switch.
  5. Observe the result: inspect acknowledgement, counters, receiver behavior, and protected exceptions.
  6. Clean up: expire or remove temporary rules and record the final state.

Do not treat a printed controller decision as proof. The proof record must include the installed rule and the observed forwarding result.

18.5 Lab Results Need a Rule Trace

An SDN lab result is credible when it connects a packet event to a controller decision, a rule-table change, a local forwarding result, and a cleanup state. The controller is important because it makes policy decisions, but the switch table and receiver outcome prove whether that decision became network behavior. In an OpenFlow-style exercise, the observable chain usually starts with a Packet-In or equivalent table-miss record, continues through a Flow-Mod request, and finishes with switch-side state, counters, and receiver proof.

The first packet and later packets answer different questions. A table miss shows when the controller had to decide. A later local match shows whether the installed rule actually carried the intended class without another controller round trip. Both observations are needed before the lab can claim that the control loop worked. For example, in a Mininet or Open vSwitch classroom setup, the useful evidence is not just that Ryu, OS-Ken, ONOS, or another controller printed a policy decision. The useful evidence is the installed rule visible in the switch, the matched-packet counter increasing on the next telemetry packet, the expected receiver log or packet capture, and no accidental capture of protected command traffic.

SDN lab proof record linking packet event, controller decision, rule acknowledgement, counter movement, receiver behavior, protected exceptions, cleanup, and conclusion.
Proof record fields turn a controller decision into a checked forwarding result.

This distinction matters because SDN labs can appear to work when they only prove reachability. A broad default rule might deliver the packet before the intended rule is tested. A stale rule from a previous exercise might hide the packet miss. A command-path exception might be masked by a lower-priority telemetry rule until the wrong packet class is replayed. The lab should therefore compare before-install state, after-install state, after-forwarding state, and after-cleanup state in one trace.

  • Packet miss: proves the local table did not already handle the event.
  • Flow-mod acknowledgement: proves the switch accepted the scoped rule.
  • Receiver and counter proof: proves later traffic used the rule and arrived where policy expected.
  • Cleanup proof: proves temporary lab behavior was removed before the next exercise.

18.6 Prove The Event Rule Loop

Write the lab record as a chain, not as a screenshot collection. Each row should name the traffic class, ingress switch, miss or hit state, controller policy reason, match fields, priority, action, timeout, owner, acknowledgement, counter movement, receiver result, and cleanup trigger. Missing fields usually mean the lab can demonstrate a packet but cannot explain the policy. A practical worksheet can have one row for the initial miss, one for the Flow-Mod acknowledgement, one for the repeated packet, and one for cleanup or rollback.

Use the protected command path as the safety check. A telemetry or update rule that makes a demo packet work can still be unsafe if it catches command traffic, outranks a containment rule, or survives after the lab condition ends. Priority exceptions, narrow match fields, and timeout cleanup keep the lab from proving the wrong behavior. Before installing a broad update rule, write the protected command match first: source group, destination service, protocol fields, higher priority, allowed action, and expected receiver. After the broad rule is installed, replay command traffic and record which rule counter moved.

If the lab uses Open vSwitch, useful commands include a flow-table dump before and after the event, a controller log line that identifies the Packet-In, a packet capture or receiver application log, and a final table dump after idle timeout, hard timeout, or explicit removal. If the lab uses cards or a spreadsheet instead of software, keep the same discipline: a rule is not accepted until a switch row records it, and a forwarding claim is not accepted until a counter and receiver row agree. Treat barrier acknowledgement, switch error messages, and Flow-Removed or expiry events as first-class lab evidence, not as optional details.

  • Before install: record known table state and the policy reason for changing it.
  • After install: record acknowledgement, counter movement, receiver behavior, and protected-path behavior.
  • After cleanup: record expiry or removal, final table state, and what the next matching packet does.

18.7 Priority and Timeout Risk

OpenFlow-style rules are not just routes. They are ordered state with match fields, priorities, actions, counters, and lifetime. A broad low-priority rule can be harmless in one exercise, while a broad high-priority rule can silently steal traffic from a protected exception. The lab has to prove match order as well as reachability. In a real switch pipeline, matching may involve table order, priority comparison, exact fields, wildcard fields, meters, groups, and output actions. The visible forwarding result is the end of that pipeline, not the whole proof.

Timeouts are part of the proof because controller decisions age. A temporary rule that never expires can make later tests inherit stale behavior. A rule that expires too early can force repeated controller involvement and hide data-plane behavior. Idle timeout, hard timeout, explicit removal, and reconciliation after controller recovery all describe what state remains trustworthy. The lab should also separate controller reachability from data-plane continuity: an installed rule may keep forwarding while the controller is unavailable, but a new table miss may be dropped, buffered, sent to a fallback rule, or fail closed depending on the switch and policy.

Asynchronous control messages create another hidden failure mode. A controller can emit a Flow-Mod before the switch has applied it, and a learner can resend traffic before the table has converged. That is why production-style labs often include a barrier reply, an acknowledgement or error event, and a later flow-table read. Counters then show whether the intended rule or a different overlapping rule handled the packet. After recovery from a controller outage, reconciliation compares controller intent with switch state: expired rules, stale counters, emergency defaults, and manually inserted rules must be explained before new policy is trusted.

  • Priority decides which matching rule wins.
  • Counters show which rule later packets actually used.
  • Reconciliation checks whether switch state still matches controller intent after outage or recovery.
  • Barrier and error handling keep controller intent separate from switch acceptance.

18.8 Prerequisites

Use these chapters as needed:

18.9 Lab Model

This lab uses a small lab model: one controller, three virtual switches, three traffic classes, and a shared proof record. You can run it with a worksheet, a spreadsheet, a local simulator, or classroom cards. The important part is the observed state transitions, not the tool.

Lab topology showing one controller, three virtual switches, telemetry devices, update traffic, protected command traffic, receiver services, and proof record.

SDN controller lab topology

Lab objects:

Controller

Owns topology, host groups, policy checks, rule decisions, timeout policy, counters, and lab proof.

Virtual switches

Hold local rule tables and report misses, acknowledgements, counters, and expiry events.

Traffic classes

Telemetry, update, command, management, and containment traffic are kept separate for checking.

18.10 Lab Materials

You need only a way to track state. Use a spreadsheet, shared document, whiteboard, or small local script.

Record these fields for each event:

  • Event id and traffic class.
  • Ingress switch and expected receiver.
  • Existing rule hit or table miss.
  • Controller decision and reason.
  • Match, priority, action, timeout, owner, and cleanup trigger.
  • Acknowledgement, counter movement, receiver result, and protected-path check.

18.11 Exercise 1: Baseline Packet Miss

Start with empty rule tables on all three switches. Send a telemetry packet into Switch 1.

Packet miss exercise showing packet ingress, empty table, packet-in event, controller state lookup, policy decision, and flow-mod rule installation.

Baseline packet miss in the lab

Expected observations:

  • Switch proof: table miss because no local rule matches the packet class.
  • Controller proof: packet event includes ingress switch, traffic class, source group, and requested receiver.
  • Policy proof: telemetry is allowed to the analytics receiver and does not conflict with protected command traffic.
  • Rule record: controller installs a narrow forwarding rule with owner, priority, timeout, and cleanup trigger.

The first event is slow because it needs a controller decision. The later matching events should use the installed local rule.

18.12 Exercise 2: Rule Table Entry

Create one rule from the baseline miss.

Flow table entry showing match fields, priority, action, timeout, owner, acknowledgement, counter, and cleanup state.

SDN lab flow table entry

Minimum rule fields:

  • Match: switch, ingress port, source group, destination service, traffic class, or packet fields used by the lab.
  • Priority: a value high enough to win against default behavior but lower than protected exceptions.
  • Action: forward, drop, queue, mirror, meter, rewrite, or send event.
  • Timeout: idle and hard cleanup behavior if the rule is temporary.
  • Owner: lab step, policy, incident, operator, or application that requested the rule.
  • Proof fields: acknowledgement, counter, receiver result, expiry, and rollback record.

If a rule cannot be explained in those terms, it is not ready to install.

18.13 Exercise 3: Local Forwarding Check

Send the same telemetry class again after the rule is installed.

Local forwarding counter proof showing a later telemetry packet matching the installed rule, switch-local action, counter movement, receiver evidence, and protected-path guardrail.

Local forwarding counter proof

Check:

  • The switch finds the matching rule.
  • The controller is not needed for the forwarding decision.
  • The rule counter moves.
  • The receiver gets the expected traffic.
  • Protected command and management paths are unchanged.

This exercise separates controller programmability from data-plane forwarding. The controller made the checked decision, then the switch handled matching traffic locally.

18.14 Exercise 4: Timeout Cleanup

Temporary rules should not become permanent by accident.

Timeout cleanup exercise showing idle timeout, hard timeout, rule expiry, counter record, removal acknowledgement, and table state after cleanup.

Timeout cleanup lab exercise

Test two cleanup paths:

Idle cleanup

Stop sending matching packets. The rule should expire when it has not matched for the configured idle period.

Hard cleanup

Keep sending matching packets. The rule should still expire if a hard limit requires periodic renewal.

Cleanup proof

Record expiry reason, final counter, affected traffic class, and the next packet behavior after removal.

After cleanup, a matching packet should create a new miss or follow a defined default rule.

18.15 Exercise 5: Priority Exception

Now add a protected command path. The command rule should override a broader telemetry or update rule.

SDN flow-table rules ordered by priority: a high-priority specific match forwards protected traffic, lower-priority rules match broader ranges, and a priority-zero wildcard sends unmatched packets to the controller.

Flow-rule priority decides which match wins: a narrow high-priority rule protects specific traffic while broader rules and the wildcard handle the rest.

Run it: Before you argue priority from the static figure, operate the flow-table lookup workbench below. Load the Overlapping Rules preset so a broad IoT-subnet rule and a specific command rule both match one packet, then Step through the lookup and watch the switch scan priority-ordered entries, ignore the lower-priority match, and let the highest-priority exception win. Read which counter increments to confirm the protected command rule carried the packet, then record which rule won and why in your proof.

Check:

  • The broader rule does not capture protected command traffic.
  • The higher-priority exception wins when multiple rules could match.
  • The command receiver still gets traffic after update or telemetry rules are installed.
  • The proof record states which rule won and why.

Priority is not a cosmetic number. It is part of the safety argument.

18.16 Exercise 6: Controller-Unavailable Drill

Simulate the controller being unavailable after safe rules are already installed.

Controller outage drill separating existing installed rule continuity, new unmatched traffic fallback behavior, controller recovery reconciliation, and proof record fields.

Controller outage drill proof loop

Expected behavior:

  • Existing matching traffic: continues according to installed local rules if the switch is healthy.
  • New unmatched traffic: follows the defined fallback policy, such as drop, buffer, or restricted default path.
  • Controller recovery: reconciles switch table state, counters, and expired rules before accepting new policy requests.
  • Proof: records what continued, what was blocked, what was buffered, and what changed after recovery.

This drill prevents the common mistake of assuming “controller down” means the same thing for existing and new flows.

18.17 Exercise 7: Lab Proof Record

Finish the lab by writing a compact record.

Lab proof record showing question, event, rule, acknowledgement, counters, receiver result, protected exceptions, cleanup, and conclusion.

SDN hands-on lab proof record

Use this template:

Lab question: prove reactive rule installation and safe cleanup
Traffic class: telemetry, update, command, or containment
Event: switch, ingress, miss or hit, packet class
Controller decision: state checked, policy result, protected exceptions
Rule: match, priority, action, table, timeout, owner
Device proof: acknowledgement, error, counter movement, expiry event
Outcome proof: receiver result and protected-path check
Cleanup: expiry, removal, rollback, and final table state
Conclusion: what behavior was proven and what remains unproven

18.18 Lab Variations

Use the same proof loop for deeper variants.

Lab variation map showing proactive rule, reactive rule, priority exception, timeout cleanup, controller unavailable drill, and proof comparison.

SDN hands-on lab variation map

Choose one:

  • Proactive rule: pre-install a known telemetry path and prove the first packet does not need a live controller decision.
  • Reactive rule: require a controller decision before a new update path is allowed.
  • Containment rule: install a high-priority drop or quarantine rule and verify protected services still work.
  • Timeout comparison: compare short-lived and longer-lived rules using table occupancy and event counts.
  • Recovery drill: remove the controller, observe existing rules, restore the controller, and reconcile state.

18.19 Knowledge Check

18.20 Check the Lab Proof

18.21 Match the Lab Artifact to Its Proof Role

18.22 Order the Hands-On Lab Sequence

18.23 Common Pitfalls

  • Confusing a demo with proof: screenshots or console text are not enough unless they connect rule acknowledgement to forwarding outcome.
  • Using broad matches: a broad update or telemetry rule can accidentally capture protected command or management traffic.
  • Ignoring priority: a correct action can still lose to another rule if priority and match scope are wrong.
  • Forgetting cleanup: temporary lab rules need expiry or removal, otherwise later exercises inherit stale behavior.
  • Testing only success: controller-unavailable and rule-rejection cases reveal whether the lab design has a safe fallback.
  • Treating named tools as the lesson: the concept is the event-rule-proof loop, not a specific controller, emulator, or board.

18.24 Summary

This hands-on lab practices the core SDN control loop: a switch observes a packet event, the controller checks state and policy, a scoped match-action rule is installed, later packets are forwarded locally, and the proof record shows the result. Strong lab work records rule owner, priority, timeout, acknowledgement, counters, receiver behavior, protected exceptions, cleanup, and rollback. The lab remains valid whether it is run with a worksheet, a local script, a classroom exercise, or a hardware simulator, because the trace target is the same: connect packet event to proof without overstating what was proven.

18.25 Key Takeaway

Hands-on OpenFlow work should leave proof of match fields, actions, priorities, counters, and rollback behavior rather than only a successful demo.

18.26 See Also

18.27 What’s Next

Continue to OpenFlow Protocol to connect this lab sequence to the protocol messages and table behavior used in OpenFlow-style switches.