How can I apply configuration changes to Mininet devices?

[vggonzalez]

Hi

I am working on a project for my university where I basically have to create a Mininet network and manage it through the NETCONF protocol. I have chosen to run the yuma server (netconfd) in the nodes and I have not yet decided whether I will use OpenDayLight or ONOS as the controller.

My question is as follows:

After editting the running configuration and committing it... Does it really change the device configuration? i.e. let's say I configure a new route. Would this route be added to the device or is there any other action required after committing?

I ask this since I've read about SIL functions in the documentation and I'm not sure whether the commit operation is enough or if there is needed any other further action in order to truly affect the device's configuration.

Regards, Victor.

[vlvassilev]

Yes upon 'commit' the southbound interface (e.g. OpenFlow most likely in your case, or NETCONF if you have devices implementing ietf-network-bridge YANG model) communication will do the work of configuring the nodes with whatever configuration you had in your 'candidate' data store as well as moving it to the 'running'.

I have used the Beryllium OpenDaylight (here some installation instructions known to work on Debian stretch https://github.com/vlvassilev/ecoc-demo-2018/blob/master/test-odl-install )

Here is how you can connect with yangcli to OpenDaylight and create/monitor flows:

user@debianhost:/home/user$ /usr/bin/yangcli --server=localhost --ncport=2830 --user=admin --password=admin
...
yangcli admin@localhost> sget /nodes/node[id='openflow:466845164403712']
...
yangcli admin@localhost>  merge /nodes/node[id='openflow:466845164403712']/table[id='0']/flow[id='1'] -- match/in-port=openflow:466845164403712:19 match/ethernet-match/ethernet-type/type=35063 instructions/instruction[order='0']/apply-actions/action[order='0']/output-action/output-node-connector=18 out_port=18 flow-name=my-ptp-flow
yangcli admin@localhost> commit
...

[vlvassilev]

I do not think you will need netconfd since you do not intend to use a NETCONF interface as OpenDaylight southbound interface (the case with the ietf-network-bridge YANG model). If you use mininet (OpenFlow as southbound interface) you only need a NETCONF client application to connect to the OpenDaylight NETCONF interface. You could use yangcli to test and tabcomplete your command lines and then take the corresponding NETCONF XML PDUs and use them in a python script. Use the following options to directly get the NETCONF PDUs (--echo-requests=true --display-mode=xml --echo-replies=true).

[vggonzalez]

Thank you very much, although I have one more question:

The way I see it I will need a NETCONF server running on each mininet node I want to manage, right? So I understand I will have to run a netconfd instance on each node for them to speak the protocol properly

[vlvassilev]

Well OpenDaylight is running a NETCONF server (along with RESTCONF) for a network (not node) based YANG model. mininet nodes are managed over OpenFlow (not NETCONF). Your OpenDaylight will listen on port 6633 for incoming OpenFlow connections and add to the openflow network all connecting nodes.

# mn --topo linear,3 --mac --controller=remote,ip=127.0.0.1,port=6633 --switch ovs,protocols=OpenFlow10

I am not sure your project assignment has a requirement to use NETCONF as southbound interface to the nodes since mininet has OpenFlow implementation that is the default and supported southbound interface for flow enabled nodes network model in OpenDaylight. I think the intention was to use NETCONF as northbound interface and manage the OpenDaylight controller (the yangcli command lines do exactly that).

That said if you have an implementation of nodes with NETCONF interface instead of OpenFlow you have 2 options:

1. Directly accessing the node model datastores mounted as NETCONF devices in OpenDaylight - see https://github.com/vlvassilev/ecoc-demo-2018/blob/master/odl-clear-traffic-generators/session.testapi.py for example deleting a container using the RESTCONF interface. This is translated to edit-config + commit on the NETCONF southbound interface.

2. Develop/enhance the existing network based YANG model implementation in OpenDaylight for flow enabled nodes so they can be used transparently in a hybrid network with the openflow nodes (https://lists.opendaylight.org/pipermail/opendaylight-users/2018-June/000844.html). This is something that requires a model (e.g. ietf-network-bridge), device implementation (e.g. SIL for netconfd or confd etc.), and OpenDaylight integrating the NETCONF southbound node model. All this is possible but I do not think anyone has demonstrated such a hybrid network yet.

[vggonzalez]

Thank you very much for taking your time to answer.

The basic idea of the Project is to create virtual network scenarios (over mininet if possible since that would make it easier) that I can manage through a remote controller and NETCONF protocol. It's still unclear to me every detail and every step I'll have to follow since I'm still on the investigation phase, however the main purpose would be being able to editing the nodes's interfaces and adding new routes to the nodes.

[KrisLloyd]

@vggonzalez

I found your original post from Google, and I'm interested in running a similar configuration. Do you have your project details anywhere?

[vggonzalez]

Hi there. Attached on this message you will find what I did (it's not completed as I can't find it 😢). The way I see it you'll probably be interested in section 6: "Prueba de concepto", more specifically in 6.1: "Experimento con OpenVSwitches". In this section i deployed a simple network of OpenVSwitches in Mininet and managed it through NETCONF. However, the configuration changes made through NETCONF were VERY simple, limiting it to turning on and off the different interfaces, as the main part of my paper was the section 6.2 (you might find it interesting, it consists on the development of a Java application in order to keep track of different statistics of a network consisting on VirtualBox instances and managed through ONOS and NETCONF).

Everything is in spanish, but I don't think Google Translate will give you much trouble to understand it. In case you end up using some of my work, I would appreciate some quotation. Anyways, I wish you the best of luck with your project. Let me know if it was any useful! Regards, Víctor.

El jue., 20 feb. 2020 a las 17:55, Kris Lloyd (notifications@github.com) escribió:

@vggonzalez https://github.com/vggonzalez

I found your original post from Google, and I'm interested in running a similar configuration. Do you have your project details anywhere?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/vlvassilev/yuma123/issues/52?email_source=notifications&email_token=AIWC43FUWUXFUSSZIFQYSMLRD2YWVA5CNFSM4GWYCPPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMPDG2A#issuecomment-589181800, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIWC43FA67LQJEDTIRYNBLLRD2YWVANCNFSM4GWYCPPA .

[vggonzalez]

Forgot to attach it haha

El jue., 20 feb. 2020 a las 19:44, Víctor García González (< v.garcia.gonzalez97@gmail.com>) escribió:

Hi there. Attached on this message you will find what I did (it's not completed as I can't find it 😢). The way I see it you'll probably be interested in section 6: "Prueba de concepto", more specifically in 6.1: "Experimento con OpenVSwitches". In this section i deployed a simple network of OpenVSwitches in Mininet and managed it through NETCONF. However, the configuration changes made through NETCONF were VERY simple, limiting it to turning on and off the different interfaces, as the main part of my paper was the section 6.2 (you might find it interesting, it consists on the development of a Java application in order to keep track of different statistics of a network consisting on VirtualBox instances and managed through ONOS and NETCONF).

Everything is in spanish, but I don't think Google Translate will give you much trouble to understand it. In case you end up using some of my work, I would appreciate some quotation. Anyways, I wish you the best of luck with your project. Let me know if it was any useful! Regards, Víctor.

El jue., 20 feb. 2020 a las 17:55, Kris Lloyd (notifications@github.com) escribió:

@vggonzalez https://github.com/vggonzalez

I found your original post from Google, and I'm interested in running a similar configuration. Do you have your project details anywhere?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/vlvassilev/yuma123/issues/52?email_source=notifications&email_token=AIWC43FUWUXFUSSZIFQYSMLRD2YWVA5CNFSM4GWYCPPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMPDG2A#issuecomment-589181800, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIWC43FA67LQJEDTIRYNBLLRD2YWVANCNFSM4GWYCPPA .

[vggonzalez]

I didn't realise this was a Github project and not a private email thread. If you are still interested, please contact me in this email: vic70garcia@gmail.com

El jue., 20 feb. 2020 a las 19:44, Víctor García González (< v.garcia.gonzalez97@gmail.com>) escribió:

Forgot to attach it haha

El jue., 20 feb. 2020 a las 19:44, Víctor García González (< v.garcia.gonzalez97@gmail.com>) escribió:

Hi there. Attached on this message you will find what I did (it's not completed as I can't find it 😢). The way I see it you'll probably be interested in section 6: "Prueba de concepto", more specifically in 6.1: "Experimento con OpenVSwitches". In this section i deployed a simple network of OpenVSwitches in Mininet and managed it through NETCONF. However, the configuration changes made through NETCONF were VERY simple, limiting it to turning on and off the different interfaces, as the main part of my paper was the section 6.2 (you might find it interesting, it consists on the development of a Java application in order to keep track of different statistics of a network consisting on VirtualBox instances and managed through ONOS and NETCONF).

Everything is in spanish, but I don't think Google Translate will give you much trouble to understand it. In case you end up using some of my work, I would appreciate some quotation. Anyways, I wish you the best of luck with your project. Let me know if it was any useful! Regards, Víctor.

El jue., 20 feb. 2020 a las 17:55, Kris Lloyd (notifications@github.com) escribió:

@vggonzalez https://github.com/vggonzalez

I found your original post from Google, and I'm interested in running a similar configuration. Do you have your project details anywhere?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/vlvassilev/yuma123/issues/52?email_source=notifications&email_token=AIWC43FUWUXFUSSZIFQYSMLRD2YWVA5CNFSM4GWYCPPKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMPDG2A#issuecomment-589181800, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIWC43FA67LQJEDTIRYNBLLRD2YWVANCNFSM4GWYCPPA .

[vlvassilev]

@KrisLloyd check also https://github.com/vlvassilev/yuma123/tree/master/netconf/test/netconfd/mininet

This is automated mininet network (NETCONF/YANG nodes) testcase based on the ietf-intefaces + ietf-network-bridge SILs part of yuma123.