Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

So why did the ping fail? Well, there are no flows installed on the data-plane, which forward the traffic appropriately. ONOS comes with a simple Reactive Forwarding app that installs forwarding flows on demand, but this application is not activated by default. To see apps that are presently active, type the apps -a -s command and you will see the following output:

Code Block
languagetext
onos> apps -a -s
*  36 org.onosproject.optical-model        1.12.0   Optical Network Model
*  40 org.onosproject.openflow-base        1.12.0   OpenFlow Base Provider
*  41 org.onosproject.lldpprovider         1.12.0   LLDP Link Provider
*  44 org.onosproject.hostprovider         1.12.0   Host Location Provider
*  47 org.onosproject.drivers              1.12.0   Default Drivers
* 104 org.onosproject.openflow             1.12.0   OpenFlow Provider Suite
* 288 org.onosproject.proxyarp             1.12.0   Proxy ARP/NDP

Note: To see all installed apps, regardless whether they are active or not, use the same command, but without the -a flag. You should see over 140 different apps listed when you do that.

As you can see above, there is no reactive forwarding application loadedcurrently active. Let's see how we load activate it.

Make it so, Number one

...

Code Block
languagetext
onos> devices
id=of:0000000000000001, available=true, local-status=connected 41m31s ago, role=MASTERSTANDBY, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitch, sw=2.15.32, serial=None, protocol=OF_10
id=of:0000000000000002driver=ovs, available=truechannelId=172.17.0.1:38710, rolelocType=MASTERgeo, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitch, sw=2.1.3, serial=NonemanagementAddress=172.17.0.1, name=Spine-1, protocol=OF_1013
id=of:000000000000000b0000000000000002, available=true, local-status=connected 41m31s ago, role=MASTERSTANDBY, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitch, sw=2.15.32, serial=None, driver=ovs, channelId=172.17.0.1:38728, locType=geo, managementAddress=172.17.0.1, name=Spine-2, protocol=OF_1013
id=of:000000000000000c000000000000000b, available=true, role=MASTERlocal-status=connected 41m31s ago, role=STANDBY, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitch, sw=2.15.32, serial=None, protocol=OF_10
id=of:000000000000000ddriver=ovs, available=truechannelId=172.17.0.1:38702, rolelocType=MASTERgeo, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitch, sw=2.1.3, serial=NonemanagementAddress=172.17.0.1, name=Leaf-1, protocol=OF_1013
id=of:000000000000000e000000000000000c, available=true, local-status=connected 41m31s ago, role=MASTER, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitch, sw=2.15.32, serial=None, protocol=OF_10

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

Code Block
onos> links

and you should get the following output:

driver=ovs, channelId=172.17.0.1:38730, locType=geo, managementAddress=172.17.0.1, name=Leaf-2, protocol=OF_13
id=of:000000000000000d, available=true, local-status=connected 41m31s ago, role=MASTER, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitch, sw=2.5.2, serial=None, driver=ovs, channelId=172.17.0.1:38720, locType=geo, managementAddress=172.17.0.1, name=Leaf-3, protocol=OF_13
id=of:000000000000000e, available=true, local-status=connected 41m31s ago, role=STANDBY, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitch, sw=2.5.2, serial=None, driver=ovs, channelId=172.17.0.1:38716, locType=geo, managementAddress=172.17.0.1, name=Leaf-4, protocol=OF_13

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 and other various attributes attached to each device.

Links command

 Similarly, the links command is used to list the links detected by ONOS. At the ONOS prompt run

Code Block
onos> links

and you should get the following output:

Code Block
languagetext
onos> links
src=of:0000000000000001/1, dst=of:000000000000000b/1
Code Block
languagetext
onos> links
src=of:000000000000000e/1, dst=of:0000000000000001/5, type=DIRECT, state=ACTIVE
src=of:000000000000000d/1, dst=of:0000000000000001/4, type=DIRECT, state=ACTIVE
src=of:000000000000000e/2, dst=of:0000000000000002/5, type=DIRECT, state=ACTIVE
src=of:000000000000000c/1, dst=of:0000000000000001/3, type=DIRECT, state=ACTIVE
src=of:000000000000000d/2, dst=of:0000000000000002/4, type=DIRECT, state=ACTIVE
src=of:000000000000000b/1, dst=of:0000000000000001/2, type=DIRECT, state=ACTIVE
src=of:000000000000000c/2, dst=of:0000000000000002/3, type=DIRECT, state=ACTIVE
src=of:000000000000000b/2, dst=of:0000000000000002/2, type=DIRECT, state=ACTIVE
src=of:0000000000000002/2, dst=of:000000000000000b/2, type=DIRECT, state=ACTIVE
src=of:0000000000000001/2, dst=of:000000000000000b/1, type=DIRECT, state=ACTIVE
src=of:0000000000000002/3, dst=of:000000000000000c/2, type=DIRECT, state=ACTIVE
src=of:0000000000000001/3, dst=of:000000000000000c/1, type=DIRECT, state=ACTIVE
src=of:0000000000000002/4, dst=of:000000000000000d/2, type=DIRECT, state=ACTIVE, expected=false
src=of:0000000000000001/42, dst=of:000000000000000d000000000000000c/1, type=DIRECT, state=ACTIVE, expected=false
src=of:00000000000000020000000000000001/53, dst=of:000000000000000e000000000000000d/21, type=DIRECT, state=ACTIVE, expected=false
src=of:0000000000000001/54, dst=of:000000000000000e/1, type=DIRECT, state=ACTIVE, expected=false
src=of:0000000000000002/1, dst=of:0000000000000001000000000000000b/12, type=DIRECT, state=ACTIVE, expected=false
src=of:00000000000000010000000000000002/12, dst=of:0000000000000002000000000000000c/12, type=DIRECT, state=ACTIVE, expected=false
...

