Using our Mininet-based OpenFlow laboratory, we are going to set up a simple network consisting of an OpenFlow switch, three hosts, and an OpenFlow controller (POX). The topology of the network is shown in the following diagram:

In addition to the POX controller, we also use the dpctl utility program to examine the flow table of the OpenFlow switch. As mentioned earlier, OpenFlow switches usually are listening on port 6634, which is considered for the dpctl channel. Even without an OpenFlow controller, we can use the dpctl utility program to communicate with the OpenFlow switch in our OpenFlow laboratory and inspect flow table entries or modify flows. In order to set up the network topology depicted in the previous figure inside our Mininet OpenFlow laboratory, we start Mininet with the following command-line parameters:

mininet@mininet-vm:~$ sudo mn --topo single,3 --mac --switch ovsk 
--controller remote 

Note that Mininet reports that it is not able to connect to the remote controller at 127.0.0.1:6633 (localhost:6633).

*** Adding controller
Unable to connect the remote controller at 127.0.0.1:6633  

In fact, since we have not started any POX controller so far, the OpenFlow switch is not able to connect to the remote controller (as indicated by --controller remote in the command-line parameters of the Mininet launcher). Note that --controller remote by default refers to an OpenFlow controller located on the localhost (127.0.0.1). You can check the IP address and MAC address of h1 (and other hosts) using the following command:

mininet> h1 ifconfig  

Now we can try to check the connectivity among the hosts (h1, h2, and h3) using the pingall command of Mininet:

mininet> pingall  

The following will be the output:

*** Ping: testing ping reachability
h1 -> X X
h2 -> X X
h3 -> X X
*** Results: 100% dropped (6/6 lost)  

These results show that the hosts (in spite of being physically connected to each other) in the current topology are not logically connected (are not reachable) to each other through the switch due to lack of any flow entry rule in the flow table of the switch. We can dump the content of the flow table of the OpenFlow switch using the following command (you need to establish an SSH terminal connection to your Mininet VM to issue this command):

mininet@mininet-vm:~$ dpctl dump-flows tcp:127.0.0.1:6634  

The following will be the output:

status reply (xid=0xf36abb08): flags=none type=1 (flow)  

Before attaching the POX controller to our network topology, in which the controller will play the role of an Ethernet hub, let's quickly review the operation of an Ethernet hub. An Ethernet hub (an active hub or multiport repeater) is a device for connecting multiple Ethernet devices together and making them act as a single network segment. It has multiple input/output ports, in which a signal introduced at the input of any port appears at the output of every port except the original incoming one. No forwarding information is stored in the switch. The hub functionality is implemented in the hub.py code of the POX distribution (developed by James McCauley). This program (along with the L2 learning switch) is located in the ~/pox/pox/forwarding directory. Looking at hub.py, we can find the launch method, which simply adds a listener for OpenFlow switches to connect to it:

def launch ():
    core.openflow.addlisternetByName("connectionUp", _handle_ConnectionUp)
    log.info("Hub running.")  

The _handle_connectionUp method, which is another method in hub.py, simply generates an OpenFlow message for the OpenFlow switch. The action appended to the message simply floods the packet on all ports of the OpenFlow switch (except the incoming port). The generated message is then sent to the OpenFlow switch in our experimental network topology:

def _handle_ConnectionUp (event):
    msg= of.ofp_flow_mod()
    msg.actions.append(of.ofp_action_output(port= of.OFPP_FLOOD))
    event.connection.send(msg)
    log.info("Hubifying %s", dpidToStr(event.dpid))  

So the event handler (_handle_ConnectionUp) simply receives an event from the OpenFlow switch and then caches a flooding rule inside the flow table of the switch. Let's start the POX controller with the following hub functionality:

mininet@mininet-vm:~/pox$ ./pox.py forwarding.hub  

The following will be the output:

POX POX 0.0.0 / Copyright 2011 James McCauley
INFO:forwarding.hub:Hub running.
DEBUG:core:POX 0.0.0 going up...
DEBUG:core:Running on CPython (2.7.3/Sep 26 2012 21:51:14)
INFO:core:POX 0.0.0 is up.
This program comes with ABSOLUTELY NO WARRANTY.  This program is free software, and you are welcome to redistribute it under certain conditions.
Type 'help(pox.license)' for details.
DEBUG:openflow.of_01:Listening for connections on 0.0.0.0:6633
Ready.
POX> INFO:openflow.of_01:[Con 1/1] Connected to 00-00-00-00-00-01
INFO:forwarding.hub:Hubifying 00-00-00-00-00-01
  

Note that upon the start of the POX controller (functioning as an Ethernet hub), an information message confirms that the OpenFlow switch is connected to the POX controller. The data path identification (dpid) of the switch is also printed out as 00-00-00-00-00-01. You can return to the Mininet command prompt and issue the net command to see the network elements, in which C0 (controller 0) will be also printed out. Now we can try to ping all hosts in our topology using the pingall command of Mininet:

mininet> pingall  

The following will be the output:

*** Ping: testing ping reachability
h1 -> h2 h3
h2 -> h1 h3
h3 -> h1 h2
*** Results: 0% dropped (0/6 lost)  

And we can also use dpctl (from our new SSH terminal) to see the content of the flow table of our OpenFlow switch:

mininet@mininet-vm:~$ dpctl dump-flows tcp:127.0.0.1:6634  

The following will be the output:

stats_reply (xid=0x2f0cd1c7): flags=none type=1(flow)
cookie=0, duration_sec=800s, duration_nsec=467000000s, table_id=0, 
priority=32768, n_packets=24, n_bytes=1680, idle_timeout=0,
hard_timeout=0,actions=FLOOD  

So, we started our experimental network topology in Mininet and made its OpenFlow switch get connected to the POX controller, which was behaving like an Ethernet hub. The interesting point about our first Net App is that just with 12 lines of code in Python (hub.py), we managed to perform the Ethernet hub functionality in the network.