Simulate an OpenFlow learning controller

Steps

Screens captured against JupyterLite Python 3.12.7 / Pyodide 0.27.6; Chromium 148.0.7778.96 on 2026-09-10; the tool may have moved on — the text steps are the contract.

1. 1 Step 1

   Do

   Run `python3 main.py --step 1` to inspect the simulated two-switch topology and initial table-miss rule.

   You will see

   The topology names sensor, laptop, telemetry, and admin endpoints; s1-edge's table contains priority 0, match `*`, action CONTROLLER, and zero packets.

   Why it matters

   The explicit table-miss establishes why an unknown packet reaches control logic instead of disappearing silently.

2. 2 Step 2

   Do

   Run `python3 main.py --step 2` to send the first frame to an unknown destination.

   You will see

   The table miss emits `PACKET_IN reason=NO_MATCH`, the controller learns the source on port 1, and PACKET_OUT floods because the destination is unknown.

   Why it matters

   The event shows which state can be learned safely from ingress and why no destination-specific rule exists yet.

3. 3 Step 3

   Do

   Run `python3 main.py --step 3` to deliver the reply and install forward and reverse learned flows.

   You will see

   Two FLOW_MOD lines show priority 100 matches and output ports; the barrier reply confirms that the switch accepted two learned rules.

   Why it matters

   Controller intent becomes reviewable switch state only after the matches, actions, and acknowledgement are visible.

4. 4 Step 4

   Do

   Run `python3 main.py --step 4` to print the resulting s1-edge flow table.

   You will see

   The table lists two priority-100 learned entries above the priority-0 table miss, with match, action, and packet-count columns.

   Why it matters

   A table dump proves final ordering and preserves the fallback path for addresses the controller has not learned.

5. 5 Step 5

   Do

   Run `python3 main.py --step 5` to repeat the forward packet after its rule is installed.

   You will see

   The frame matches priority 100, outputs to port 2, increments its packet counter from 0 to 1, emits no Packet-In, and reaches laptop-1.

   Why it matters

   The match, counter movement, controller absence, and receiver result together prove data-plane handling.

6. 6 Step 6

   Do

   Run `python3 main.py --step 6` to install a higher-priority IoT-isolation policy.

   You will see

   FLOW_MOD lines and the full table show priority 300 DROP for IoT-to-admin and priority 200 OUTPUT:3 for IoT-to-telemetry above learned rules and table miss.

   Why it matters

   Narrow policy matches and explicit priorities keep a broad learning rule from bypassing the protected admin boundary.

7. 7 Step 7

   Do

   Run `python3 main.py --step 7` to test one allowed telemetry packet and one denied admin packet.

   You will see

   Packet A reaches telemetry through priority 200; packet B matches priority 300 DROP with receiver NONE; allow and deny counters both become 1.

   Why it matters

   Both positive and protected-path tests are needed to prove isolation without breaking the permitted IoT service.

8. 8 Step 8

   Do

   Run `python3 main.py --step 8` to remove the temporary isolation rules and close the proof record.

   You will see

   The table shrinks from five to three entries after deleting priorities 200 and 300; the evidence line retains Packet-In, Flow-Mod, barrier, counters, receiver results, and cleanup.

   Why it matters

   Explicit cleanup prevents maintenance policy from becoming hidden permanent state and completes the protocol evidence chain.