The output shows you the list of discovered links. Reported links are formatted by source device-port pair to destination device-port pair. The 'The type' field indicates whether the link is a direct connection between two devices or not. 

...

Code Block
languagetext
onos> hosts
id=00:00:00:00:00:01/-1None, mac=00:00:00:00:00:01, locationlocations=[of:000000000000000b/3], vlan=-1None, ip(s)=[10.0.0.1], provider=of:org.onosproject.provider.host, configured=false
id=00:00:00:00:00:1302/-1None, mac=00:00:00:00:00:1302, locationlocations=[of:000000000000000e000000000000000b/34], vlan=-1None, ip(s)=[10.0.0.19]

Which displays the hosts' id as well as its mac address and where in the network it is connected. The '-1' in the id field is used to display the vlan information, in this case there is no vlan (wink).

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 by going to the mininet window and running

Code Block
mininet> h11 ping h41

then in the ONOS window let's run the flows command

Code Block
onos> flows

you should see the following output

Code Block
languagetext
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{mac2], provider=of:org.onosproject.provider.host, configured=false
id=00:00:00:00:00:03/None, mac=00:00:00:00:00:03, locations=[of:000000000000000b/5], vlan=None, ip(s)=[10.0.0.3], provider=of:org.onosproject.provider.host, configured=false
id=00:00:00:00:00:04/None, mac=00:00:00:00:00:04, locations=[of:000000000000000b/6], vlan=None, ip(s)=[10.0.0.4], provider=of:org.onosproject.provider.host, configured=false
id=00:00:00:00:00:01}05/None, ETH_DST{mac=00:00:00:00:00:13}05, 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{maclocations=[of:000000000000000b/7], vlan=None, ip(s)=[10.0.0.5], provider=of:org.onosproject.provider.host, configured=false
id=00:00:00:00:00:13}06/None, ETH_DST{mac=00:00:00:00:00:01}06, 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.

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.

Code Block
languagetext
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.

Code Block
languagetext
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

The intent command allows one to see what intents are stored in the system. Intents can be in several states:

  • SUBMITTED - The intent has been submitted and will be processed soon.
  • COMPILING - The intent is being compiled. This is a transient state.
  • INSTALLING - The intent is in the process of being installed. 
  • INSTALLED - The intent has been installed.
  • RECOMPILING - The intent is being recompiled after a failure.
  • WITHDRAWING - The intent is being withdrawn.
  • WITHDRAWN - The intent has been removed.
  • FAILED - The intent is in a failed state because it cannot be satisfied.

For more information about Intents go here.

Code Block
languagetext
onos> intents
id=0x0, state=INSTALLED, type=HostToHostIntent, appId=org.onlab.onos.gui
	constraints=[LinkTypeConstraint{inclusive=false, types=[OPTICAL]}]
id=0x1, state=WITHDRAWN, type=HostToHostIntent, appId=org.onlab.onos.cli
	constraints=[LinkTypeConstraint{inclusive=false, types=[OPTICAL]}]

Note: You will not see any intents until some have been added. In the next section of the tutorial, you will load the intent reactive forwarding application, which automatically adds intents as needed.

The command can also tell you what type of sub-intents the intent has been compiled to:

Code Block
languagetext
onos> intents -i
id=0x2, state=INSTALLED, type=HostToHostIntent, appId=org.onlab.onos.ifwd
    constraints=[LinkTypeConstraint{inclusive=false, types=[OPTICAL]}]
    installable=[
PathIntent{id=0x4, 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=0x5, 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}}]

For example, this host to host intent has been compiled to two path intents with the appropriate traffic selections and actions computed on your behalf.

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 

Code Block
languagetext
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. 

Code Block
languagetext
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.

Code Block
languagetext
onos> intents
id=0x9, 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 see may vary slightly as all alternate paths here have equal cost and therefore ONOS is free to pick either one.

