No I didn't see the question. I'm assuming you are talking about this FlowManager: https://github.com/martimy/flowmanager. The two apps may conflict if they are using the same port (8080), otherwise try.
ryu-manager ~/flowmanager/flowmanager.py ryu.app.ofctl_rest BTW, you asked What is the origin of the Priority 65535 flow in scenario A ? This entry is created when the controller is run with the --observe-links option. $ ryu-manager --observe-links The controller adds an entry that forwards all LLDP packets to the controller with the highest possible priority. Remove the option and the entry will disappear. Sending LLDP packets to the controller helps the controller "understand" the topology but it is not mandatory. You can use it with the topology display applications. Regards, Maen On Sat, Feb 16, 2019 at 3:01 PM Diarmuid O Briain <diarm...@obriain.com> wrote: > Maen, > > I understand. Why I wonder is the version with the python3-ryu package as > it is? Is that the Ryu group or Ubuntu repository package management? > > BTW did you see the question I asked about Flow Manager not working with > the REST API. Is that normal or can the two be ran together ? > > Regards, > > Diarmuid > > Regards, > > Diarmuid > > On Sat 16 Feb 2019, 21:19 Maen Artimy <arti...@gmail.com wrote: > >> Here is at least one issue that may arise if you match based on >> destination MAC only: >> 1. Say Node A is connected to switch port 1. The controller creates a >> flow entry that forwards packets with destination MAC A to port 1. >> 2. If Node A is moved to switch port 2. The controller never learns about >> the change and all packets with destination MAC A match existing entry and >> go to port 1 (and never reach A). >> >> If the match is based on both source and destination MACs: >> 2. If Node A is moved to switch port 2, the packets from A will be sent >> to the controller because they don't match any entry and the controller >> will create a new entry withe proper output port (The old entry will remain >> though because there is not time-out assigned to it). >> >> I hope this helps. I may have been too brief. >> >> Regards, >> Maen >> >> >> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> >> Virus-free. >> www.avast.com >> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> >> <#m_3873663500120092052_m_3224595215056297631_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >> >> On Sat, Feb 16, 2019 at 1:57 PM Diarmuid O Briain <diarm...@obriain.com> >> wrote: >> >>> Maen, >>> >>> Interesting, I compared the *simple_switch13.py* file you linked me to >>> and the one that comes with the *python3-ryu* package (installed with >>> apt-get install python3-ryu). >>> >>> $ *diff /usr/lib/python3/dist-packages/ryu/app/simple_switch_13.py >>> maen_version_simple_switch_13.py* >>> 105c105 >>> < match = parser.OFPMatch(in_port=in_port, eth_dst=dst) >>> --- >>> > match = parser.OFPMatch(in_port=in_port, eth_dst=dst, >>> eth_src=src) >>> 120d119 >>> < >>> >>> That would seem to bear out what you say. I am a little lost as to what >>> that means though. Why the difference? >>> >>> regards, >>> >>> Diarmuid >>> -- >>> >>> *Irish by birth, located in Uganda but Munster by the grace of God.* >>> >>> >>> >>> >>> On Sat, 16 Feb 2019 at 19:04, Maen Artimy <arti...@gmail.com> wrote: >>> >>>> Diarmuid, >>>> There is something odd about the application you are running. The >>>> simple_switch_13.py should match three fields not two. Also it should not >>>> output the packet to the same input port (see line 105) . So I would start >>>> by checking if the application is correct. >>>> https://github.com/osrg/ryu/blob/master/ryu/app/simple_switch_13.py >>>> >>>> Regards, >>>> Maen >>>> >>>> On Sat, Feb 16, 2019 at 11:36 AM Diarmuid O Briain < >>>> diarm...@obriain.com> wrote: >>>> >>>>> Hi, >>>>> >>>>> I have spent ages playing with Ryu and mininet and decided to try some >>>>> actual physical switches. I compared using Ryu with an OvS switching for >>>>> physical ports in a server with Ryu controlling a Netgear M4300-48G in >>>>> OpenFlow v1.3 mode. The response in both cases were different and I >>>>> documented it in the attached. I would appreciate it if someone who knows >>>>> more about the Ryu controller than me would look and try explain the >>>>> different outcomes from scenarios on A and B. >>>>> >>>>> much appreciated. >>>>> >>>>> Diarmuid O'Briain >>>>> -- >>>>> >>>>> *Irish by birth, located in Uganda but Munster by the grace of God.* >>>>> >>>>> >>>>> _______________________________________________ >>>>> Ryu-devel mailing list >>>>> Ryu-devel@lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/ryu-devel >>>>> >>>> >> >> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> >> Virus-free. >> www.avast.com >> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail> >> <#m_3873663500120092052_m_3224595215056297631_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >> >
_______________________________________________ Ryu-devel mailing list Ryu-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ryu-devel
