I deployed Ryu and ONOS controllers and programmed forwarding behaviour through a Python application and the northbound REST API. Centralizing logic in the controller replaced per-switch configuration with one programmable control point for the whole fabric.

Objective & Context

The controller is the brain of an SDN fabric. This lab writes a Ryu app that reacts to packet-in events and pushes flows, then drives ONOS through REST, demonstrating both event-driven and declarative control models on the topology from the SDN concepts lab.

Environment & Prerequisites

  • Ryu and/or ONOS installed; Mininet with OVS switches.
  • Python 3 for the Ryu app; curl for ONOS REST.
  • OpenFlow 1.3 connectivity on port 6653.

Step-by-Step Execution

1. Run a Ryu learning-switch app

ryu-manager ryu.app.simple_switch_13 --ofp-tcp-listen-port 6653

2. Push a flow via the ONOS REST API

curl -u onos:rocks -X POST http://127.0.0.1:8181/onos/v1/flows/of:0000000000000001 -d @flow.json

3. Verify devices and flows are managed

curl -s -u onos:rocks http://127.0.0.1:8181/onos/v1/devices | jq '.devices[].id'
"of:0000000000000001"
"of:0000000000000002"

Validation & Testing

Run pingall in Mininet and confirm the controller installs flows reactively (Ryu) or that REST-pushed flows appear in the switch (ONOS). Pass criteria: full reachability driven by controller-installed flows, visible in dump-flows.

Advanced: Troubleshooting
  • App not receiving events: confirm switches connect on 6653 and speak OpenFlow 1.3.
  • ONOS REST 401: use the correct credentials and enable required apps (openflow, fwd).
  • Flows not applied: validate the JSON deviceId and selector/treatment fields.

Key Results

  • Centralized forwarding logic for a multi-switch fabric in one controller.
  • Programmed flows via both event-driven Python and declarative REST.
  • Achieved full fabric reachability driven entirely by controller flows.
  • Replaced per-switch config with a single programmable control point.