locations=[of:000000000000000c/3], vlan=None, ip(s)=[10.0.0.6], provider=of:org.onosproject.provider.host, configured=false
id=00:00:00:00:00:07/None, mac=00:00:00:00:00:07, locations=[of:000000000000000c/4], vlan=None, ip(s)=[10.0.0.7], provider=of:org.onosproject.provider.host, configured=false
...

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 by going to the mininet window and running

Code Block
mininet> h11 ping h41

then in the ONOS window let's run the flows command

Code Block
onos> flows

you should see the following output

Code Block
languagetext
onos> flows
deviceId=of:0000000000000001, flowRuleCount=6
    id=100007a585b6f, state=ADDED, bytes=330966, packets=4086, duration=3159, liveType=UNKNOWN, priority=40000, tableId=0, appId=org.onosproject.core, payLoad=null, selector=[ETH_TYPE:bddp], treatment=DefaultTrafficTreatment{immediate=[OUTPUT:CONTROLLER], deferred=[], transition=None, meter=[], cleared=true, StatTrigger=null, metadata=null}
    id=100009465555a, state=ADDED, bytes=330966, packets=4086, duration=3159, liveType=UNKNOWN, priority=40000, tableId=0, appId=org.onosproject.core, payLoad=null, selector=[ETH_TYPE:lldp], treatment=DefaultTrafficTreatment{immediate=[OUTPUT:CONTROLLER], deferred=[], transition=None, meter=[], cleared=true, StatTrigger=null, metadata=null}
    id=10000ea6f4b8e, state=ADDED, bytes=0, packets=0, duration=3159, liveType=UNKNOWN, priority=40000, tableId=0, appId=org.onosproject.core, payLoad=null, selector=[ETH_TYPE:arp], treatment=DefaultTrafficTreatment{immediate=[OUTPUT:CONTROLLER], deferred=[], transition=None, meter=[], cleared=true, StatTrigger=null, metadata=null}
    id=125000008756fbe, state=PENDING_ADD, bytes=0, packets=0, duration=0, liveType=UNKNOWN, priority=10, tableId=0, appId=org.onosproject.fwd, payLoad=null, selector=[IN_PORT:1, ETH_DST:00:00:00:00:00:10, ETH_SRC:00:00:00:00:00:01], treatment=DefaultTrafficTreatment{immediate=[OUTPUT:4], deferred=[], transition=None, meter=[], cleared=false, StatTrigger=null, metadata=null}
    id=1000000ea1bfb, state=ADDED, bytes=0, packets=0, duration=1097, liveType=UNKNOWN, priority=5, tableId=0, appId=org.onosproject.core, payLoad=null, selector=[ETH_TYPE:arp], treatment=DefaultTrafficTreatment{immediate=[OUTPUT:CONTROLLER], deferred=[], transition=None, meter=[], cleared=true, StatTrigger=null, metadata=null}
    id=10000021b41dc, state=ADDED, bytes=98, packets=1, duration=1097, liveType=UNKNOWN, priority=5, tableId=0, appId=org.onosproject.core, payLoad=null, selector=[ETH_TYPE:ipv4], treatment=DefaultTrafficTreatment{immediate=[OUTPUT:CONTROLLER], deferred=[], transition=None, meter=[], cleared=true, StatTrigger=null, metadata=null}
deviceId=of:0000000000000002, flowRuleCount=6
    id=1000002bbd8d4, state=ADDED, bytes=330804, packets=4084, duration=3160, liveType=UNKNOWN, priority=40000, tableId=0, appId=org.onosproject.core, payLoad=null, selector=[ETH_TYPE:lldp], treatment=DefaultTrafficTreatment{immediate=[OUTPUT:CONTROLLER], deferred=[], transition=None, meter=[], cleared=true, StatTrigger=null, metadata=null}
...

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.

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.

Code Block
languagetext
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.

Code Block
languagetext
onos> paths of:000000000000000e of:000000000000000b
of:000000000000000e/2-of:0000000000000002/4==>of:0000000000000002/1-of:000000000000000b/2; cost=2.0
of:000000000000000e/1-of:0000000000000001/4==>of:0000000000000001/1-of:000000000000000b/1; cost=2.0

Intent Command

The intent command allows one to see what intents are stored in the system. Intents can be in several states:

  • SUBMITTED - The intent has been submitted and will be processed soon.
  • COMPILING - The intent is being compiled. This is a transient state.
  • INSTALLING - The intent is in the process of being installed. 
  • INSTALLED - The intent has been installed.
  • RECOMPILING - The intent is being recompiled after a failure.
  • WITHDRAWING - The intent is being withdrawn.
  • WITHDRAWN - The intent has been removed.
  • FAILED - The intent is in a failed state because it cannot be satisfied.

For more information about Intents go here.

Code Block
languagetext
onos> intents
id=0x0, state=INSTALLED, type=HostToHostIntent, appId=org.onlab.onos.gui
	constraints=[LinkTypeConstraint{inclusive=false, types=[OPTICAL]}]
