Also we should make sure that the tutorial text is up to date relative to the 2.0.0 VM image.

Need to figure out how to add this to the doxypy documentation and/or integrate it some other way. Also documentation should be updated on static web pages.

Mininet supports multiple controllers for multiple sets of switches, but it's not obvious how to set it up (in 1.0, you use a custom switch constructor or class; in 2.0 you have the additional option of specifying a custom constructor/class in the topology as well as custom options - the latter requires that controller objects exist before the topology is instantiated and that they know their IP addresses before net.start() is called.)

We should add documentation and possibly an example into the 2.0 code.

Try out Octopress, get feedback.

I really don't like the laundry list of parameters, especially the ones we added later on (enable_ecn, enable_red, use_hfsc, ...). It looks really really bad, though it's explicit. Also, maintaining that constructor is error prone!

A cleaner implementation would be to add a kwargs object to the constructor, and use something like __getattr__. The downside is bad readability---someone browsing the code would have no idea what options to pass. I think it's not a big deal, as we can document it.

Any thoughts?

Otherwise install.sh breaks partway through. Small issue.

such as --controller nox,pyswitch,somemodule,someothermodule

Maybe invoke mn -c automatically?

Currently mininet shuts down if you interrupt pingall. Instead it should just stop the overall pingall operation and recover.

From mininet wiki.

Very much so. As a result, VMs aren't updated frequently.

We should automate it using ubuntu-vm-builder.

Then we could have an automated build system that would also automatically create VM images.

Otherwise install.sh breaks partway through. Small issue.

The install.sh script is using an deprecated URL for the oftest git repository and this is breaking the installation process.
Needs just to be updated to git://github.com/floodlight/oftest at line 287 of file mininet/util/install.sh.

Unfortunately the ovs-vsctl patch broke the automatic DPID assignment in Mininet 1.0. This will change in Mininet 2.0 and is fixed there, but we need to fix it in install-precise.

Particularly on a VM, mininet startup is extremely slow. Adding links and starting switches can be very sluggish.

It seems that Mininet cs244/2.0 might even be slower than 1.0? Or perhaps it just takes up more CPU/memory?

We should add some Mininet startup/shutdown performance benchmarks, and also attempt to identify and fix the cause of the slowdown.

It's really close; however, we currently require the OF reference controller. If we supported the OVS controller, then we would be very close to running out of the box.

Ideally "make install" would just work on Ubuntu. Unfortunately our dependencies are a bit ugly at the moment, largely because of networkx which pulls in numpy and matplotlib and a general bag of hurt.

In order to work out of the box:

• openvswitch-switch and openvswitch-controller need to be installed
• openvswitch-switch must be running
• openvswitch-controller must NOT be running

It's not clear what the most obvious and sane way is to do ensure that this is the case.

The OVSSwitch in CS244 branch does not take user-defined OF dpid. This can be fixed with something like this

self.cmd( 'ovs-vsctl -- set Bridge ' + self.name + ' other_config:datapath-id=' + self.dpid)

... and send out an email so people know how to update it.

Fixed in CS244 branch.

version='0.0.0', seems like a bad idea.

With previous Linux kernels, the user switch failed to start if slicing was enabled. However, this no longer seems to be a problem with recent kernels, for example the kernels in Ubuntu 11 and 12.

We should probably remove the --no-slicing parameter that we currently pass to the user switch in Mininet 2.0, and if we can verify that it works in 10.04 then we should definitely remove it in 1.0 as well.

Reported-by: [email protected]

When attempting to create > 256 datapaths w/OVS compiled for just that many datapaths, Mininet does not fail at creation time.

See more description at:

https://mailman.stanford.edu/mailman/suprivate/mininet-discuss/2011-November/000610.html

Hi,

I tried to follow http://www.openflow.org/wk/index.php/MPLS-TE_Demo to install OpenFlow and emulate things, but I found the url to packetgen.py file dead. The packetgen.py file is supposed to be available at http://www.stanford.edu/~sharafat/packetgen.py Any ideas?

