For some time, UserSwitch has suffered from abysmal performance due
to rx and tx offload settings. In the latest Ubuntu 16.04/Linux 4.4
kernel, it simply doesn't work with the default settings, since
packets with bad TCP checksums are generated at one end, passed through
the user switch, and dropped at the other. It doesn't seem to be
something we can fix in UserSwitch itself although it may be possible
to do something in the C code of the Stanford reference switch and
CPqD switch.
Previously the standard OpenFlow poort (6653) that Controller()
may be listening at would conflict with the default listenPort
for switch 20 (usually UserSwitch 20), breaking waitConnected()
and disconnecting that switch from the network in general.
Fixes#668
It's very useful to be able to pass parameters to tests.
Unfortunately, our previous --test argument syntax didn't
permit it, because , was used as a delimiter for multiple
tests. With this change, we change , to become a delimiter
for arguments, as it is with other options to mn. For now,
we introduce + as a separator, as it is legal in filenames
and therefore shouldn't conflict with special characters
used by Unix shells.
We also reorganize mn a bit to make it hopefully slightly
clearer.
The justification for this is that 1) the options are
already documented in the API documentation and 2) the
class names are fairly self-explanatory, so adding short
descriptions doesn't add much.
In the future, however, we could add a short description
by simply using the first line or sentence of the docstring;
note that docstrings would have to be canonicalized, which
they aren't now.
specialClass is an analog of functools.partial but for classes.
We can now use it instead of partial() in mn, so that Mininet
can introspect on the actual base class.
Fixes#488
Note that we are changing the interface of batchStartup/Shutdown
slightly so that the method can choose not to start some of the
switches. We might wish to refine this a bit...
Works in a few ways:
* a single file: --custom foo.py (as before)
* comma-separated list: --custom foo.py,bar.py
* multiple custom args: --custom foo.py --custom bar.py
We add a new experimental feature to allow Mininet to run across
a cluster of machines. This is currently implemented via a set
mix-in classes that provide remote nodes that are implemented
via a connection to a remote shell, and remote links which are
tunnels across servers. In this preliminary implementation,
both control and data connections are made via ssh, but this
could change in the future.
A MininetCluster class is provided which allows existing code
to be used with minimal modification - all that is required is
to provide a list of servers to use. A customizable placement
algorithm may also be specified. An experimental CLI subclass
is also provided to make it easier to examine node placement;
status and links commands can also check whether nodes and
tunnels are still running.
Although this is an experimental feature, it does include a
--cluster option to make it convenient to start up a Mininet
simulation over a cluster, and a script to assist with setting
up the prerequisite authentication via ssh key pairs.
The cluster feature is preliminary and missing some obvious
important features, such as parallel startup and multiple tunnel
types, which we hope to add in the future.