id=0x1, state=WITHDRAWN, type=HostToHostIntent, appId=org.onlab.onos.cli
	constraints=[LinkTypeConstraint{inclusive=false, types=[OPTICAL]}]

Note: You will not see any intents until some have been added. In the next section of the tutorial, you will add explicit host connectivity intent.

The command can also tell you what type of sub-intents the intent has been compiled to:

Code Block
languagetext
onos> intents -i
id=0x2, state=INSTALLED, type=HostToHostIntent, appId=org.onlab.onos.ifwd
    constraints=[LinkTypeConstraint{inclusive=false, types=[OPTICAL]}]
    installable=[
PathIntent{id=0x4, 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=0x5, appId=DefaultApplicationId{id=2, name=org.onlab.onos.ifwd},
	selector=DefaultTrafficSelector{criteria=[
Code Block
languagetext
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:0107}, ETH_DST{mac=00:00:00:00:00:130D}]
      },
	treatment=[OUTPUTDefaultTrafficTreatment{portinstructions=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{macconstraints=[LinkTypeConstraint{inclusive=false, types=[OPTICAL]}], 	
	path=DefaultPath{src=ConnectPoint{elementId=00:00:00:00:00:13}, ETH_DST{mac07/-1, portNumber=0}, 
						dst=ConnectPoint{elementId=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=0D/-1, portNumber=0}, type=INDIRECT, state=ACTIVE, durable=false}}]

For example, this host to host intent has been compiled to two path intents with the appropriate traffic selections and actions computed on your behalf.

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.

First, let's deactivate the Reactive Forwarding application though:

Code Block
languagetext
onos> app deactivate fwd
Deactivated org.onosproject.fwd


Next, let's add a host connectivity intent for some two end-station hosts. You can use argument completion by pressing the Tab key.

Code Block
languagetext
onos> add-host-intent 00:00:00:00:00:13}, ETH_DST{mac=0001/None 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=10/None
Host to Host intent submitted:
HostToHostIntent{id=0x0, key=0x0, appId=DefaultApplicationId{id=2, name=org.onosproject.cli}, priority=100, resources=[00:00:00:00:00:01}/None, 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{mac10/None], selector=DefaultTrafficSelector{criteria=[]}, treatment=DefaultTrafficTreatment{immediate=[NOACTION], deferred=[], transition=None, meter=[], cleared=false, StatTrigger=null, metadata=null}, constraints=[LinkTypeConstraint{inclusive=false, types=[OPTICAL]}], resourceGroup=null, one=00:00:00:00:00:01}/None, ETH_DST{mactwo=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=10/None}

This command will provision a path between 10.0.0.1 (h11) and 10.0.0.16 (h41) and you can see that the intent is installed.

Code Block
languagetext
onos> intents
Id: 0x0
State: INSTALLED
Key: 0x0
Intent type: HostToHostIntent
Application Id: org.onosproject.cli
Resources: [00:00:00:00:00:13}01/None, ETH_DST{mac=00:00:00:00:00:01}10/None]
Treatment: [NOACTION]
Constraints:     treatment=[OUTPUT{port=1}]

...

[LinkTypeConstraint{inclusive=false, types=[OPTICAL]}]
Source host: 00:00:00:00:00:01

...

/None
Destination host: 00:00:00:00:00:10/None


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, you may have to teardown the link between s2 and s11 so pay attention to the flows command output. This can be done in mininet by running:

Code Block
mininet> link s1 s11 down

still have the h11 ping h41 command running, you will see that the ICMP pings are still working beetween the two hosts.

So now that the intent is installed, and let's have a look at the flows again.what path it is using by using the flows command with summarized output using the -s flag for better readability:

Code Block
languagetext
onos> flows -s
deviceId=of:0000000000000001, flowRuleCount=0
deviceId=of:0000000000000002, flowRuleCount=2
3
    id=10000c364e119ADDED, bytes=429138, statepackets=ADDED5298, bytestable=0, packetspriority=040000, duration=1, priority=123, appId=org.onlab.onos.net.intentselector=[ETH_TYPE:bddp], treatment=[immediate=[OUTPUT:CONTROLLER], clearDeferred]
    ADDED, bytes=429138, packets=5298, 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}table=0, priority=40000, selector=[ETH_TYPE:lldp], treatment=[immediate=[OUTPUT:CONTROLLER], clearDeferred]
   id=10000c364e173, state=ADDED, bytes=0, packets=0, durationtable=10, priority=123, appId=org.onlab.onos.net.intent
      40000, 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}ETH_TYPE:arp], treatment=[immediate=[OUTPUT:CONTROLLER], clearDeferred]
