Guide to Mininet Network Topology Configuration with OpenDaylight and Wireshark Analysis

1 Open Wireshark and Create a Topology

Follow Chapter One to build the platform, start ODL, and open Wireshark. Enter the VM with Mininet to specify the network topology and designate this ODL controller using the mn command.Mininet network topology creation command:

sudo mn --topo linear,2 --switch ovsk --controller=remote,ip=192.168.5.203,port=6633

This command simulates creating a network topology with two switches (Open vSwitch, abbreviated as OVS hereafter) and two hosts via Mininet. Here, 192.168.5.203 is the IP of ODL, and 6633 is ODL’s default port. The network topology is shown in the diagram below:

2 View the Network

You can use network commands within Mininet to view the connection relationships between OVS and hosts, as well as whether Mininet is connected to the controller remotely.

For instance, using the nodes command allows you to view all nodes in the network.

The net command can help verify whether network connections match expectations and show node details, including specific port connection information.

Using the dump command below, you can see that the switches are connected to the controller remotely, along with the controller’s IP and PORT.

3 Capture and Analyze Protocols

Through packet capture in Wireshark, you can directly see the communication process between the controller and OVS switches. The following analyzes the OF messages in this process. This topic uses the Stable Release (1.12.1) version of Wireshark, which directly supports the OpenFlow protocol.

3.1 Establish Connection

The OpenFlow protocol between the controller and switches is applied over the TCP transport layer, and thus application layer parsing is required. They first send hello messages to establish an initial connection, negotiating the OpenFlow protocol version to be used. As shown in the diagram below, OpenFlow1.0 protocol version is used between ODL and Mininet (other versions like 1.2, 1.3 will be indicated after the OpenFlow protocol).

3.2 Capability Request Response

This message primarily responds to the feature request message, returning some basic configuration information about the switches connected to this controller, including their capabilities and some port information.

3.3 Config Request Reply

The get config reply message is used to respond to the get config request message, whereby the switch replies with configuration information, typically interface configuration, and so on.

3.4 Stats Status Information

The stats reply message is used to respond to the stats request information, mainly concerning status information replied from the switch to the controller.

3.5 Flow Mod Message

The flow mod message involves the match information of flow table entries, etc. The flow mod match entry type information is shown in the diagram below.

3.6 packet_in, packet_out Messages

In this part of the process, when a switch receives a packet but finds no match in the flow table, it encapsulates the packet in a packet_in message to the controller. The controller issues a decision via a packet_out message to enable communication between the two hosts sending and receiving the packet.

These message types can reference the types in the OpenFlow standard protocol, as shown in the diagram below:

We can observe using Wireshark that when the first ping packet is sent from h1 to h2, how the controller automatically adds corresponding table entries to the switch.

At the same time, you can enter ODL’s web interface to view discovered device topology, as illustrated in the diagram:

4 Summary

This article, based on the previous article in this topic, introduces the experimental platform and uses Mininet to build a topology to familiarize with its basic operations. It also uses the Wireshark packet capture tool supporting the OpenFlow protocol to familiarize and analyze the relevant OpenFlow protocol.