Thanks.

I changed the cs244 branch to intuit the dpid if it isn't specified by looking for it in the name. However, this is somewhat brittle and breaks for non-standard switch names. So, either we should specify a default dpid when we create the network (as we currently do in mainline) or make this mechanism more robust.

Reported-by: Andrew Ferguson

"btw, there is a bug on this line: https://github.com/mininet/mininet/blob/devel/2.0dev/mininet/link.py#L248 .. if you are using ecn or red, then handle with major 10 has already been created."

It's annoying when switch dpids aren't assigned correctly. We should add a test to verify that it works.

From Mininet wiki. Need to verify and fix.

I started out with the basic emptynet.py topology given in the example directory.

from mininet.net import Mininet
from mininet.node import Controller,OVSKernelSwitch, NOX
from mininet.cli import CLI
from mininet.log import setLogLevel, info

def emptyNet():

"Create an empty network and add nodes to it."

net = Mininet( switch=OVSKernelSwitch,controller=lambda name: NOX (name, 'NOXSwitch') )

info( '*** Adding controller\n' )
net.addController( 'c0' )

info( '*** Adding hosts\n' )
h1 = net.addHost( 'h1', mac='00:11:22:33:44:55 )
h2 = net.addHost( 'h2', mac='00:12:22:32:42:52 )

info( '*** Adding switch\n' )
s3 = net.addSwitch( 's3' )

info( '*** Creating links\n' )
h1.linkTo( s3, 0, 0 )
h2.linkTo( s3, 0, 1 )

info( '*** Starting network\n')
net.start()

info( '*** Running CLI\n' )
CLI( net )

info( '*** Stopping network' )
net.stop()

if name == 'main':
setLogLevel( 'info' )
emptyNet()

When I run this I get the following error:
*** Adding controller
*** Adding hosts
*** Adding switch
*** Creating links
*** Starting network
*** Configuring hosts
h1 h2
*** Starting controller
*** Starting 1 switches
s3 Traceback (most recent call last):
File "emptynet.py", line 44, in
emptyNet()
File "emptynet.py", line 34, in emptyNet
net.start()
File "/usr/local/lib/python2.7/dist-packages/mininet-0.0.0-py2.7.egg/mininet/net.py", line 358, in start
switch.start( self.controllers )
File "/usr/local/lib/python2.7/dist-packages/mininet-0.0.0-py2.7.egg/mininet/node.py", line 602, in start
'supported: %s' % self.intfs )
Exception: only contiguous, one-indexed port ranges supported: {0: 's3-eth0', 1: 's3-eth1'}

When I change the statements to:
h1.linkTo( s3 )
h2.linkTo( s3 )
everything works fine.

commit 40ea16e in testing supposedly fixed this in U11.04 in install.sh, but trying the one-liner (modified to use libwireshark1 rather than libwireshark0) in U11.10 didn't work for me. I can't see the OFP as an available protocol for expressions in WS.

This means install.sh is broken as it currently stands.

So that we can kill the testing branch, here's the full change, right before "#Copy coloring rules" in util/install.sh

# The OpenFlow wireshark plugin does not install to the correct dir.
+    # The correct way would be to fix the install script.
+    # For now, just copy it to the global WS plugin dir.
+    # Tested on Ubuntu 11.04.
+    cp /var/packet-openflow.so /usr/lib/wireshark/libwireshark0/plugins

One thing that's clear to me from our experience with piazza is that a q&a site is better than a mailing list in so many ways: avoiding duplicates, editing and improving answers over time, easy browsing of existing questions, indexing via google (if the site is public) etc.. It would be nice to have something for Mininet/OpenFlow/SDN at large. Some options that occur to me:

1. People could just use stackoverflow.
2. Perhaps we could convince Pooja to expand piazza beyond course web sites to allow project Q&A.
3. Perhaps a new stackexchange site could be created for networking or software-defined networking
4. We could use getsatisfaction.com or some other Q&A or support site

I'm not sure what the best idea is.

Currently we have the Mininet FAQ, but it's updated manually. Automated systems can vote the most common questions and best answers to the top automatically, and can be indexed by google for easy access from any web browser.

In node.py, the Controller class is using ip, but RemoteController is using defaultIP. The parameter in RemoteController won't propagate into Controller class.

Moreover, the --ip switch in bin/mn seems broken too.

I believe it is fixed in 2.0dev, so we should propagate that fix to install-precise.

If all of the pieces aren't in place and working correctly, Mininet won't work.

We should implement a health check feature that you can run to check that everything is in place and to optionally fix missing or broken components.

In general, Mininet should have better error checking. I like the way piconet wraps everything in python 'with' statements - perhaps we could adopt that as well.

If the network won't start up for some reason, we should provide some help, perhaps automatically running the health check.

It would be nice to see if we can create a "pure" Python version of Mininet which replaces mnexec with Python code. Note it would still be Linux-dependent since it requires network namespaces and various Linux utilities.

The advantage of create

It would be nice to know what the performance hit (if any) is of such an approach.

Currently the version number of Mininet appears in multiple places, but consistency isn't enforced. It should be. Ideally, there should be a single instance of the version number. If that's not possible, then we should at least enforce consistency in the code check or elsewhere.

I was talking with one of the Frenetic guys and he suggested an obvious but brilliant idea: change the VM image to automatically update Mininet on boot so that an "old" VM image still gets a "new" mininet.

Ubuntu's /etc/motd is quite useful - I think it would be terrific if it also included information on whether mininet had been updated, along with a script (update-mininet?) to do so! The message could look something like:

Mininet updates are available - use 'update-mininet' to update.

We could also just update it automatically on first boot, but this won't work unless there is internet connectivity.

Of course, we also want to make it easier to spin new VMs, ideally automatically (e.g. by using ubuntu-create-vm-image.)

Of course, if mininet were a package in a repo, it could be updated automatically using the regular apt-get mechanism; however, it is important that we don't vaporize a custom version of mininet which may have been installed in the VM, which is why I favor an "update-mininet" script/command which would be careful not to do so.

Additionally, we could do a development install so that make install wouldn't be necessary.

The update-mininet script would also have to make sure that the updated mininet would actually run, and have some means of reverting to the previous versions in case of disaster.

Now that ovs-controller is a package in ubuntu, this can easily happen.

In Mininet CS244 with remote controller, if I run this command:

~/mininet/examples$ sudo mn --controller=remote,ip=10.0.2.2 --listenport=6633 --topo=tree,depth=6,fanout=2

the controller can only detect 50 switches.
I have tested it with Beacon and Floodlight. They both have this issue.

This is an annoying problem. The devel/install-precise branch may fix things, but hasn't been tested with 10.04 and 11.x, which we also don't want to break.

What we need to do is:

1. Test devel/install-precise on 10.04 and 11.x
2. Fix any bugs
3. Make sure that Mininet itself works reliably (e.g. that dpctl works on all platforms)
4. File pull request
5. Merge into mainline
6. Tag as Mininet 1.0.1

... as it isn't in current default 10.04-3 LTS kernel (though you can install 3.0.0-15-generic which works fine.)

Since NOX classic is deprecated, for 2.0 install.sh -a (or -t?) should install POX and/or the new NOX. Keeping around the old NOX classic install code is probably fine.

From mininet wiki.

Reported by Kelvin Zou and Rômulo Vitoi:

https://mailman.stanford.edu/mailman/suprivate/mininet-discuss/2012-July/001024.html

If I start mininet with just the basic defaults, pingall works fine:

sudo mn -v debug --mac

but as soon as I specify a floodlight controller (or non-existent controller) then pingall fails:

sudo mn -v debug --controller=remote --ip=10.2.156.88 --port=6633 --mac

log file says connection is made, but no connectivity. Tables look the same in both cases.

Suggestions?