deviceId=of:000000000000000b0000000000000002, flowRuleCount=25
   id=10000c3659547, state=ADDED, bytes=0428976, packets=05296, durationtable=10, priority=123, appId=org.onlab.onos.net.intent
      40000, 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}ETH_TYPE:lldp], treatment=[immediate=[OUTPUT:CONTROLLER], clearDeferred]
   id=10000c3659565, state=ADDED, bytes=0, packets=0, durationtable=10, priority=123, appId=org.onlab.onos.net.intent
      40000, selector=[IN_PORT{port=3}, ETH_SRC{mac=00:00:00:00:00:01}, ETH_DST{mac=00:00:00:00:00:13}ETH_TYPE:arp], treatment=[immediate=[OUTPUT:CONTROLLER], clearDeferred]
    ADDED, bytes=428976, treatment=[OUTPUT{port=2}]
deviceId=of:000000000000000c, flowRuleCount=0
deviceId=of:000000000000000d, flowRuleCount=0
deviceId=of:000000000000000e, flowRuleCount=2
   id=10000c365a08a, state=packets=5296, table=0, priority=40000, selector=[ETH_TYPE:bddp], treatment=[immediate=[OUTPUT:CONTROLLER], clearDeferred]
    ADDED, bytes=032536, packets=0332, durationtable=10, priority=123, appId=org.onlab.onos.net.intent
      100, selector=[IN_PORT{port=2}:1, ETH_SRC{mac=DST:00:00:00:00:00:01}10, ETH_DST{mac=SRC:00:00:00:00:00:13}]
     01], treatment=[immediate=[OUTPUT{port=3}:4]]
   id=10000c365a0a8, state=ADDED, bytes=032536, packets=0332, durationtable=10, priority=123100, appId=org.onlab.onos.net.intent
      selector=[selector=[IN_PORT{port=3}:4, ETH_SRC{mac=DST:00:00:00:00:00:13}01, ETH_DST{mac=SRC:00:00:00:00:00:01}]
     :10], treatment=[immediate=[OUTPUT:1]]
deviceId=of:000000000000000b, flowRuleCount=5
    ADDED, bytes=214407, packets=2647, table=0, priority=40000, selector=[ETH_TYPE:bddp], 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:

Code Block
mininet> link s1 s11 up

Have fun!

ONOS Graphical User Interface

ONOS comes with a GUI. The GUI allows you to manipulate your network in a simple way.

To open the UI simply click on the 'ONOS GUI' icon. Initially, when the UI loads up you will see your network's topology over a map of the US. You can remove the map by hitting 'b'. In fact, the UI has a cheat sheet which can be toggled by hitting '/' which is easy to remember because it's the question mark key except you don't need to hit shift. 

Ok let's make all the hosts appear in the UI, we can do this by making the hosts talk on the network. The best way to do this is to run the pingall command at mininet.

Code Block
mininet> pingall
*** Ping: testing ping reachability                                                                 
h11 -> h12 h13 h14 h15 h16 h21 h22 h23 h24 h25 h26 h31 h32 h33 h34 h35 h36 h41 h42 h43 h44 h45 h46  
h12 -> h11 h13 h14 h15 h16 h21 h22 h23 h24 h25 h26 h31 h32 h33 h34 h35 h36 h41 h42 h43 h44 h45 h46  
h13 -> h11 h12 h14 h15 h16 h21 h22 h23 h24 h25 h26 h31 h32 h33 h34 h35 h36 h41 h42 h43 h44 h45 h46  
h14 -> h11 h12 h13 h15 h16 h21 h22 h23 h24 h25 h26 h31 h32 h33 h34 h35 h36 h41 h42 h43 h44 h45 h46  
h15 -> h11 h12 h13 h14 h16 h21 h22 h23 h24 h25 h26 h31 h32 h33 h34 h35 h36 h41 h42 h43 h44 h45 h46  
h16 -> h11 h12 h13 h14 h15 h21 h22 h23 h24 h25 h26 h31 h32 h33 h34 h35 h36 h41 h42 h43 h44 h45 h46  
h21 -> h11 h12 h13 h14 h15 h16 h22 h23 h24 h25 h26 h31 h32 h33 h34 h35 h36 h41 h42 h43 h44 h45 h46  
h22 -> h11 h12 h13 h14 h15 h16 h21 h23 h24 h25 h26 h31 h32 h33 h34 h35 h36 h41 h42 h43 h44 h45 h46  
.....

The hosts will not appear initially, simply type 'h' in your browser window and they will appear. At this point you should see something roughly similar to the image below. 

Image Removed

GUI Features

GUI Cheat Sheet

At anytime you can pull up the GUI's cheat sheet by typing '/' (which is '?' without the pesky shift (wink)) and you will get a pane that looks like below.

Image Removed

Summary pane

The GUI comes with a very useful summary pane. It shows you a  summary of what is going on at this ONOS cluster.

Image Removed

Switch details

When you click on a switch a pane appears on the right hand side. This pane gives information about the switch as shown in the image below.

Image Removed

You my notice that the UI reports nine ports but you can only see eight, this is because OpenFlow switches have virtual ports that are hard to show on a UI. 

