Lab 9: SDN vs. OSPF Convergence Comparison

Chapter: 9 (SDN + Performance)
Duration: 90 minutes
Tools: Containerlab, FRRouting (OSPF), Mininet, Ryu, iperf3
Points: 10

Objectives

1. Deploy the same 4-node topology under OSPF control and under SDN (OpenFlow + Ryu)
2. Measure convergence time after a link failure under each paradigm
3. Document the behavioral difference between distributed reconvergence and centralized control
4. Understand the failure modes of each approach

Topology (same for both experiments)

h1 --- sw1/r1 --- sw2/r2 --- h2
             \         /
              sw3/r3---

Four nodes: two "host" nodes (h1, h2) and two switching/routing nodes. A redundant path exists. Fail one link; measure recovery.

Part 1: OSPF Convergence (40 min)

1.1 Deploy the OSPF topology

# topo-ospf-conv.clab.yml
name: ospf-conv
topology:
  nodes:
    r1:
      kind: linux
      image: frrouting/frr:latest
    r2:
      kind: linux
      image: frrouting/frr:latest
    r3:
      kind: linux
      image: frrouting/frr:latest
    h1:
      kind: linux
      image: alpine:latest
    h2:
      kind: linux
      image: alpine:latest
  links:
    - endpoints: ["h1:eth1", "r1:eth1"]
    - endpoints: ["r1:eth2", "r2:eth1"]   # primary path
    - endpoints: ["r1:eth3", "r3:eth1"]   # secondary path
    - endpoints: ["r2:eth2", "r3:eth2"]   # r2-r3 link
    - endpoints: ["r2:eth3", "h2:eth1"]

containerlab deploy -t topo-ospf-conv.clab.yml

Configure OSPF on r1, r2, r3:

# r1: enable OSPF, advertise all connected subnets in area 0
docker exec -it clab-ospf-conv-r1 vtysh <<EOF
configure terminal
interface eth2
 ip address 10.1.2.1/30
interface eth3
 ip address 10.1.3.1/30
interface eth1
 ip address 10.0.1.1/24
router ospf
 router-id 1.1.1.1
 network 10.0.0.0/8 area 0
 auto-cost reference-bandwidth 10000
EOF

Configure r2 (10.1.2.2, 10.2.3.1, 10.0.2.1) and r3 (10.1.3.2, 10.2.3.2) similarly.

Set host routes:

docker exec clab-ospf-conv-h1 ip addr add 10.0.1.10/24 dev eth1
docker exec clab-ospf-conv-h1 ip route add default via 10.0.1.1
docker exec clab-ospf-conv-h2 ip addr add 10.0.2.10/24 dev eth1
docker exec clab-ospf-conv-h2 ip route add default via 10.0.2.1

1.2 Verify connectivity

docker exec clab-ospf-conv-h1 ping -c 3 10.0.2.10
docker exec -it clab-ospf-conv-r1 vtysh -c "show ip ospf neighbor"
docker exec -it clab-ospf-conv-r1 vtysh -c "show ip route"

1.3 Measure OSPF convergence

# Start continuous ping from h1 to h2
docker exec clab-ospf-conv-h1 ping -i 0.1 -c 600 10.0.2.10 > /tmp/ping_ospf.txt &

# Start timing: record current time
date +%s%3N > /tmp/failure_time.txt

# Disable the primary r1-r2 link
docker exec clab-ospf-conv-r1 ip link set eth2 down

# Watch for recovery
sleep 60
docker exec clab-ospf-conv-r1 ip link set eth2 up

# Analyze ping output: find gap and recovery
grep -n "time=" /tmp/ping_ospf.txt | tail -100 | head -30
# Count consecutive losses
grep -c "Request timeout" /tmp/ping_ospf.txt 2>/dev/null || \
  grep -c "^$" /tmp/ping_ospf.txt

Record:

1. Number of ping packets lost during the failure
2. Estimated convergence time (lost_packets × 100ms interval)
3. Compare to the theoretical convergence time with default OSPF timers (Dead interval = 40s)
4. Is OSPF using the secondary r1-r3-r2 path during recovery? How did you verify?

Part 2: SDN (OpenFlow) Convergence (35 min)

2.1 Tear down OSPF; bring up Mininet

containerlab destroy -t topo-ospf-conv.clab.yml
sudo mn -c

2.2 Start Ryu learning switch controller

ryu-manager ryu.app.simple_switch_13 &

2.3 Deploy Mininet topology (same physical layout)

sudo mn --topo linear,3 \
  --controller remote,ip=127.0.0.1,port=6633 \
  --switch ovsk,protocols=OpenFlow13 \
  --link tc,bw=10,delay=2ms

(3-switch linear topology approximates the r1-r2-r3 triangle; adjust as needed.)

2.4 Measure SDN convergence

# In Mininet
mininet> h1 ping -i 0.1 -c 600 h3 > /tmp/ping_sdn.txt &

# Disable s1-s2 link (simulates primary link failure)
# Method: use Mininet's link down command
mininet> link s1 s2 down

Observe controller output (Ryu will show new PACKET_IN events as the learning switch adapts).

mininet> link s1 s2 up

Record:

1. Number of ping packets lost during SDN link failure
2. Estimated convergence time
3. Did SDN reconverge via the alternative path (through s3)? How long did it take?
4. What happened to existing flow entries when the link went down?

Part 3: Comparison and Analysis (15 min)

Additional test: kill the Ryu controller mid-session

pkill ryu-manager

# In Mininet: test connectivity with controller dead
mininet> h1 ping -c 5 h3

Record:

1. Do existing flows continue to work (packets that match installed flow entries)?
2. Does new traffic work (traffic requiring a new flow entry / PACKET_IN to controller)?
3. What does this failure mode imply about SDN controller availability requirements?

Lab Report

1. You measured OSPF convergence time as X seconds and SDN reconvergence as Y seconds. Which is faster and why? Under what conditions might the result reverse?
2. A network engineer argues that SDN is strictly better than OSPF because "the controller has a global view." What is the primary counter-argument from an availability standpoint?
3. OSPF route reflectors (or in this case, distributed SPF) require no central node. SDN requires a reachable controller. In a real network, how would you make the Ryu controller highly available?

Cleanup

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

Grading (10 points)