ONOS Can't Find the P4Switch

Hi friends,
We have completed the ngsdn-tutorial, but we don’t want to rely on the overall framework and script provided by it. We intend to conduct the connection experiment in the original way.However, we encountered difficulties and found that onos could not link P4 switches all the time.

Our experiment is like this,
First, start onos through docker, using the following command:

docker run -t -d -p 8181:8181 -p 8101:8101 -p 5005:5005 -p 830:830 -p 6653:6653 --name onos8 onosproject/onos:2.2.2

We found that onos started normally:

And We have also launched many applications of ONOS:

However,when we used this command to start mininet

sudo -E mn --custom bmv2.py --switch onosbmv2  --controller remote,ip=127.17.0.2

the bmv2.py file as follows:

And the BMV2.EXE and the BMV2.JSON are as flows:
image

Finally, we start by command:

sudo -E mn --custom bmv2.py --switch onosbmv2  --controller remote,ip=127.17.0.2

But ONOS can’t find any devices!

We are now eager to solve this problem. If friends can put forward suggestions, we will be very grateful!

Thanks,

Hi,

I try to not to deviate from the NG-SDN tutorial (in terms of deploying an scenario) because all complicated things are already programmed. Check the Makefile from the tutorial and, also check EXERCISE 4.

They state in EXERCISE 4:

6. Push netcfg to ONOS to trigger device and link discovery

On a terminal window, type:

$ make netcfg

And if you check the actual Makefile:

_netcfg:
	$(info *** Pushing ${NGSDN_NETCFG_JSON} to ONOS...)
	${onos_curl} -X POST -H 'Content-Type:application/json' \
		${onos_url}/v1/network/configuration -d@./mininet/${NGSDN_NETCFG_JSON}
	@echo

netcfg: NGSDN_NETCFG_JSON := netcfg.json
netcfg: _netcfg

As you see, they reference a file netcfg.json and push it to ONOS. That file includes device information, port information and hosts information. The connfiguration data for the devices includes the IP and port that ONOS needs to know so that the P4Runtime session is established. That is probably why the controller cannot find the switch, see the managementAddress key in the netcfg.json file. Copnsider that your own programs pipeconf, if you use Stratum and so on also matter, and that is specified in the configuration file as well as the drivers you activate in ONOS. That is why keeping as much as you can from the tutorial is helpful (at least in the beginning).

{
  "devices": {
    "device:leaf1": {
      "basic": {
        "managementAddress": "grpc://mininet:50001?device_id=1",
        "driver": "stratum-bmv2",
        "pipeconf": "org.onosproject.ngsdn-tutorial",
        "locType": "grid",
        "gridX": 200,
        "gridY": 600
      },
      "fabricDeviceConfig": {
        "myStationMac": "00:aa:00:00:00:01",
        "mySid": "3:101:2::",
        "isSpine": false
      }
    },
    ...
  },
  "ports": {
    "device:leaf1/3": {
      "interfaces": [
        {
          "name": "leaf1-3",
          "ips": ["2001:1:1::ff/64"]
        }
      ]
    },
  ...
  },
  "hosts": {
    "00:00:00:00:00:1A/None": {
      "basic": {
        "name": "h1a",
        "locType": "grid",
        "gridX": 100,
        "gridY": 700
      }
    },
    ...
  }
}

If you want a good recommendation, go step by step. Keep as much as you can from the tutorial (maybe not the control plane app, because you need your own). But still use mininet, the Makefile and so on. If you need to switch from Mininet to your own simple_switch process do it but only once Mininet worked. Try to only make changes but step by step.

Cheers,

Dear ederollora

Thank you,

We still have some questions are as follows:

  • Our work is based on the IPv4 protocol, but exercise involves the IPv6 protocol. If we change it, what should we pay attention to?
  • What is the relationship between ONOS and P4Runtime ?
  • Since we want to customize our own topology, are there other ways for ONOS to discover P4 switches besides submitting netcfg.json? If not, is there a netcfg.json file? Is there any example format?

More thanks,

Boyu

Well, if you use IPv6, then you obviously need to have a P4 with that header (to begin with). NG-SDN tutorial, indeed, uses the Ipv6 header in one or more exercises. If you check EXERCISE 3, you will notice that Flow rules and groups section shows the IPv6 header selector for the ACL table when flows are displayed. This tell you that when rules are installed for the ACL table, the controller must have done it in a way that you should be able to check. Apart from that, the file Ipv6RoutingComponent.java has a pretty clear example. I do not think you have to pay attention to anything more than what the example shows. Also, check how the program calls the aforementioned function, like this line

Let me give a very simplified answer. As you know, ONOS is a controller. Just like OpenDaylight or Ryu. Or even like any control plane of any networking device, with the difference that ONOS operates logically centralized and physically distributed. Of course, not all control planes “look” the same and do not operate in the same way. Still, most if not all control planes have to communicate with the data plane in one way or another. In order to communicate with the data plane agent, you need to speak the same “language” (i.e., protocol). The “language” is P4Runtime (based on Protobuf and gRPC). Before the P4 and P4Runtime, other “languages” were available, like the OpenFlow protocol.

There might be other ways to discover the switch (or force the switches to connect to the controller), but I am not sure right now. However, using the netcfg.json file seems pretty straightforward, and you can automate it, so I recommend you to use it. In the NG-SDN tutorial that you did, you have several examples. See here.

Cheers,

Thank you,

Your answer helped us clarify many questions.

Boyu.