Page History

...

How can I connect to the ONOS GUI if ONOS is running in a Mininet host inside a VM?

One way is to use ssh port forwarding, e.g.

ssh -L 8081:192.168.123.1:8081 mininet-vm

from your laptop. This forwards port 8081 on 192.168.123.1 in mininet-vm to port 8081 on your laptop. (8081 is the default ONOS GUI port, and 192.168.123.1 is the default IP address for onos1.)

Then open up http://localhost:8101/onos/ui/ in your browser.

Another way is to run a browser such as Firefox or Chromium in your development VM or server.

firefox &

We hope to make it easier and more automatic in the future.

How can I look at the karaf log file for (which usually contains ONOS's log messages) for onos1?

There are many ways to do it, including:

mininet-onos> onos log:display

mininet-onos> onos log:tail  # press control-c to quit

mininet-onos> sh tail /tmp/onos1/log  # press control-c to quit

mininet-onos> onos1 more /tmp/onos1.log  # press q to quit

$ tail /tmp/onos1/log

The first few methods work when you are at the mininet-onos> prompt. The last one is for when you are at a shell prompt.

How can I look at the onos-service log file (which usually doesn't contain much of anything unless there are errors starting karaf) for onos1? 

mininet-onos> sh tail -f /tmp/onos1/onos.log

$ tail -f /tmp/onos1/onos.log

What is the default control network topology?

The ONOS nodes are all connected to LinuxBridge cs1, which is connected to nat0 in the root namespace. Since all switches are in the root namespace, they share the same control network IP address with nat0.

onos1  (onos1-eth0:192.168.123.1) ---- cs1 ---- root ns (nat0-eth0:192.168.123.n+1, where n is the number of onos nodes)

This topology allows us to control the links from the onos nodes to cs1, but not the connections to individual switches. In the future we may introduce a more complicated default control network where switches have their own management IP addresses rather than sharing a single address.

Can I ssh into the ONOS cluster?

Not directly with this version of onos.py, since the nodes are not running ssh by default.

If you have a Mininet source tree, you can attach to it using mininet/util/m:

$ ~/mininet/util/mn 192.168.123.1

You can also send commands to an onos node from the mininet-onos> prompt.

mininet-onos> onos1 ifconfig

And you can also start up a new shell (use exit or control-d to exit):

mininet-onos> onos1 bash

Can I use the onos-* scripts from tools/test/bin with this environment?

Not currently, but you should not need to use them for the most part.

Troubleshooting

onos.py doesn't work - what should I do?

Here are some things you can try:

• Make sure you are running the latest version of Mininet (see below)
• Look at the log file(s) and make sure no errors are occurring: more /tmp/onos1/log; more /tmp/onos1/onos.log
• Look at the output from running mn or onos.py and carefully examine and try to understand any error or exception messages - usually they will tell you what is going wrong
• Reset your environment using: sudo pkill -f  karaf.jar; sudo mn -c
• Make sure you have built onos: cd ~/onos; buck build onos 
• Make sure you can run Mininet: sudo mn --test pingall 

Mininet doesn't work - what should I do?

First, make sure you are running Mininet 2.2.1 or later:

mn --version

If you have an older version of Mininet, you can install a newer version from source as described above. Older versions of Mininet may not include LinuxBridge, which is required by onos.py.

Next, make sure that the following command works:

sudo mnexec -n ifconfig -a

It should show a single loopback interface and no other interfaces. If this command doesn't work as expected, then Mininet will not work. If you have installed Mininet using apt-get, or from source on Ubuntu, Mininet should work correctly. However, you should make sure you don't have multiple or older versions of Mininet installed which might not work correctly with onos.py.

Once you've verified that mnexec works, you can try a sanity check for mn:

sudo mn --test pingall

This should complete without errors.

Why can s1 ping onos1, but onos1 can't ping s1 (it just pings its own loopback interface?)

Currently, all of the switches are in the root namespace. If you wish to test connectivity from a controller to a switch, try pinging nat0 instead. In the future we may add support for a more complex control network with separate IP addresses for the switch management interfaces.

By default, onos.py automatically forwards connections to the Mininet VM/server to the appropriate ONOS instance.

So if you are using a VM whose IP address is 192.168.51.131, to connect to the GUI on ONOS1, you would use the URL http://192.168.51.131:8181/onos/ui/