Shift click will unselect the switch and remove the pane

Instances

The GUI has the ability to show which ONOS instances are active. By hitting the 'i' key (it will be open by default) you will see a pane show up on the left hand side as shown below.

Image Removed

Notice that the glyphs for the switches changes color, this indicates which switches are controlled by which instance. This is useful to see at a glance which switches are controlled by which ONOS instance.

Install Intent

Ok let's install an intent using the UI. First select two hosts by clicking on one host then shift-click on another. Let's pick 10.0.0.20 and 10.0.0.9. Now a pane will appear on the right and side of the screen as here:

Image Removed

Now click on 'Create Host-to-host Flow', this actually provisions a host to host intent and lights up the path used by the intent. 

Image Removed

You can check that the intent was installed via the ONOS cli

Code Block
languagetext
onos> intents 
	id=0x223838ca, state=INSTALLED, type=HostToHostIntent, appId=org.onlab.onos.gui
	[LinkTypeConstraint{inclusive=false, types=[OPTICAL]}]

Now let's send some traffic on that intent. This will animate the link to show traffic and display how much traffic (counter value) is flowing through that link

Code Block
mininet> h42 ping h23

Show all traffic

Another thing you can do is to visually monitor the network traffic in the UI. You can cycle between different modes, e.g. port stats in bits/s or packets/s and flow stats in bits/s or packets/s, by pressing the A key.

Play on

Now you know the main features of the UI. We encourage you to play around with it to find out what other features you can use and who knows may find a few bugs.

Exploring Further

Here we just scratched the surface of what ONOS can do in terms of controlling a network. We highly encourage you to continue using ONOS and perhaps start developing your own applications. Find out how to get started in this tutorial.

Return To : Tutorials and Walkthroughs

immediate=[OUTPUT:CONTROLLER], clearDeferred]
    ADDED, bytes=214407, packets=2647, table=0, priority=40000, selector=[ETH_TYPE:lldp], treatment=[immediate=[OUTPUT:CONTROLLER], clearDeferred]
    ADDED, bytes=294, packets=7, table=0, priority=40000, selector=[ETH_TYPE:arp], treatment=[immediate=[OUTPUT:CONTROLLER], clearDeferred]
    ADDED, bytes=32536, packets=332, table=0, priority=100, selector=[IN_PORT:2, ETH_DST:00:00:00:00:00:01, ETH_SRC:00:00:00:00:00:10], treatment=[immediate=[OUTPUT:3]]
    ADDED, bytes=32536, packets=332, table=0, priority=100, selector=[IN_PORT:3, ETH_DST:00:00:00:00:00:10, ETH_SRC:00:00:00:00:00:01], treatment=[immediate=[OUTPUT:2]]
deviceId=of:000000000000000c, flowRuleCount=3
    ADDED, bytes=214245, packets=2645, table=0, priority=40000, selector=[ETH_TYPE:bddp], treatment=[immediate=[OUTPUT:CONTROLLER], clearDeferred]
    ADDED, bytes=210, packets=5, table=0, priority=40000, selector=[ETH_TYPE:arp], treatment=[immediate=[OUTPUT:CONTROLLER], clearDeferred]
    ADDED, bytes=214245, packets=2645, table=0, priority=40000, selector=[ETH_TYPE:lldp], treatment=[immediate=[OUTPUT:CONTROLLER], clearDeferred]
deviceId=of:000000000000000d, flowRuleCount=3
    ADDED, bytes=210, packets=5, table=0, priority=40000, selector=[ETH_TYPE:arp], treatment=[immediate=[OUTPUT:CONTROLLER], clearDeferred]
    ADDED, bytes=214245, packets=2645, table=0, priority=40000, selector=[ETH_TYPE:bddp], treatment=[immediate=[OUTPUT:CONTROLLER], clearDeferred]
    ADDED, bytes=214245, packets=2645, table=0, priority=40000, selector=[ETH_TYPE:lldp], treatment=[immediate=[OUTPUT:CONTROLLER], clearDeferred]
deviceId=of:000000000000000e, flowRuleCount=5
    ADDED, bytes=214245, packets=2645, table=0, priority=40000, selector=[ETH_TYPE:lldp], treatment=[immediate=[OUTPUT:CONTROLLER], clearDeferred]
    ADDED, bytes=630, packets=15, table=0, priority=40000, selector=[ETH_TYPE:arp], treatment=[immediate=[OUTPUT:CONTROLLER], clearDeferred]
    ADDED, bytes=214245, packets=2645, table=0, priority=40000, selector=[ETH_TYPE:bddp], treatment=[immediate=[OUTPUT:CONTROLLER], clearDeferred]
    ADDED, bytes=32536, packets=332, table=0, priority=100, selector=[IN_PORT:2, ETH_DST:00:00:00:00:00:10, ETH_SRC:00:00:00:00:00:01], treatment=[immediate=[OUTPUT:3]]
    ADDED, bytes=32536, packets=332, table=0, priority=100, selector=[IN_PORT:3, ETH_DST:00:00:00:00:00:01, ETH_SRC:00:00:00:00:00:10], treatment=[immediate=[OUTPUT:2]]
