steps to use it

[stevebobaaa]

Hello, I am very interested in this project and would like to further investigate it. Could you please tell me the steps to use it

[Jiarre]

Hello,

The general usage of this repo consists of starting the controllers in different hosts using Ryu (you can use the scripts c1.sh, c2.sh, and c3.sh), and then starting the mininet topology (network.py). The other files present on the repo are mostly related to the testing I was performing. You can read more about the setup and parameters I used for testing on the paper that was published on this work:

F. Giarré, L. Cominardi and P. Casari, "Realizing Flat Multi-Zone Multi-Controller Software-Defined Networks using Zenoh," 2022 IEEE Conference on Network Function Virtualization and Software Defined Networks (NFV-SDN), Phoenix, AZ, USA, 2022, pp. 45-51, doi: 10.1109/NFV-SDN56302.2022.9974876.

Please note that has been a while since this was originally run, and I'm pretty sure that Zenoh's APIs were quite different at the time, I recommend having a look at their documentation in order to fix the problems or using the old version as reported in the paper.

Feel free to ask any other question if needed!

[stevebobaaa]

Thank you very much for your reply!! Do I need to run c1, c2, and c3 controllers on three different hosts? Why are the three controller IPs in network.py the same?

CONTROLLER1 = "192.168.86.15:6633" CONTROLLER2 = "192.168.86.15:6634" CONTROLLER3 = `"192.168.86.15:6635"

And Zenoh is already embedded in controllerz *. py, right? I don't need to start Zenoh additionally, do I?

[Jiarre]

You're right!

For development and testing purposes the controllers were started on the same hosts in different ports (as you pointed out), but in order to test distribution in a wider network you would want to initialize the controllers in different hosts. This may vary on the setup you want to test (you may be more interested on multiple controllers on a single host).

For what concerns Zenoh, you don't need to start the Zenoh-router daemon if you run everything on the same host, but the latter is required if you use multiple hosts because the different daemons will connect with each other.

You may check the Zenoh configuration that suits you more on this page: https://zenoh.io/docs/getting-started/deployment/

[stevebobaaa]

Ok, I'll try to run it and I'll ask you if I have any more questions.Thank you so much!

[stevebobaaa]

Hello, may I ask what version of Zenoh should I install? Is it Zenoh-Python? I tried to install using pip install eclipse-zenoh and ranryu-manager controllerz1.py --observe-links --ofp-tcp-listen-port 6633 &, but encountered an error: ImportError: cannot import name 'SubMode' from 'zenoh' (/home/jkc/.local/lib/python3.8/site-packages/zenoh/init.py)

[Jiarre]

Unfortunately I have no record of the version of Zenoh-Python used (apart from the fact that it was a nightly release and that the project is from early 2022).

Fortunately, the usage of Zenoh in those scripts is quite basic, hence you should be able to change the syntax to the latest one with ease.

I should also mention that Zenoh's team is pretty fast with replies, so for implementation-related question I recommend to refer to them.

[stevebobaaa]

OK, Thank you, I will try to change the syntax. So, it's okay to use install eclipse-zenoh to install zenoh, or do I need to install it from source code?

[Jiarre]

Exactly! The Python package should contain all you need to run the scripts locally (and in a LAN). In order to displace Zenoh in multiple networks you may need to install (by compiling from source or downloading the docker container for instance) Zenoh router.

[stevebobaaa]

Okay, I really appreciate your guidance. I will try it now.

[stevebobaaa]

I'm sorry to bother you again, but I don't know how to modify the code to adapt to the current version of Zenoh because there have been too many changes in Zenoh. TAT

[stevebobaaa]

OMG, I found that many APIs in the code are from Zenoh Net, but the (https://zenoh.io/docs/migration/migrationguide-python-v0.5.x-v0.6.x/) link says that Zenoh Net has been removed. What do you think should be done next?

[Jiarre]

Sorry to hear that. The Zenoh infrastructure of the project as you can read on the paper (and as you can read in the code) is quite limited (lines 219 to 232 in controllerz1.py) and simple:

• A couple of storages per Controller (as python dictionaries)
• Functions to query and get the results back (let alone various consistency and reliability settings that were there just for testing)
• Subscribe to keys to exchange knowledge

For what I recall, there was nothing more to these implementation than what is contained in the basic tutorials, so you should be able to change it even if starting from scratch following the new docs (https://zenoh-python.readthedocs.io/en/0.10.0-rc/).

Anyways, I would recommend you to contact the team on their discord channel for any clarification on functions and new features (or how to replace old ones) that may have been added, since they are usually quick and very helpful!

[stevebobaaa]

Hello, I have modified the section of the code regarding Zenoh configuration according to the documentation on the Zenoh official website (lines 219-232 in controller1, 226-239 in controller2, and 233-247 in controller3).

Now the controller can run, but only loading app controllerz1.py appears after running, and there is no other response.

Moreover, after running network.py, I found that the network is not ping properly using pingall. What is the reason? Thank you!

[stevebobaaa]

May I ask where else I need to try to modify?

[Jiarre]

Hi, sorry I made you wait.

For what concerns network.py:

• Did you change the controller addresses to localhost:<portnumber> and deployed the controller to the address accordingly?
• Did you start all 3 controllers?
• "is not pinging properly using pingall" does this mean that only some pings are working? In this case, check if the ones pinging are part of the same zone. In case only hosts of the same zone are pinging, then the controller is working, but Zenoh is not. On the other end if no ping is working there is an issue involving the controller or the connection switch-controller
• Check the switches configuration using the commands here https://randomsecurity.dev/posts/openvswitch-cheat-sheet/

For what concerns the controller scripts:

• Try and log received messages from the hosts and switches. To do this, just add a print on the functions switch_features_handler (to log when switches are connecting to the controller) and _packet_in_handler (to log when packets from hosts are received)
• Try and launch the ryu.app.simple_switch_13 with ryu and see if it loads (you can also try deploying a simple network) to check if Ryu's configuration is on point and functioning.
• Use the upper-cited cmd tools to check if switch have the correct flows installed

To sum up, 3 kinds of problems:

• Ryu <-> Mininet connection (not communicating correctly)
• Ryu process problem (not starting properly / crashing)
• Ryu <-> Ryu connection (Zenoh configuration problem)

As mentioned in previous comments there is nothing really complicated in the logic of these scripts, so playing around printing logs and using console tools should lead to the root of the problem pretty quickly.

[stevebobaaa]

Oh, It doesn't matter.

When I started three controllers and ran mininet, running the pingall command resulted in a 100% drop. I also have tried using mininet to create a simple linear topology, separately starting controllerz1 and connecting it with mininet, but the network is not working.

[stevebobaaa]

Is there any difference between the controller in reactive and the controller in hybrid? I was wondering if it might be this problem