Closed ElisaRojas closed 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:
As Elisa said, any help would be appreaciated. Thanks.
Could you please post the command you use to run the ryu backend so that I can reproduce the error?
Thanks
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
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
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: 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.
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?
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.
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).
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.
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:
I'm using Ryu version 3.27.
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.
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!
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?
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?
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.
Can you provide a log of the core?
There is the following recurring error:
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?
It looks like this:
I'm also using the ryu-backend from the ryu-backend-lldp branch, not the master one.
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.
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.
Ok, now it's working, thank you very much. I have added the new composition specification to the repository.
I am closing this now then.
Hi, one final question to @doriguzzi . Should we merge the new backend into the master branch? Thanks everybody for your help! :)
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).
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.