onos>

We can see that the traffic flows between dpid 00:00:00:00:00:00:00:02 (Spine-2) and 00:00:00:00:00:00:00:0b (Leaf-1) and similarly between 00:00:00:00:00:00:00:02 (Spine-2) and 00:00:00:00:00:00:00:0e (Leaf-4).

Please note that the output from the tutorial and what you see may vary slightly as all alternate paths here have equal cost and therefore ONOS is free to pick either one.

You can visualize the intent using ONOS GUI by selecting the Leaf-1 node in the GUI and press the V key to show paths provisioned by intents that pass through the selected node. You should see something like this:

Image Added

Let's see what happens if we sever the link between Spine-2 (s2) and Leaf-1 (s11), you may have to teardown the link between s1 and s11 so pay attention to the flows command output. This can be done in mininet by running:

Code Block
mininet> link s2 s11 down

After this, the GUI will show the link disappear. Selecting Leaf-1 and pressing V key again will show the newly established path which leads through the other spine switch:

Image Added

Similarly, running the flows -s command again will show flows have moved to pass through the other spine.

How did this happen? Well when we tore down the link between s2 and s11, ONOS detected this change and informed all compo listening to topology events that the link went down. The intent service is one such component and when it receives this information it makes sure to repair any of the intents is affected by this change by provisioning connectivity using an alternate 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:

Code Block
mininet> link s2 s11 up

Have fun!

ONOS Graphical User Interface

You have already briefly seen the ONOS GUI in action. So far it was used to help you visualize the network, but the GUI also allows many more ways to visualize information about the network and its elements, in addition to provisioning several types of connectivity intents.

To open the UI simply click on the ONOS GUI icon on the desktop. Let's go over some of the GUI features.

GUI Features

GUI Cheat Sheet

At anytime you can pull up the GUI's cheat sheet by pressing the Slash key (which is ? without the pesky shift (wink)) and you will get an overlay pane that looks like below. You can dismiss this by pressing the Esc key. Each view, not just the topology view, provides a similar Quick Help overlay.

Image Added

Overview pane

The Topology View of the GUI comes with a very useful overview pane. It shows you a summary about the network such as version of ONOS, number of devices, links, hosts, etc. You can toggle on/off the overview pane using the O key.

Image Added

Details pane

When you Left-Click on an element of the topology, such as a switch, host or a link, another pane appears on the right hand side below the Overview pane. This pane gives additional details about the selected item(s). Its display can be toggled on/off using the D key.

Image Added

Note that the action buttons at the bottom of the Details pane can be used to jump to different views of the ONOS GUI for additional context. So select multiple items, hold the Shift key while you Left-Click. To unselect an item hold Shift and Left-Click it to toggle off the selection. You can also Left-Click anywhere on the blank part of the Topology View to unselect all items.

Instances pane

The GUI has the ability to show which ONOS instances are active. By hitting the 'i' key (it will be open by default) you will see a pane show up on the left hand side as shown below.

Image Added

Notice that the glyphs for the switches changes color, this indicates which switches are controlled by which instance. This is useful to see at a glance which switches are controlled by which ONOS instance. The terminal glyph indicates which instance the GUI is presently connected to and the check-mark glyph indicates that the instance is in ready state, which means fully operating as part of the cluster.

Install Intent

Ok let's install an intent using the UI. First select two hosts by clicking on one host then shift-click on another. Let's pick 10.0.0.20 and 10.0.0.9. Now a pane will appear on the right and side of the screen as here:

Image Added

Now click on 'Create Host-to-host Flow', this actually provisions a host to host intent and lights up the path used by the intent. 

Image Added

You can check that the intent was installed via the ONOS cli

Code Block
languagetext
onos> intents 
	id=0x223838ca, state=INSTALLED, type=HostToHostIntent, appId=org.onlab.onos.gui
	[LinkTypeConstraint{inclusive=false, types=[OPTICAL]}]

Now let's send some traffic on that intent. This will animate the link to show traffic and display how much traffic (counter value) is flowing through that link

Code Block
mininet> h42 ping h23

Show all traffic

Another thing you can do is to visually monitor the network traffic in the UI. You can cycle between different modes, e.g. port stats in bits/s or packets/s and flow stats in bits/s or packets/s, by pressing the A key.

Play on

Now you know the main features of the UI. We encourage you to play around with it to find out what other features you can use and who knows may find a few bugs.

Exploring Further

Here we just scratched the surface of what ONOS can do in terms of controlling a network. We highly encourage you to continue using ONOS and perhaps start developing your own applications. Find out how to get started in this tutorial.


...

Return To : Tutorials and Walkthroughs

