fp7-netide / Usecases

Contains the implementations of the use cases and target scenarios generated in the project
Eclipse Public License 1.0
7 stars 0 forks source link

Testing UC2 with Ryu/Core/Ryu #1

Closed ElisaRojas closed 8 years ago

ElisaRojas commented 8 years ago

Hi,

I'm writing this issue on behalf of @Juanma-Sanchez , who wrote the email to @doriguzzi in the first place. He was testing UC2 in the Ryu/Core/Ryu combination (as the UC2 is now implemented in Ryu) and he's having the following problem:

UC2 uses LLDP to obtain the topology and then use it for optimal routing. However, when he uses NetIDE, he's found out that the topology module (called "switches" in Ryu) is not receiving the proper information. LLDP messages go down to the network and then up to the backend (we checked that with Wireshark), but the problem is that they are not being forwarded to the switches modules, but only to the UC2 module (called IITS_NetManager in the screenshot below). Moreover, he found out that the switches modules is recognized by the core as another module (see below).

netide-module-list

Juanma's has been checking through the ModuleIDs of a Wireshark capture (we can send it if you need it), and he could only find the ID 719 that represents our aplication (UC2).

It seems that the problem is that the switches module isn't receiving any LLDP although it is recognized by the core.

He later on tried to add the switches module to the composition file, but it was unsuccessful. I don't recall now the problem, @Juanma-Sanchez , could you remind us?

We are assigning @doriguzzi to the issue, as the author of the Ryu backend, but if Arne could check the issue as well, as he know about the behaviour of the core (and maybe explain if we could add a composition file for it), it would be great.

Any help would be really appreaciated! Best,

P.S: We might stop using LLDP (and hardcode the topology) if it has no solution, but ideally, this being solved would be nice.

Juanma-Sanchez commented 8 years ago

Hi,

Sorry for the delay. This is the error I get when I try to add the switches module to the composition file as if it was another application: image

As Elisa said, any help would be appreaciated. Thanks.

doriguzzi commented 8 years ago

Could you please post the command you use to run the ryu backend so that I can reproduce the error?

Thanks

Juanma-Sanchez commented 8 years ago

Yes, it's: ryu-manager --ofp-tcp-listen-port 7733 --observe-links ~/NetIDE/Engine-mixed/ryu-backend/ryu-backend.py IITS_NetManager.py

The IITS_NetManager.py file is in Usecases/Usecase2/ryu/Application/ Thanks

doriguzzi commented 8 years ago

Hi Elisa, Juan,

please find in the ryu-backend-lldp branch a prototype of the ryu-backend that sends the lldp messages to all the modules running atop. I tested it and it should work. However, do not hesitate to contact me in case of errors/problems.

--rob

Juanma-Sanchez commented 8 years ago

Hello @doriguzzi, With the new backend the switches module is receiving (at least some of) the lldps, but the routing table doesn't seem to update correctly: image Any idea why could this be?

If it may be helpful, I used a new vagrant machine (in which i disabled Ipv6 in the grub and installed python-ipaddr), with the attached composition specification and called the backend with th command: _ryu-manager --ofp-tcp-listen-port 7733 --observe-links ~/NetIDE/Engine-mixed/ryu-backend-lldp/ryu-backend.py IITSNetManager.py

Thanks in advance.

CompositionSpecification.zip

doriguzzi commented 8 years ago

What does it happen with the "official" backend (i.e. the one without the patch for LLDP messages)?. Do you have the same percentage of dropped packets?

doriguzzi commented 8 years ago

If I try to reproduce the same environment using the mininet script provided in the Usecase2/ryu/Topology folder, I get an error because IPCONFIG.dat does not exist.

ElisaRojas commented 8 years ago

Thank you @doriguzzi , AFAIK with the "official" backend all pings are dropped (because no learning is done at all via LLDP). With this new backend some learning is done (and that is why some pings work), but apparently not all... @Juanma-Sanchez tried to print the different LLDP arriving, but could not see the reason.

As for the .dat, I think it has been ignored when uploading due to .gitignore. Let's see if @Juanma-Sanchez can upload it on Monday (just delete the .dat in .gitignore and try to upload it again).

ElisaRojas commented 8 years ago

Hi again @doriguzzi , I've just uploaded the IPCONFIG.dat file. Apparently, the *.dat file was the one from the Pyretic project and @Juanma-Sanchez did not have it either, so he was executing the scenario ignoring that error. In any case, I've uploaded the file anyway.

Therefore, you can either execute it without the *dat or with it. @Juanma-Sanchez has been testing everything without it so far and ignoring the error, if you want to follow the same scenario.

doriguzzi commented 8 years ago

As a first step I'm running mininet with command "sudo python UC2_IITSystem.py" and the application with just Ryu, no Network Engine. However, pingall does not work at all and after a while I get the following error:

image

I'm using Ryu version 3.27.

Juanma-Sanchez commented 8 years ago

The only thing that comes to mind is that you may be missing the "--observe-links" option when running the application (it's necessary for the ryu topology api). That wouldn't explain the error, but I don't have any other plausible explanation.

ElisaRojas commented 8 years ago

Hi @doriguzzi , please let us know if you tried with the "--observe-links" as well. If you still have errors, maybe we can organize a quick telco to debug the issue together :) Thanks for your help!

doriguzzi commented 8 years ago

When I run the IITS_NetManager.py application on top of the Engine, the ryu-backend detects two applications: IITS_NetManager.py and switches.py (which, I guess, is activated by "--observe-links" ). I see both of them receiving the same LLDP packets that are also received by the backend. Could you please tell me how you detect the anomaly?

Juanma-Sanchez commented 8 years ago

Hello @doriguzzi , there has been a problem. I detected the anomaly indirectly using the routing table that gets printed when the application starts (the entries that were set all to ones meant the switches module didn't receive the lldp messages).

I was going to include screenshots, but I have updated the java core to its latest version and now the ryu-backend-lldp doesn't complete the handshake (the regular one does), although the core seems to be receiving the backend messages. Do you know what could have happened?

Juanma-Sanchez commented 8 years ago

Hello,

The application is working properly with the python core, but when I use the java core the lldp messages don't reach neither the application or the switches module.

schwabe commented 8 years ago

Can you provide a log of the core?

Juanma-Sanchez commented 8 years ago

There is the following recurring error: image

karaf-log.zip

schwabe commented 8 years ago

Compsition empty for packet means exactly that. The core has no backend to forward that packet to so it is dropping it. How does your composition file look like?

Juanma-Sanchez commented 8 years ago

It looks like this:

image

I'm also using the ryu-backend from the ryu-backend-lldp branch, not the master one.

schwabe commented 8 years ago

Should that composition xml be in the https://github.com/fp7-netide/Usecases/tree/master/Usecase2 folder?

That compsition.xml looks not even valid. I would be suprised if netide:loadcomposition accepts that composition file.

schwabe commented 8 years ago

next time you might want to put your code inside ``` instead of posting an image.

Your Composition is indeed empty. There is no <Composition> in your xml at all. See the example specification files in the core.

Juanma-Sanchez commented 8 years ago

Ok, now it's working, thank you very much. I have added the new composition specification to the repository.

schwabe commented 8 years ago

I am closing this now then.

ElisaRojas commented 8 years ago

Hi, one final question to @doriguzzi . Should we merge the new backend into the master branch? Thanks everybody for your help! :)