...
Build ONOS master
Code Block language bash $ cd ~/onos $ git pull origin master $ buckbazel build onos
Run ONOS
Code Block language bash $ export ONOS_APPS=drivers.bmv2,proxyarp,lldpprovider,hostprovider,fwd $ buckbazel run onos-local -- clean
The variable
ONOS_APPS
indicates which ONOS applications to execute at ONOS boot. The list includes the BMv2 drivers (based on P4Runtime), the Proxy ARP application, the LLDP Link Provider, the Host Location Provider, and the Reactive Forwarding application. These applications combined together provide ONOS with capabilities to discover the topology (via injection of LLDP packets), the hosts (by intercepting and handling ARP requests) and to provide basic point-to-point connectivity.On a second terminal shell, access the ONOS command line:
Code Block language bash $ onos localhost
Check that all applications have been loaded successfully. On the ONOS command line, type:
Code Block language bash onos> apps -s -a
You should see an output similar to this (depending on your startup apps defined in $ONOS_APPS)
* 10 org.onosproject.drivers 1.13.0.SNAPSHOT Default Drivers
* 35 org.onosproject.generaldeviceprovider 1.13.0.SNAPSHOT General Device Provider
* 36 org.onosproject.protocols.grpc 1.13.0.SNAPSHOT gRPC Protocol Subsystem
* 37 org.onosproject.protocols.p4runtime 1.13.0.SNAPSHOT P4Runtime Protocol Subsystem
* 38 org.onosproject.p4runtime 1.13.0.SNAPSHOT P4Runtime Provider
* 39 org.onosproject.drivers.p4runtime 1.13.0.SNAPSHOT P4Runtime Drivers
* 42 org.onosproject.proxyarp 1.13.0.SNAPSHOT Proxy ARP/NDP
* 44 org.onosproject.hostprovider 1.13.0.SNAPSHOT Host Location Provider
* 45 org.onosproject.lldpprovider 1.13.0.SNAPSHOT LLDP Link Provider
* 73 org.onosproject.pipelines.basic 1.13.0.SNAPSHOT Basic Pipelines
* 119 org.onosproject.drivers.bmv2 1.13.0.SNAPSHOT BMv2 Drivers
* 146 org.onosproject.fwd 1.13.0.SNAPSHOT Reactive Forwarding
Start Mininet. On third VM terminal shell, type:
Code Block language bash $ sudo -E mn --custom $BMV2_MN_PY --switch onosbmv2 --controller remote
This will run a simple Mininet topology with 2 hosts connected to a BMv2 switch, to use a different topology please refer to the Mininet guide. The
-E
argument in sudo ensures that all environment variables are exported to the root user. $BMV2_MN_PY is used to point to the location of the Mininet custom file bmv2.py provided in ONOS. If successful, the output of the previous command should be similar to this:*** Creating network
*** Adding controller
*** Adding hosts:
h1 h2
*** Adding switches:
s1
*** Adding links:
(h1, s1) (h2, s1)
*** Configuring hosts
h1 h2
*** Starting controller
c0
*** Starting 1 switches
s1
Starting BMv2 target: simple_switch_grpc --device-id 0 -i 1@s1-eth1 -i 2@s1-eth2 --log-console -Lwarn --thrift-port 38148 --no-p4 -- --cpu-port 255 --grpc-server-addr 0.0.0.0:37346
[1] 2370*** Starting CLI:
mininet>Info title bmv2.py custom Mininet script When using the bmv2.py custom Mininet script, files related to the execution of the BMv2 switch are stored under
/
tmp. The name of these files depends on the switch name used in Mininet, e.g. s1, s2, etc. Example of these files are:bmv2-s1-
grpc-port
: contains the port used by the P4Runtime server executed by the BMv2 simple_switch_grpc instance named 's1'bmv2-s1-log
: contains the BMv2 logbmv2-s1-
netcfg.json
: netcfg blob pushed to ONOS to discover the switchInfo title bm-* commands The VM comes with a number command aliases to aid in the debugging of BMv2 when executed as part of Mininet. These commands all take one parameter, the switch name used in Mininet, e.g. s1, s2, etc.
Command Description bm-log
Shows a live scrolling view of the given BMv2 switch instance log bm-cli
Access the BMv2 CLI, useful to dump table entries, etc.
WARNING: this CLI uses the BMv2 Thrift-based APIs which capabilities overlap with P4Runtime (e.g. a table management is provided by both). For this reason, there could be inconsistency issues when using both APIs to write state to the switch. For example, if one tries to insert a table entry using Thrift, the same cannot be read using P4Runtime. In general, to avoid such issues, we suggest using this CLI only to read state, or to write state that is not managed by P4Runtime.bm-dbg
Starts the BMv2 debugger bm-nmsg
Start the BMv2 nanomsg event logger client Check that the BMv2 switch has successfully connected to ONOS. On the ONOS command line, check the output of the following command.
onos> devices
id=device:bmv2:1, available=false, local-status=connected 9m33s ago, role=NONE, type=SWITCH, mfr=p4.org, hw=master, sw=master, serial=unknown, driver=bmv2:org.onosproject.pipelines.basic, locType=geo, name=device:bmv2:1, protocol=[p4runtime]
From the output, we can see that the BMv2 switch is connected (
available=true
), along with information on the P4 program (pipeconf) deployed (driver=bmv2:org.onosproject.pipelines.basic
) and on the protocol used to control the switch (protocol=[p4runtime]
).Check that the 2 hosts can ping each other. On the Mininet command line, use the
pingall
command check the output:Code Block language text mininet> pingall *** Ping: testing ping reachability h1 -> h2 h2 -> h1 *** Results: 0% dropped (2/2 received)
...