sdn-traffic-monitor is a software-defined networking application that demonstrates how a centralised controller manages forwarding behaviour across switches using the OpenFlow protocol. Built for a Computer Networks course, it deploys a custom Mininet topology of two OpenFlow switches and four hosts joined by a 10 Mbps backbone link, and drives it from a Ryu controller application that combines learning-switch forwarding, access control and periodic statistics collection in one program.
The control logic follows the reactive SDN model end to end. When a switch connects, the controller installs a table-miss entry at priority 0 that forwards anything unmatched to the controller. A packet with no matching flow rule therefore triggers a packet_in event; the controller learns the source MAC against the ingress port, checks whether the source–destination pair is blocked, and installs either a drop rule at priority 10 or a forwarding rule at priority 5. Access control is enforced by that priority ordering — traffic from h2 to h3 is deliberately blocked while every other pair remains reachable, which pingall confirms as a single failing pair against otherwise complete connectivity. A separate monitoring thread issues an OFPFlowStatsRequest to every connected switch every ten seconds and logs the match fields, priority, packet count and byte count of each installed flow.
The project's most instructive result is a measurement rather than a feature. Round-trip time between hosts is consistently higher on a cold first run than on a warm second run — roughly 0.112 ms against 0.094 ms — because in the cold case every packet must escalate to the controller before it can be forwarded, whereas once flow rules are cached in the switch datapath the packets are forwarded locally with no controller involvement at all. Throughput measured with iperf3 reaches about 9.55 Mbps on the 10 Mbps link both within a switch and across the backbone, showing the control plane imposes no steady-state penalty once the flow table has converged.
Evidence is captured rather than asserted: flow-table dumps taken before and after traffic generation, controller statistics reports, iperf transcripts and annotated screenshots of each test scenario are all committed alongside the code. The repository is archived, having been completed as coursework, but it stands as a clear worked example of controller–switch interaction, match–action rule design and the observable cost of the reactive flow-installation model.