Due to a ransomware attack, the wiki was reverted to a July 2022 version. . We apologize for the lack of a more recent valid backup.
Welcome to the ONOS tutorial!
In this tutorial, you’ll complete a set of exercises designed to explain the main concepts of ONOS, our distributed network operating system. Soon, you'll understand how to use the basic features of ONOS.
To get you started quickly, this tutorial is distributed as a preconfigured virtual machine with the needed software. Just run the VM in VirtualBox using the instructions in the next section.
Introduction
Pre-requisites
You will need a computer with at least 2GB of RAM and at least 5GB of free hard disk space. A faster processor or solid-state drive will speed up the virtual machine boot time, and a larger screen will help to manage multiple terminal windows.
The computer can run Windows, Mac OS X, or Linux – all work fine with VirtualBox, the only software requirement.
To install VirtualBox, you will need administrative access to the machine.
The tutorial instructions requires prior knowledge of SDN in general, and OpenFlow and Mininet in particular. So please first complete the OpenFlow tutorial and the Mininet walkthrough. Although not a requirement, completing the FlowVisor tutorial before starting this one is highly recommended. Also being familiar with Apache Karaf would be helpful although not entirely required.
Stuck? Found a bug? Questions?
Email us if you’re stuck, think you’ve found a bug, or just want to send some feedback. Please have a look at the guidelines to learn how to efficiently submit a bug report.
Setup your environment
Install required software
You will need to acquire two files: a VirtualBox installer and the Tutorial VM.
After you have downloaded VirtualBox, install it, then go to the next section to verify that the VM is working on your system.
Create Virtual Machine
####REVISIT THIS######
Start up VirtualBox, then select Machine>New, give it a name, and select Linux as type and Ubuntu (64 bit) as version. Press Continue.
Next, configure the VM with 2 GB (2048 MB) of memory. Press Continue.
Select ‘Use an existing virtual hard drive file’, and point it to the vmdk file you downloaded. Select Create.
Now you can start the VM by double clicking it; once it starts you can login with user tutorial1 and password tutorial1.
After some time you should see the desktop view for ubuntu. You can open a terminal by double clicking Terminal.
Make sure to read the command prompt notes below; they’re important to knowing where to run each command.
Important Command Prompt Notes
In this tutorial, commands are shown along with a command prompt to indicate the subsystem for which they are intended.
For example,
onos>
indicates that you are in the ONOS command line, whereas
mininet>
indicates that you are in mininet.
Start Mininet
We’ll be using the same physical topology for all exercises, so now is a good time to start Mininet. The network is a simple set of six switches where the outer switches interconnected by a mesh of four switches. The diagram below shows the topology.
The outer switch each have six hosts attached to them. To start mininet with this topology, simply double click on the Mininet icon on your desktop.
Reactive Forwarding
No pings? Why?
In this exercise, we are going to run a sample app shipped with ONOS. Reactive Forwarding is a simple application which installs flows for every packet in that arrives at the controller. Go to your mininet prompt and do the following.
h1 ping h10
You will notice that the ping fails as shown below.
mininet> h11 ping -c3 h41 PING 10.0.0.19 (10.0.0.19) 56(84) bytes of data. From 10.0.0.1 icmp_seq=1 Destination Host Unreachable From 10.0.0.1 icmp_seq=2 Destination Host Unreachable From 10.0.0.1 icmp_seq=3 Destination Host Unreachable --- 10.0.0.19 ping statistics --- 3 packets transmitted, 0 received, +3 errors, 100% packet loss, time 2009ms
So why did the ping fail? Well we didn't load the reactive forwarding application. Indeed, if you list the loaded application you will see the following:
110 | Active | 80 | 1.0.0.SNAPSHOT | onos-rest 116 | Active | 80 | 1.0.0.SNAPSHOT | onos-of-api 117 | Active | 80 | 1.0.0.SNAPSHOT | onos-of-ctl 118 | Active | 80 | 1.0.0.SNAPSHOT | onos-lldp-provider 119 | Active | 80 | 1.0.0.SNAPSHOT | onos-host-provider 120 | Active | 80 | 1.0.0.SNAPSHOT | onos-of-provider-device 121 | Active | 80 | 1.0.0.SNAPSHOT | onos-of-provider-packet 122 | Active | 80 | 1.0.0.SNAPSHOT | onos-of-provider-flow 136 | Active | 80 | 1.0.0.SNAPSHOT | onos-cli 137 | Active | 80 | 8.1.15.v20140411 | Jetty :: Websocket 138 | Active | 80 | 1.0.0.SNAPSHOT | onos-gui 151 | Active | 80 | 1.0.0.SNAPSHOT | onos-core-net 152 | Active | 80 | 1.0.0.SNAPSHOT | onos-core-trivial
As you can see above, there is no reactive forwarding application loaded. Let's see how we load it.
Make it so, Number one
In your ONOS window, do
feature:install onos-app-fwd
Then, in a mininet window run the ping again, just this time don't limit the number of pings.
h11 ping h41
This time the ping is flowing:
mininet> h11 ping h41 PING 10.0.0.19 (10.0.0.19) 56(84) bytes of data. 64 bytes from 10.0.0.19: icmp_req=1 ttl=64 time=9.12 ms 64 bytes from 10.0.0.19: icmp_req=2 ttl=64 time=0.892 ms 64 bytes from 10.0.0.19: icmp_req=3 ttl=64 time=0.075 ms 64 bytes from 10.0.0.19: icmp_req=4 ttl=64 time=0.068 ms
Start stop start stop....
You have now seen that you can load applications into ONOS dynamically. Actually you can also interrupt applications while they are running so, for example, let's stop the reactive forwarding application.
stop onos-app-fwd
Observe that the ping has now stopped. This is because when the reactive forwarding application is unloaded, it cleans up after itself by removing the rules that it has pushed. We'll talk more about this in the next section. For now, let's restart the reactive forwarding application.
start onos-app-fwd
...and the ping restarts 
ONOS CLI commands
ONOS has many CLI commands. In this section, we will go through some of the most useful commands. This section may also serve as a CLI reference for you during this tutorial. While we will explain some of the ONOS CLI command here you can find an exhaustive list by running:
help onos
or more information about an individual command adding --help to any command. Also most commands have autocompletion to help you find the parameters quickly and easily.
Devices command
An SDN Controller would be nothing without devices to control. Luckily, ONOS has a convenient command to list the device currently known in the system. Running
devices
will return the following information,
onos> devices id=of:0000000000000001, available=true, role=MASTER, type=SWITCH, mfr=Nicira Networks, Inc., hw=Open vSwitch, sw=1.4.6, serial=None id=of:0000000000000002, available=true, role=MASTER, type=SWITCH, mfr=Nicira Networks, Inc., hw=Open vSwitch, sw=1.4.6, serial=None id=of:000000000000000b, available=true, role=MASTER, type=SWITCH, mfr=Nicira Networks, Inc., hw=Open vSwitch, sw=1.4.6, serial=None id=of:000000000000000c, available=true, role=MASTER, type=SWITCH, mfr=Nicira Networks, Inc., hw=Open vSwitch, sw=1.4.6, serial=None id=of:000000000000000d, available=true, role=MASTER, type=SWITCH, mfr=Nicira Networks, Inc., hw=Open vSwitch, sw=1.4.6, serial=None id=of:000000000000000e, available=true, role=MASTER, type=SWITCH, mfr=Nicira Networks, Inc., hw=Open vSwitch, sw=1.4.6, serial=None
which consists of a device id, and a boolean value which indicates whether this devices is currently up. You also get the type of device and well as it's role relationship with this ONOS instance.
Links command
The links command is used to list the links detected by ONOS. At the ONOS prompt run
links
and you should get the following output:
onos> links src=of:000000000000000e/1, dst=of:0000000000000001/5, type=DIRECT src=of:000000000000000d/1, dst=of:0000000000000001/4, type=DIRECT src=of:000000000000000e/2, dst=of:0000000000000002/5, type=DIRECT src=of:000000000000000c/1, dst=of:0000000000000001/3, type=DIRECT src=of:000000000000000d/2, dst=of:0000000000000002/4, type=DIRECT src=of:000000000000000b/1, dst=of:0000000000000001/2, type=DIRECT src=of:000000000000000c/2, dst=of:0000000000000002/3, type=DIRECT src=of:000000000000000b/2, dst=of:0000000000000002/2, type=DIRECT src=of:0000000000000002/2, dst=of:000000000000000b/2, type=DIRECT src=of:0000000000000002/3, dst=of:000000000000000c/2, type=DIRECT src=of:0000000000000001/2, dst=of:000000000000000b/1, type=DIRECT src=of:0000000000000002/4, dst=of:000000000000000d/2, type=DIRECT src=of:0000000000000001/3, dst=of:000000000000000c/1, type=DIRECT src=of:0000000000000002/5, dst=of:000000000000000e/2, type=DIRECT src=of:0000000000000001/4, dst=of:000000000000000d/1, type=DIRECT src=of:0000000000000001/5, dst=of:000000000000000e/1, type=DIRECT src=of:0000000000000002/1, dst=of:0000000000000001/1, type=DIRECT src=of:0000000000000002/2, dst=of:0000000000000001/2, type=DIRECT src=of:0000000000000001/1, dst=of:0000000000000002/1, type=DIRECT src=of:0000000000000001/2, dst=of:0000000000000002/2, type=DIRECT
The output show you the list of discovered links. Reported links are formatted by source device-port pair to destination device-port pair. The 'type' field indicates whether the link is a direct connection between two devices or not.
Hosts command
A network without hosts is a little like a city without bars, it would be a ridiculously boring place. Fortunately, ONOS has the ability to list the hosts (as opposed to bars, although that would be a great feature) currently in the system.
hosts
with this output:
onos> hosts id=00:00:00:00:00:01/-1, mac=00:00:00:00:00:01, location=of:000000000000000b/3, vlan=-1, ip(s)=[10.0.0.1] id=00:00:00:00:00:02/-1, mac=00:00:00:00:00:02, location=of:000000000000000b/4, vlan=-1, ip(s)=[10.0.0.2] id=00:00:00:00:00:03/-1, mac=00:00:00:00:00:03, location=of:000000000000000b/5, vlan=-1, ip(s)=[10.0.0.3] id=00:00:00:00:00:04/-1, mac=00:00:00:00:00:04, location=of:000000000000000b/6, vlan=-1, ip(s)=[10.0.0.4] id=00:00:00:00:00:05/-1, mac=00:00:00:00:00:05, location=of:000000000000000b/7, vlan=-1, ip(s)=[10.0.0.5] id=00:00:00:00:00:06/-1, mac=00:00:00:00:00:06, location=of:000000000000000b/8, vlan=-1, ip(s)=[10.0.0.6] id=00:00:00:00:00:07/-1, mac=00:00:00:00:00:07, location=of:000000000000000c/3, vlan=-1, ip(s)=[10.0.0.7] id=00:00:00:00:00:08/-1, mac=00:00:00:00:00:08, location=of:000000000000000c/4, vlan=-1, ip(s)=[10.0.0.8] id=00:00:00:00:00:09/-1, mac=00:00:00:00:00:09, location=of:000000000000000c/5, vlan=-1, ip(s)=[10.0.0.9] id=00:00:00:00:00:0A/-1, mac=00:00:00:00:00:0A, location=of:000000000000000c/6, vlan=-1, ip(s)=[10.0.0.10] id=00:00:00:00:00:0B/-1, mac=00:00:00:00:00:0B, location=of:000000000000000c/7, vlan=-1, ip(s)=[10.0.0.11] id=00:00:00:00:00:0C/-1, mac=00:00:00:00:00:0C, location=of:000000000000000c/8, vlan=-1, ip(s)=[10.0.0.12] id=00:00:00:00:00:0D/-1, mac=00:00:00:00:00:0D, location=of:000000000000000d/3, vlan=-1, ip(s)=[10.0.0.13] id=00:00:00:00:00:0E/-1, mac=00:00:00:00:00:0E, location=of:000000000000000d/4, vlan=-1, ip(s)=[10.0.0.14] id=00:00:00:00:00:0F/-1, mac=00:00:00:00:00:0F, location=of:000000000000000d/5, vlan=-1, ip(s)=[10.0.0.15] id=00:00:00:00:00:10/-1, mac=00:00:00:00:00:10, location=of:000000000000000d/6, vlan=-1, ip(s)=[10.0.0.16] id=00:00:00:00:00:11/-1, mac=00:00:00:00:00:11, location=of:000000000000000d/7, vlan=-1, ip(s)=[10.0.0.17] id=00:00:00:00:00:12/-1, mac=00:00:00:00:00:12, location=of:000000000000000d/8, vlan=-1, ip(s)=[10.0.0.18] id=00:00:00:00:00:13/-1, mac=00:00:00:00:00:13, location=of:000000000000000e/3, vlan=-1, ip(s)=[10.0.0.19] id=00:00:00:00:00:14/-1, mac=00:00:00:00:00:14, location=of:000000000000000e/4, vlan=-1, ip(s)=[10.0.0.20] id=00:00:00:00:00:15/-1, mac=00:00:00:00:00:15, location=of:000000000000000e/5, vlan=-1, ip(s)=[10.0.0.21] id=00:00:00:00:00:16/-1, mac=00:00:00:00:00:16, location=of:000000000000000e/6, vlan=-1, ip(s)=[10.0.0.22] id=00:00:00:00:00:17/-1, mac=00:00:00:00:00:17, location=of:000000000000000e/7, vlan=-1, ip(s)=[10.0.0.23] id=00:00:00:00:00:18/-1, mac=00:00:00:00:00:18, location=of:000000000000000e/8, vlan=-1, ip(s)=[10.0.0.24]
Which displays the hosts' id as well as its mac address and where in the network it is connected.
Flows command
The flows command allows you to observe which flow entries are currently registered in the system. Flow entries may be in several states:
- PENDING_ADD - The flow has been submitted and forwarded to the switch.
- ADDED - The flow has been added to the switch.
- PENDING_REMOVE - The request to remove the flow has been submitted and forwarded to the switch.
- REMOVED - The rule has been removed.
So let's start some traffic but going to the mininet window and running
mininet> h11 ping h41
then in the ONOS window let's run the flows command
onos> flows
you should see the following output
deviceId=of:0000000000000001, flowRuleCount=1
id=30000b889cb32, state=ADDED, bytes=8722, packets=89, duration=89, priority=10, appId=org.onlab.onos.fwd
selector=[ETH_TYPE{ethType=800}, ETH_SRC{mac=00:00:00:00:00:01}, ETH_DST{mac=00:00:00:00:00:13}, IN_PORT{port=2}]
treatment=[OUTPUT{port=5}]
deviceId=of:0000000000000002, flowRuleCount=1
id=30000b889cf4d, state=ADDED, bytes=8624, packets=88, duration=88, priority=10, appId=org.onlab.onos.fwd
selector=[ETH_TYPE{ethType=800}, ETH_SRC{mac=00:00:00:00:00:13}, ETH_DST{mac=00:00:00:00:00:01}, IN_PORT{port=5}]
treatment=[OUTPUT{port=2}]
deviceId=of:000000000000000b, flowRuleCount=2
id=30000b88a8321, state=ADDED, bytes=8722, packets=89, duration=89, priority=10, appId=org.onlab.onos.fwd
selector=[ETH_TYPE{ethType=800}, ETH_SRC{mac=00:00:00:00:00:13}, ETH_DST{mac=00:00:00:00:00:01}, IN_PORT{port=2}]
treatment=[OUTPUT{port=3}]
id=30000b88a833e, state=ADDED, bytes=8722, packets=89, duration=89, priority=10, appId=org.onlab.onos.fwd
selector=[ETH_TYPE{ethType=800}, ETH_SRC{mac=00:00:00:00:00:01}, ETH_DST{mac=00:00:00:00:00:13}, IN_PORT{port=3}]
treatment=[OUTPUT{port=1}]
deviceId=of:000000000000000c, flowRuleCount=0
deviceId=of:000000000000000d, flowRuleCount=0
deviceId=of:000000000000000e, flowRuleCount=2
id=30000b88a8e45, state=ADDED, bytes=8722, packets=89, duration=89, priority=10, appId=org.onlab.onos.fwd
selector=[ETH_TYPE{ethType=800}, ETH_SRC{mac=00:00:00:00:00:01}, ETH_DST{mac=00:00:00:00:00:13}, IN_PORT{port=1}]
treatment=[OUTPUT{port=3}]
id=30000b88a8e82, state=ADDED, bytes=8722, packets=89, duration=89, priority=10, appId=org.onlab.onos.fwd
selector=[ETH_TYPE{ethType=800}, ETH_SRC{mac=00:00:00:00:00:13}, ETH_DST{mac=00:00:00:00:00:01}, IN_PORT{port=3}]
treatment=[OUTPUT{port=2}]
As you can see from the above output, ONOS provides many details about he the flows at the switches. For example each flow entry defines a selector and treatment which is the set of traffic matched by the the flow entry and how this traffic should be handled. Notice as well that each flow entry it tagged by an appId (application id), this appId identifies which application installed this flow entry. This is a useful feature because it can help an admin identify which application may be misbehaving or consuming many resources.
Apps command
The apps command enables the user to list the applications currently running on ONOS.
onos> apps id=0, name=org.onlab.onos.net.intent id=1, name=org.onlab.onos.fwd id=2, name=org.onlab.onos.gui
As shown above the tutorial ONOS has three applications loaded. One of them is the reactive forwarding applications, we will see the other two later in this tutorial.
Paths command
Given a network topology, ONOS computes all the shortest paths between any two nodes. This is especially useful for your applications to obtain path information for either flow installation or some other use. The paths command takes two arguments, both of them are devices. To make things easy for you ONOS provides CLI autocompletion by simply hitting the <TAB> key.
onos> paths <TAB> of:0000000000000001 of:0000000000000002 of:000000000000000b of:000000000000000c of:000000000000000d of:000000000000000e
ONOS lists device options for you, thereby making it easier to find the devices you would like. For example, the output of the command below shows two paths of equal costs.
onos> paths of:000000000000000b of:000000000000000e of:000000000000000b/1-of:0000000000000001/2==>of:0000000000000001/5-of:000000000000000e/1; cost=2.0 of:000000000000000b/2-of:0000000000000002/2==>of:0000000000000002/5-of:000000000000000e/2; cost=2.0
Intent Command
blah blah
Intent Reactive Forwarding
Another sample application in ONOS is the intent reactive forwarding application. Rather than pushing flow entries for each packet the it sees the intent reactive forwarding application provisions an intent. In particular, it provisions a host to host intent which is a simple connectivity intent which enables the connectivity between two hosts.
Out with the old, In with the new
First let's start by removing the old reactive forwarding application and load the intent reactive forwarding application.
onos> feature:uninstall onos-app-fwd onos> feature:install onos-app-ifwd
NB: Notice the different bundle names: onos-app-fwd vs. onos-app-ifwd
Ok let's just make sure it is loaded correctly:
onos> apps id=0, name=org.onlab.onos.net.intent id=1, name=org.onlab.onos.fwd id=2, name=org.onlab.onos.ifwd
So we can see that the intent forwarding application is correctly loaded.
Intentionally React
Alright so let's forward some traffic.
mininet> h21 ping h31 PING 10.0.0.13 (10.0.0.13) 56(84) bytes of data. 64 bytes from 10.0.0.13: icmp_seq=1 ttl=64 time=25.7 ms 64 bytes from 10.0.0.13: icmp_seq=2 ttl=64 time=1.73 ms 64 bytes from 10.0.0.13: icmp_seq=3 ttl=64 time=0.191 ms 64 bytes from 10.0.0.13: icmp_seq=4 ttl=64 time=0.079 ms ^C --- 10.0.0.13 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3005ms rtt min/avg/max/mdev = 0.079/6.926/25.700/10.859 ms
So by using the flows command you can list the flows (by running the flows command) that the intent installed. So how is this different than the other application? Well the end result is the same but the process by which is was obtained it radically different. The intent reactive forwarding application has installed an intent between h21 and h31, as you can see by running the intents command:
onos> intents -i
id=0xffffffffe2a484dd, state=INSTALLED, type=HostToHostIntent, appId=org.onlab.onos.ifwd
constraints=[LinkTypeConstraint{inclusive=false, types=[OPTICAL]}]
installable=[
PathIntent{id=0xffffffffc68cba73, appId=DefaultApplicationId{id=2, name=org.onlab.onos.ifwd},
selector=DefaultTrafficSelector{criteria=[ETH_SRC{mac=00:00:00:00:00:0D}, ETH_DST{mac=00:00:00:00:00:07}]},
treatment=DefaultTrafficTreatment{instructions=[]}, constraints=[LinkTypeConstraint{inclusive=false, types=[OPTICAL]}],
path=DefaultPath{src=ConnectPoint{elementId=00:00:00:00:00:0D/-1, portNumber=0},
dst=ConnectPoint{elementId=00:00:00:00:00:07/-1, portNumber=0}, type=INDIRECT, state=ACTIVE, durable=false}},
PathIntent{id=0xffffffffde7767b7, appId=DefaultApplicationId{id=2, name=org.onlab.onos.ifwd},
selector=DefaultTrafficSelector{criteria=[ETH_SRC{mac=00:00:00:00:00:07}, ETH_DST{mac=00:00:00:00:00:0D}]},
treatment=DefaultTrafficTreatment{instructions=[]}, constraints=[LinkTypeConstraint{inclusive=false, types=[OPTICAL]}],
path=DefaultPath{src=ConnectPoint{elementId=00:00:00:00:00:07/-1, portNumber=0},
dst=ConnectPoint{elementId=00:00:00:00:00:0D/-1, portNumber=0}, type=INDIRECT, state=ACTIVE, durable=false}}]
So the intent forwarding app has pushed the intent you see above as evidenced by the appId field. The intent is a host to host intent which details the path along which the flows have been installed. If you would like to know more about intents or the intent framework in general have a look at this page.
Before we continue, let's remove the intent you just installed so that it doesn't get in the way of the intent gymnastics we are going to do in the next section.
onos> remove-intent <TAB>
The <tab> key will autocomplete the id that was associated the intent we just pushed. You should now see that your intent is in withdrawn state.
onos> intents
id=0xffffffffe2a484dd, state=WITHDRAWN, type=HostToHostIntent, appId=org.onlab.onos.ifwd
constraints=[LinkTypeConstraint{inclusive=false, types=[OPTICAL]}]
State your intentions
One major advantage of using intents over simply using flow entries to program your network is that intents track the state of the network and reconfigure themselves in order to satisfy your intention. For example, if link were to go down the intent framework would reroute your intent (ie. your flows) onto an alternative path. But, what if there are no alternative path? Well, in this case the intent would enter the failed state and remain there until a path becomes available. Pretty cool, eh? Let's check this out in action.
Let's start by looking at the set of hosts know to ONOS. If you ran through this tutorial exactly there should be four hosts
onos> hosts id=00:00:00:00:00:01/-1, mac=00:00:00:00:00:01, location=of:000000000000000b/3, vlan=-1, ip(s)=[10.0.0.1] id=00:00:00:00:00:07/-1, mac=00:00:00:00:00:07, location=of:000000000000000c/3, vlan=-1, ip(s)=[10.0.0.7] id=00:00:00:00:00:0D/-1, mac=00:00:00:00:00:0D, location=of:000000000000000d/3, vlan=-1, ip(s)=[10.0.0.13] id=00:00:00:00:00:13/-1, mac=00:00:00:00:00:13, location=of:000000000000000e/3, vlan=-1, ip(s)=[10.0.0.19]
Pick any any of these two hosts and install a host to host intent for them.
onos> add-host-intent 00:00:00:00:00:01/-1 00:00:00:00:00:13/-1
This command will provision a path between 10.0.0.1 (h11) and 10.0.0.19 (h41) and you can see that the intent is installed.
onos> intents
id=0xffffffff8f64cf44, state=INSTALLED, type=HostToHostIntent, appId=org.onlab.onos.cli
constraints=[LinkTypeConstraint{inclusive=false, types=[OPTICAL]}]
So now that the intent is installed let's have a look what path it is using. Be careful here as the output from the tutorial and what you actually may vary slightly as all alternatives paths here have equal cost and therefore ONOS is free to pick either one.
onos> flows
deviceId=of:0000000000000001, flowRuleCount=2
id=10000c364dd58, state=ADDED, bytes=0, packets=0, duration=1781, priority=123, appId=org.onlab.onos.net.intent
selector=[IN_PORT{port=2}, ETH_SRC{mac=00:00:00:00:00:01}, ETH_DST{mac=00:00:00:00:00:13}]
treatment=[OUTPUT{port=5}]
id=10000c364ddb2, state=ADDED, bytes=0, packets=0, duration=1781, priority=123, appId=org.onlab.onos.net.intent
selector=[IN_PORT{port=5}, ETH_SRC{mac=00:00:00:00:00:13}, ETH_DST{mac=00:00:00:00:00:01}]
treatment=[OUTPUT{port=2}]
deviceId=of:0000000000000002, flowRuleCount=0
deviceId=of:000000000000000b, flowRuleCount=2
id=10000c3659528, state=ADDED, bytes=0, packets=0, duration=1781, priority=123, appId=org.onlab.onos.net.intent
selector=[IN_PORT{port=1}, ETH_SRC{mac=00:00:00:00:00:13}, ETH_DST{mac=00:00:00:00:00:01}]
treatment=[OUTPUT{port=3}]
id=10000c3659564, state=ADDED, bytes=0, packets=0, duration=1781, priority=123, appId=org.onlab.onos.net.intent
selector=[IN_PORT{port=3}, ETH_SRC{mac=00:00:00:00:00:01}, ETH_DST{mac=00:00:00:00:00:13}]
treatment=[OUTPUT{port=1}]
deviceId=of:000000000000000c, flowRuleCount=0
deviceId=of:000000000000000d, flowRuleCount=0
deviceId=of:000000000000000e, flowRuleCount=2
id=10000c365a06b, state=ADDED, bytes=0, packets=0, duration=1781, priority=123, appId=org.onlab.onos.net.intent
selector=[IN_PORT{port=1}, ETH_SRC{mac=00:00:00:00:00:01}, ETH_DST{mac=00:00:00:00:00:13}]
treatment=[OUTPUT{port=3}]
id=10000c365a0a7, state=ADDED, bytes=0, packets=0, duration=1781, priority=123, appId=org.onlab.onos.net.intent
selector=[IN_PORT{port=3}, ETH_SRC{mac=00:00:00:00:00:13}, ETH_DST{mac=00:00:00:00:00:01}]
treatment=[OUTPUT{port=1}]
We can see that the traffic flows between dpid 00:00:00:00:00:00:00:01 (s1) and 00:00:00:00:00:00:00:0b (s11). If you have trouble seeing this, refer to the topology diagram in the beginning of this tutorial.
Ok so let's teardown the link between s1 and s11. This can be done in mininet by running:
mininet> link s1 s11 down
and let's have a look at the flows again.
onos> flows
deviceId=of:0000000000000001, flowRuleCount=0
deviceId=of:0000000000000002, flowRuleCount=2
id=10000c364e119, state=ADDED, bytes=0, packets=0, duration=1, priority=123, appId=org.onlab.onos.net.intent
selector=[IN_PORT{port=2}, ETH_SRC{mac=00:00:00:00:00:01}, ETH_DST{mac=00:00:00:00:00:13}]
treatment=[OUTPUT{port=5}]
id=10000c364e173, state=ADDED, bytes=0, packets=0, duration=1, priority=123, appId=org.onlab.onos.net.intent
selector=[IN_PORT{port=5}, ETH_SRC{mac=00:00:00:00:00:13}, ETH_DST{mac=00:00:00:00:00:01}]
treatment=[OUTPUT{port=2}]
deviceId=of:000000000000000b, flowRuleCount=2
id=10000c3659547, state=ADDED, bytes=0, packets=0, duration=1, priority=123, appId=org.onlab.onos.net.intent
selector=[IN_PORT{port=2}, ETH_SRC{mac=00:00:00:00:00:13}, ETH_DST{mac=00:00:00:00:00:01}]
treatment=[OUTPUT{port=3}]
id=10000c3659565, state=ADDED, bytes=0, packets=0, duration=1, priority=123, appId=org.onlab.onos.net.intent
selector=[IN_PORT{port=3}, ETH_SRC{mac=00:00:00:00:00:01}, ETH_DST{mac=00:00:00:00:00:13}]
treatment=[OUTPUT{port=2}]
deviceId=of:000000000000000c, flowRuleCount=0
deviceId=of:000000000000000d, flowRuleCount=0
deviceId=of:000000000000000e, flowRuleCount=2
id=10000c365a08a, state=ADDED, bytes=0, packets=0, duration=1, priority=123, appId=org.onlab.onos.net.intent
selector=[IN_PORT{port=2}, ETH_SRC{mac=00:00:00:00:00:01}, ETH_DST{mac=00:00:00:00:00:13}]
treatment=[OUTPUT{port=3}]
id=10000c365a0a8, state=ADDED, bytes=0, packets=0, duration=1, priority=123, appId=org.onlab.onos.net.intent
selector=[IN_PORT{port=3}, ETH_SRC{mac=00:00:00:00:00:13}, ETH_DST{mac=00:00:00:00:00:01}]
treatment=[OUTPUT{port=2}]
Observe that the flows moved from 00:00:00:00:00:00:00:01 to 00:00:00:00:00:00:00:02 (s2) and the remaining flows remained untouched. How did this happen? Well when we tore down the link between s1 and s11, ONOS detected this change and informed all people interested by this event that the link went down. Therefore the intent service receives this information and realises that one of its intents is affected by this change and thus it recompiles the intent in light of this change which causes the intent to be installed on a different path.
This simple example shows that using intents is more powerful than simply installing flows. Intents maintain your intention (hence the name!) while retaining the ability to install them as is possible or most efficient.
Up down up down
If you wish you can take down more links and see what happens. Obviously, if you partition the network then no flows will be installed, sadly ONOS doesn't grow links between switches yet. You can bring up links in mininet by:
mininet> link s1 s11 up
Have fun!