Lab 7: OpenFlow Mininet and Programmatic Flow Rule Installation

Chapter: 7 (SDN)
Duration: 90 minutes
Tools: Mininet, Open vSwitch (OVS), Ryu SDN controller, Python
Points: 10

Objectives

1. Deploy a Mininet topology with a remote Ryu controller
2. Observe reactive flow installation via PACKET_IN events
3. Measure first-packet latency in reactive mode vs. proactive mode
4. Programmatically install flow rules to block specific traffic
5. Dump and interpret the OVS flow table

Setup

# Verify Mininet and OVS are installed
mn --version
ovs-vsctl --version
ryu-manager --version

# Clean any stale Mininet state
sudo mn -c

Part 1: Simple Learning Switch (30 min)

1.1 Start the Ryu learning switch controller

# Terminal 1: start Ryu with the built-in learning switch
ryu-manager ryu.app.simple_switch_13 &
echo "Ryu started on port 6633"

1.2 Deploy the Mininet topology

# Terminal 2: start Mininet with 4 hosts, 2 switches, remote controller
sudo mn --topo tree,depth=2,fanout=2 \
  --controller remote,ip=127.0.0.1,port=6633 \
  --switch ovsk,protocols=OpenFlow13 \
  --link tc,bw=10,delay=5ms

1.3 Test connectivity

mininet> pingall

Record:

1. What is the first ping RTT to each host? (Expected: higher than steady-state due to reactive controller round-trip)
2. What is the steady-state ping RTT after flow rules are installed?
3. Run pingall a second time. Is the first-ping RTT lower? Why?

1.4 Examine flow table after ping

# In a separate terminal
sudo ovs-ofctl -O OpenFlow13 dump-flows s1
sudo ovs-ofctl -O OpenFlow13 dump-flows s2

Record:

1. How many flow entries are in s1's flow table after pingall?
2. What match fields does the learning switch use? (eth_src? eth_dst? IP? Both?)
3. What action does each flow entry specify? (output:PORT?)
4. What is the priority of the installed flows?

Part 2: Reactive vs. Proactive Flow Measurement (20 min)

2.1 Measure reactive (controller-in-the-loop) latency

# Clear flow tables to force reactive behavior on every ping
sudo ovs-ofctl -O OpenFlow13 del-flows s1
sudo ovs-ofctl -O OpenFlow13 del-flows s2

# In Mininet CLI:
mininet> h1 ping -c 10 -i 0.5 h4

Record:

1. What is the RTT of the first ping (reactive, no existing flow entry)?
2. What is the RTT of the second and subsequent pings?
3. The difference between first and second ping RTT is approximately the controller round-trip overhead. What is it (ms)?

2.2 Proactive flow installation

# Write a proactive_setup.py script
cat << 'EOF' > /tmp/proactive_setup.py
from subprocess import run

# Proactively install flows on s1 and s2 for h1->h4 path
# h1 is on s1 port 1; s1 connects to s2 on port 3
# h4 is on s2 port 2; s2 connects to s1 on port 3

flows = [
    # s1: forward to port 3 for traffic destined to h4
    ('s1', 'priority=200,ip,nw_dst=10.0.0.4', 'output:3'),
    # s2: forward to port 2 for traffic destined to h4
    ('s2', 'priority=200,ip,nw_dst=10.0.0.4', 'output:2'),
]

for switch, match, action in flows:
    cmd = f"ovs-ofctl -O OpenFlow13 add-flow {switch} '{match},actions={action}'"
    run(cmd, shell=True)
    print(f"Installed flow on {switch}: {match} -> {action}")
EOF
sudo python3 /tmp/proactive_setup.py

# Clear Ryu state and test again
mininet> h1 ping -c 5 h4

Record:

1. Is the first ping RTT now lower with proactive flows?
2. What is the trade-off between reactive and proactive SDN flow installation?

Part 3: Programmatic Flow Rule to Block Traffic (20 min)

3.1 Block traffic between h1 and h3

# Install a drop rule for h1 -> h3 traffic (h3 = 10.0.0.3)
sudo ovs-ofctl -O OpenFlow13 add-flow s1 \
  "priority=300,ip,nw_src=10.0.0.1,nw_dst=10.0.0.3,actions=drop"

# Test in Mininet
mininet> h1 ping -c 3 h3
# Expected: 100% packet loss (rule drops all packets)

mininet> h2 ping -c 3 h3
# Expected: success (rule only affects h1->h3)

Record:

1. Did the blocking rule work? What was the packet loss percentage?
2. Is h2 -> h3 still working? (It should be -- the rule is scoped to nw_src=10.0.0.1)
3. Why does this drop rule have priority=300 instead of the default learning switch priority?

3.2 Remove the blocking rule and restore connectivity

sudo ovs-ofctl -O OpenFlow13 del-flows s1 "ip,nw_src=10.0.0.1,nw_dst=10.0.0.3"

mininet> h1 ping -c 3 h3

Record: Is connectivity restored after removing the drop rule?

Part 4: OVS Flow Table Analysis (20 min)

# View flow table statistics
sudo ovs-ofctl -O OpenFlow13 dump-flows s1 -O OpenFlow13

# View port statistics
sudo ovs-ofctl -O OpenFlow13 dump-ports s1

# View OVS switch configuration
sudo ovs-vsctl show

Interpret the flow table output format:

cookie=0x...  duration=...  table=0, n_packets=..., n_bytes=...,
  priority=..., in_port=..., dl_src=..., dl_dst=..., actions=output:...

Record:

1. For each flow entry on s1, describe:
   • The match criteria (what traffic does it match?)
   • The action (where does it forward the packet?)
   • n_packets and n_bytes (how much traffic has matched this rule?)
2. Is there a "table-miss" flow entry? What does it do with unmatched packets?

Lab Report

1. Explain the reactive vs. proactive flow installation trade-off in terms of latency, controller load, and visibility. Under what scenarios would each approach be preferred?
2. An OpenFlow controller crashes. What happens to existing flows on the switch? What happens to new traffic (packets that don't match any existing flow)?
3. You observe a Mininet experiment where pingall takes 60 seconds on the first run but 0.1 seconds on the second. What is the most likely explanation?

Cleanup

sudo mn -c
pkill ryu-manager 2>/dev/null

Grading (10 points)