...



mininet> h11 ping -c3 h41
PING 10.0.0.16 (10.0.0.16) 56(84) bytes of data.

--- 10.0.0.16 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2010ms

mininet>

onos> apps -a -s
* 36 org.onosproject.optical-model 1.12.0 Optical Network Model
* 40 org.onosproject.openflow-base 1.12.0 OpenFlow Base Provider
* 41 org.onosproject.lldpprovider 1.12.0 LLDP Link Provider
* 44 org.onosproject.hostprovider 1.12.0 Host Location Provider
* 47 org.onosproject.drivers 1.12.0 Default Drivers
* 104 org.onosproject.openflow 1.12.0 OpenFlow Provider Suite
* 288 org.onosproject.proxyarp 1.12.0 Proxy ARP/NDP
onos>

mininet> h11 ping h41
PING 10.0.0.16 (10.0.0.16) 56(84) bytes of data.
64 bytes from 10.0.0.16: icmp_seq=1 ttl=64 time=39.6 ms
64 bytes from 10.0.0.16: icmp_seq=2 ttl=64 time=0.263 ms
64 bytes from 10.0.0.16: icmp_seq=3 ttl=64 time=0.058 ms
64 bytes from 10.0.0.16: icmp_seq=4 ttl=64 time=0.061 ms
64 bytes from 10.0.0.16: icmp_seq=5 ttl=64 time=0.065 ms
^C
--- 10.0.0.16 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4002ms
rtt min/avg/max/mdev = 0.058/8.011/39.612/15.800 ms
mininet>

onos> devices
id=of:0000000000000001, available=true, local-status=connected 41m31s ago, role=STANDBY, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitch, sw=2.5.2, serial=None, driver=ovs, channelId=172.17.0.1:38710, locType=geo, managementAddress=172.17.0.1, name=Spine-1, protocol=OF_13
id=of:0000000000000002, available=true, local-status=connected 41m31s ago, role=STANDBY, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitch, sw=2.5.2, serial=None, driver=ovs, channelId=172.17.0.1:38728, locType=geo, managementAddress=172.17.0.1, name=Spine-2, protocol=OF_13
id=of:000000000000000b, available=true, local-status=connected 41m31s ago, role=STANDBY, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitch, sw=2.5.2, serial=None, driver=ovs, channelId=172.17.0.1:38702, locType=geo, managementAddress=172.17.0.1, name=Leaf-1, protocol=OF_13
id=of:000000000000000c, available=true, local-status=connected 41m31s ago, role=MASTER, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitch, sw=2.5.2, serial=None, driver=ovs, channelId=172.17.0.1:38730, locType=geo, managementAddress=172.17.0.1, name=Leaf-2, protocol=OF_13
id=of:000000000000000d, available=true, local-status=connected 41m31s ago, role=MASTER, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitch, sw=2.5.2, serial=None, driver=ovs, channelId=172.17.0.1:38720, locType=geo, managementAddress=172.17.0.1, name=Leaf-3, protocol=OF_13
id=of:000000000000000e, available=true, local-status=connected 41m31s ago, role=STANDBY, type=SWITCH, mfr=Nicira, Inc., hw=Open vSwitch, sw=2.5.2, serial=None, driver=ovs, channelId=172.17.0.1:38716, locType=geo, managementAddress=172.17.0.1, name=Leaf-4, protocol=OF_13
onos>

mininet> h11 ping -c3 h41
PING 10.0.0.16 (10.0.0.16) 56(84) bytes of data.
--- 10.0.0.16 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2010ms
mininet>

onos> apps -a -s
* 36 org.onosproject.optical-model 1.12.0 Optical Network Model
* 40 org.onosproject.openflow-base 1.12.0 OpenFlow Base Provider
* 41 org.onosproject.lldpprovider 1.12.0 LLDP Link Provider
* 44 org.onosproject.hostprovider 1.12.0 Host Location Provider
* 47 org.onosproject.drivers 1.12.0 Default Drivers
* 104 org.onosproject.openflow 1.12.0 OpenFlow Provider Suite
* 288 org.onosproject.proxyarp 1.12.0 Proxy ARP/NDP
onos>

mininet> h11 ping h41
PING 10.0.0.16 (10.0.0.16) 56(84) bytes of data.
64 bytes from 10.0.0.16: icmp_seq=1 ttl=64 time=39.6 ms
64 bytes from 10.0.0.16: icmp_seq=2 ttl=64 time=0.263 ms
64 bytes from 10.0.0.16: icmp_seq=3 ttl=64 time=0.058 ms
64 bytes from 10.0.0.16: icmp_seq=4 ttl=64 time=0.061 ms
64 bytes from 10.0.0.16: icmp_seq=5 ttl=64 time=0.065 ms
^C
--- 10.0.0.16 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4002ms
rtt min/avg/max/mdev = 0.058/8.011/39.612/15.800 ms
mininet>