How to map OpenFlow switches to TCP ports in Mininet SDN simulations

When testing SDN functions in the Mininet network emulator and viewing captured OpenFlow messages in a packet analyzer such as Wireshark, it is difficult to identify which SDN switch is the source or destination of each captured message.

The only reliable way to identify which SDN switch sent or received an OpenFlow message is to look at the source or destination TCP port of the OpenFlow packets. This is because most OpenFlow messages exchanged between switches and the controller do not contain any other information that helps identify the sending or receiving switch. Neither Mininet nor the Open vSwitch database provides information that might be used to identify the TCP ports used by each switches to communicate with the OpenFlow controller in the network.

This post describes a procedure to map which TCP ports are used on each switch to communicate with the SDN controller in the Mininet network simulation. This procedure will enable researchers or students to study the interactions between SDN controller and switches in a more detailed and accurate way.

Summary of procedure

To map which TCP ports are used on each switch to communicate with the SDN controller in the Mininet network simulation, execute the steps listed below on the Mininet VM:

1. Start the Mininet network emulator and create a Mininet network topology with a remote controller.
2. Start Wireshark and capture OpenFlow messages on the Mininet VM’s loopback interface.
3. Start the controller. In this example, we start the POX SDN controller.
4. Examine the messages labelled of-features_reply in the Wireshark display’s Info field (or filter for of10.features_reply.type).
   b. In the of-features_reply packet, the datapath_id is the same as the switch number.
   c. Also in the same packet, switch port names are shows in clear text and they contain the switch name as part of the port name.
5. Map the source TCP port to the switch name and save the information for future reference.

The sections below offer a tutorial describe detailed procedures required to complete the steps in the summary.

Start a Mininet network topology

The Mininet VM should be running on your computer. If this is not yet the case, please read my post about how to set up the Mininet virtual machine.

We will create a simple Mininet network to demonstrate how to map OpenFlow TCP sessions to switches. In a terminal window connected to the Mininet VM, create a simple tree network with a remote SDN controller using the command:

$ sudo mn --topo tree,2,2 --controller=remote,ip=127.0.0.1,port=6633

This creates a simulated network as shown below.

We defined the remote controller address and TCP port as 127.0.0.1:6633 because we know from POX documentation it will be listening on port 6633. The Linux networking stack assigns TCP ports to the switches when the remote controller starts and requests sessions to connect to each switch.

We do not start the controller yet. We must start Wireshark first.

Start Wireshark and capture OpenFlow messages

Next, we start Wireshark and start capturing packets on the Mininet VM’s loopback interface. We start Wireshark now, before starting the POX controller, because we need to capture the switch setup messages sent by the POX controller when it starts.

In one of the terminal windows, start Wireshark with the command:

$ sudo wireshark &

Then select the loopback interface interface and start capturing. The enter the text of in the filter box and click the Apply button. Now you will see only OpenFlow messages captured on the loopback interface.

We see the bottom of the window that packets are being captured — because the packets counter is incrementing, but zero OpenFlow packets are displayed because the controller is not yet started. As soon as the controller starts, we will see OpenFlow messages and we will be interested in the initial of-features_reply setup messages.

Start the POX controller

Open a new terminal session. In the new terminal window (or tab), we will run the POX SDN controller. We will call this window the POX console.

The command we use to start POX is:

$ sudo ~/pox/pox.py forwarding.l2_learning      

This starts POX and makes the switches in the network perform basic Ethernet switching.

In the Wireshark window, you should start to see OpenFlow messages.

We will come back to these later in this tutorial. We will use the setup messages exchanged between the POX controller and the switches to identify the TCP port associated with each switch’s OpenFlow interface.

Monitor Wireshark packet capture

Look for OFPT_FEATURES_REPLY messages in Wireshark. These will show as of-features_reply in the Wireshark display’s Info field. You can filter for these messages specifically by entering of10.features_reply.type in the display filter box and pressing Apply (when using OpenFlow 1.0, which is what POX supports).

The POX controller requests switch features when it starts up and each switch reponds with an of-features_reply message. This message contains the switch’s unique datapath ID and information about switch ports, including the name of each port.

As shown in the image above, we can determine the switch that sent the packet from the information in the of-features_reply message.

• For Mininet-created switches, the datapath_id field shows the switch number. For example, a datapath_id of 00 00 00 00 00 00 00 02 refers to switch s2.
• The names of the ports include the switch name. For example, one port is named s2-eth0 so we know it is on switch s2.

Then we can look at the source TCP port in the TCP header to map the switch name to the TCP port assigned to the switch. In this example, the source TCP address is 34224.

Real-world scenarios

The above example works in Mininet because it assigns simple datapath ID numbers to the switches it creates in the simulation scenario. In the real world, the OpenFlow datapath ID may include a MAC address set to a number other than all-zeros and an identifier number that may not align so clearly with the switch name.

If the switch is an Open vSwitch, then you may find the switch’s datapath ID using the following command:

$ ovs-vsctl get bridge <switch_name> datapath_id

If another type of OpenFlow-enabled switch is used, consult the switch’s documentation and use the appropriate method to determine the datapath ID.

Create the TCP-port-to-switch map

We now know which switch is listening to which TCP port. Create a table and use it for future reference. In this case, our table will look like the following:

TCP Port	Switch name
34225	s1
34224	s2
34226	s3

Filtering messages

To filter so that you see only the OpenFlow messages exchanged between the SDN controller and a specific OpenFlow switch in a Mininet SDN simulation, use the Wireshark display filter to show only packets with the TCP port used by that switch to communicated with the controller.

For example, in the scenario above we would use the display filter: tcp.port==34224 and of to view OpenFlow messages going to or from switch s2. This filters out everything except OpenFlow messages (using the of filter) that are sent to or received from TCP port 34224.

Conclusion

We showed how to use the Wireshark packet analyzer to view OpenFlow messages sent to and from a specific switch in a network simulation created with Mininet and the POX SDN controller. We also showed how to identify the TCP ports used by each OpenFlow switch to communicated with the SDN controller, Then we used this information to identify OpenFlow messages send to or received from specific switches in the network.

Helpful information

This tutorial assumed you are already familiar with Mininet, OpenFlow, and the POX SDN controller. If you would like to learn more about these topics, please look at the links below:

• Fundamentals of Ethernet networks, IP networking, and software defined networking.
• How to set up the Mininet virtual machine on your computer.
• How to use the Mininet network emulator.
• How to use the POX SDN controller.
• A comprehensive OpenFlow Tutorial.