Original post is here.
from mininet.net import Mininet
from mininet.node import Controller, RemoteController
from mininet.cli import CLI
from mininet.log import setLogLevel, info
net = Mininet( topo=None, build=False)
# Create nodes
h1 = net.addHost( 'h1', mac='01:00:00:00:01:00', ip='192.168.0.1/24' )
h2 = net.addHost( 'h2', mac='01:00:00:00:02:00', ip='192.168.0.2/24' )
# Create switches
s1 = net.addSwitch( 's1', listenPort=6634, mac='00:00:00:00:00:01' )
s2 = net.addSwitch( 's2', listenPort=6634, mac='00:00:00:00:00:02' )
print "*** Creating links"
net.addLink(h1, s1, )
net.addLink(h2, s2, )
net.addLink(s1, s2, )
# Add Controllers
odl_ctrl = net.addController( 'c0', controller=RemoteController, ip=ODL_CONTROLLER_IP, port=6633)
fl_ctrl = net.addController( 'c1', controller=RemoteController, ip=FL_CONTROLLER_IP, port=6633)
# Connect each switch to a different controller
s1.start( [odl_ctrl] )
s2.start( [fl_ctrl] )
CLI( net )
if __name__ == '__main__':
setLogLevel( 'info' )
If you’re getting kernel module installation errors, probably the module is not compiled for the current kernel or its dependencies are not loaded.
# insmod datapath/linux/openvswitch.ko
datapath/linux/openvswitch.ko: Unknown symbol in module
By using the command modinfo, you can take clues about the module, such as its dependencies and kernel version that was used to compile.
If the problem is dependencies, instead of using insmod to install openvswitch.ko module, you can first type the command in the OVS root directory (after compiling):
# make install
This will install all compiled modules in the Linux system. Then, type:
# modprobe openvswitch
The command should automatically load openvswitch module and its dependencies.
From the original post:
The following (save as
rr.sh) reads a file passed as an argument line by line:
while IFS='' read -r line || [[ -n "$line" ]]; do
echo "Text read from file: $line"
done < "$1"
IFS=) prevents leading/trailing whitespace from being trimmed.
-r prevents backslash escapes from being interpreted.
|| [[ -n $line ]] prevents the last line from being ignored if it doesn’t end with a
read returns a non-zero exit code when it encounters EOF).
Run the script as follows:
chmod +x rr.sh
How long a kernel’s table entry can be inactive? The OVS kernel’s table can inactive, by default, during a time interval less than 5 seconds. After 5 seconds being inactive, the flow entry is removed from the table. This time is dictated by ovs-vswitchd.
From the original post:
”ovs-vswitchd determines how long the flow should stay in the kernel flow table. By default, it expires a flow after five seconds of inactivity. It can be more aggressive if the flow table becomes large.”
Original post here.
When using ovs-dpctl, there are flow descriptions with “used=never”. What does it mean? It means that a packet went up to the userspace (ovs-vswitchd), a match was found and it was copied to the kernel space. However, there were no more following packets that matched the rule cached in the kernel’s table.
Basically, ovs-ofctl is used to look up for the actual flow table entries. And, ovs-dpctl can be used to see what is inside of the OVS’s kernel table, which can be considered as flow table, but OVS kernel module actually does not speak OpenFlow, i.e., it doesn’t handle OpenFlow messages.
The number of entries retrieved by ovs-ofctl and ovs-dpctl can be different. That is because only the matched entries in user-space are copied to the kernel-space. More details may be found in the OVS official website.
From the original post.
“ovs-ofctl dump-flows” prints OpenFlow flow table entries.
“ovs-dpctl dump-flows” is different.
As the manpage says:
This command is primarily useful for debugging Open vSwitch. The flow table entries that it displays are not OpenFlow flow entries. Instead, they are different and considerably simpler flows maintained by the Open vSwitch kernel module.
In a little more detail, the flows that ovs-dpctl prints are always exact-match. They reflect packets that have actually passed through the system in the last 5 seconds or so.
If you want to know what OpenFlow sees, use ovs-ofctl. If you want to verify that the OpenFlow flows are being implemented in the way you expect, ovs-dpctl is the right tool.
If you’re running ONOS, you might have seen the following error:
Exception in thread "JMX Connector Thread
java.lang.RuntimeException: Could not start JMX connector server
I got this issue once, and I solved by replacing ‘0.0.0.0‘ with a meaningful IP address, such as ‘127.0.0.1‘. All I had to do, was to edit the file ‘org.apache.karaf.management.cfg ‘
$ cd apache-karaf-3.0.3/etc
$ vim org.apache.karaf.management.cfg