Hi, Thanks for your answer!
I use this version of OVS: mininet@mininet-vm:~$ sudo ovs-ofctl --version ovs-ofctl (Open vSwitch) 2.0.2 Compiled Aug 15 2014 14:31:02 OpenFlow versions 0x1:0x4 I simply took this VM image Mininet 2.2.0 on Ubuntu 14.04 and installed ryu using the install.sh -y command. It's weird because I installed exactly like I did before so I don't see why it's not working anymore... Best, Clément On 16 January 2015 at 06:59, Yusuke Iwase <[email protected]> wrote: > Hi, > > Well... > On my enviroment, the following commands (that you were mentioned) works fine. > > # Run mininet > --- > $ sudo mn --topo single,2 --mac --switch ovsk --controller remote > *** Creating network > *** Adding controller > Unable to contact the remote controller at 127.0.0.1:6633 > *** Adding hosts: > h1 h2 > *** Adding switches: > s1 > *** Adding links: > (h1, s1) (h2, s1) > *** Configuring hosts > h1 h2 > *** Starting controller > *** Starting 1 switches > s1 > *** Starting CLI: > mininet> > --- > > # Run ofctl_rest > --- > $ sudo ryu-manager ryu.app.ofctl_rest > loading app ryu.app.ofctl_rest > loading app ryu.controller.ofp_handler > instantiating app None of DPSet > creating context dpset > creating context wsgi > instantiating app ryu.app.ofctl_rest of RestStatsApi > instantiating app ryu.controller.ofp_handler of OFPHandler > (6712) wsgi starting up on http://0.0.0.0:8080/ > --- > > # Execute commands > --- > $ # Push a group entry > $ curl -X POST -d '{ >> "dpid": 1, >> "type": "FF", >> "group_id": 1, >> "buckets": [ >> { >> "watch_port": 1, >> "actions": [ >> { >> "type": "OUTPUT", >> "port": 1 >> } >> ] >> } >> ] >> }' http://localhost:8080/stats/groupentry/add > $ > $ # Check the group entry > $ curl -X GET http://localhost:8080/stats/groupdesc/1 > {"1": [{"buckets": [{"actions": ["OUTPUT:1"], "watch_group": 4294967295, > "weight": 0, "watch_port": 1}], "group_id": 1, "type": "FF"}]} > $ > $ # Push a flow entry > $ curl -X POST -d '{ >> "dpid": 1, >> "match":{ >> "vlan_vid": 5 >> }, >> "actions":[ >> { >> "type":"GROUP", >> "group_id": 1 >> } >> ] >> }' http://localhost:8080/stats/flowentry/add > $ > $ # Check the flow entry > $ curl -X GET http://localhost:8080/stats/flow/1 > {"1": [{"actions": ["GROUP:1"], "idle_timeout": 0, "cookie": 0, > "packet_count": 0, "hard_timeout": 0, "byte_count": 0, "length": 80, > "duration_nsec": 548000000, "priority": 0, "duration_sec": 1, "table_id": 0, > "flags": 0, "match": {"dl_vlan": "5"}}]} > --- > > > What switch do you use? > My environment use Open vSwitch 2.3.90 like below. > --- > $ sudo ovs-ofctl --version > ovs-ofctl (Open vSwitch) 2.3.90 > Compiled Jul 29 2014 11:28:11 > OpenFlow versions 0x1:0x4 > --- > > Thanks > > On 2015年01月16日 00:10, Clément Rault wrote: >> Hi, >> >> Could it be a bug of the new version? >> >> Because I seem to remember that I tried to push some group entry with >> the example of the documentation (see below what I mean) with the last >> version and it worked. >> >> "Example of use: >> >> $ curl -X POST -d '{ >> "dpid": 1, >> "type": "ALL", >> "group_id": 1, >> "buckets": [ >> { >> "actions": [ >> { >> "type": "OUTPUT", >> "port": 1 >> } >> ] >> } >> ] >> }' http://localhost:8080/stats/groupentry/add"; >> >> Best, >> Clément >> >> >> >> On 13 January 2015 at 17:46, Clément Rault <[email protected]> wrote: >>> Hi, >>> >>> Now that I solved my other problems I'm trying to try some things >>> using group tables. >>> >>> But the weird thing is that it doesn't seem to work. >>> >>> I tried what you wrote in the previous email: >>> >>> mininet@mininet-vm:~$ curl -X POST -d '{ >>>> "dpid": 1, >>>> "type": "FF", >>>> "group_id": 1, >>>> "buckets": [ >>>> { >>>> "watch_port": 1, >>>> "actions": [ >>>> { >>>> "type": "OUTPUT", >>>> "port": 1 >>>> } >>>> ] >>>> } >>>> ] >>>> }' http://localhost:8080/stats/groupentry/add >>> mininet@mininet-vm:~$ >>> mininet@mininet-vm:~$ curl -X GET http://localhost:8080/stats/groupdesc/1 >>> {"1": []}mininet@mininet-vm:~$ >>> mininet@mininet-vm:~$ curl -X POST -d '{ >>>> "dpid": 1, >>>> "match":{ >>>> "vlan_vid": 5 >>>> }, >>>> "actions":[ >>>> { >>>> "type":"GROUP", >>>> "group_id": 1 >>>> } >>>> ] >>>> }' http://localhost:8080/stats/flowentry/add >>> mininet@mininet-vm:~$ >>> mininet@mininet-vm:~$ curl -X GET http://localhost:8080/stats/flow/1 >>> {"1": []} >>> >>> Even though ryu's log show me that the requests got accepted: >>> >>> mininet@mininet-vm:~/ryu$ PYTHONPATH=~/ryu ~/ryu/bin/ryu-manager >>> ~/ryu/ryu/app/ofctl_rest.py >>> loading app /home/mininet/ryu/ryu/app/ofctl_rest.py >>> loading app ryu.controller.ofp_handler >>> instantiating app None of DPSet >>> creating context dpset >>> creating context wsgi >>> instantiating app /home/mininet/ryu/ryu/app/ofctl_rest.py of RestStatsApi >>> instantiating app ryu.controller.ofp_handler of OFPHandler >>> (8305) wsgi starting up on http://0.0.0.0:8080/ >>> (8305) accepted ('127.0.0.1', 54645) >>> 127.0.0.1 - - [09/Jan/2015 17:38:48] "POST /stats/groupentry/add >>> HTTP/1.1" 200 115 0.010800 >>> (8305) accepted ('127.0.0.1', 54646) >>> 127.0.0.1 - - [09/Jan/2015 17:38:49] "GET /stats/groupdesc/1 HTTP/1.1" >>> 200 131 1.004360 >>> (8305) accepted ('127.0.0.1', 54647) >>> 127.0.0.1 - - [09/Jan/2015 17:38:49] "POST /stats/flowentry/add >>> HTTP/1.1" 200 115 0.001661 >>> (8305) accepted ('127.0.0.1', 54648) >>> 127.0.0.1 - - [09/Jan/2015 17:38:52] "GET /stats/flow/1 HTTP/1.1" 200 >>> 131 0.001752 >>> >>> And the weird thing is that when I try to push another flow entry >>> (that I used for another example) it's working fine: >>> >>> mininet@mininet-vm:~$ curl -X POST -d '{ >>>> "dpid": 1, >>>> "cookie": 1, >>>> "cookie_mask": 1, >>>> "table_id": 0, >>>> "idle_timeout": 0, >>>> "hard_timeout": 0, >>>> "priority": 11111, >>>> "flags": 1, >>>> "match":{ >>>> "nw_dst": "11.0.0.2", >>>> "eth_type": 2048 >>>> }, >>>> "actions":[ >>>> { >>>> "type":"OUTPUT", >>>> "port": 2 >>>> } >>>> ] >>>> }' http://localhost:8080/stats/flowentry/add >>> mininet@mininet-vm:~$ curl -X GET http://localhost:8080/stats/flow/1 >>> {"1": [{"actions": ["OUTPUT:2"], "idle_timeout": 0, "cookie": 1, >>> "packet_count": 0, "hard_timeout": 0, "byte_count": 0, "length": 96, >>> "duration_nsec": 127000000, "priority": 11111, "duration_sec": 11, >>> "table_id": 0, "flags": 1, "match": {"dl_type": 2048, "nw_dst": >>> "11.0.0.2"}}] >>> >>> Do you have any idea why? I'm running out of ideas why it doesn't work :/. >>> >>> Thanks for your help. >>> >>> Best, >>> Clément >>> >>> On 2 December 2014 at 01:56, Yusuke Iwase <[email protected]> wrote: >>>> Hi, >>>> >>>> On 2014年12月01日 20:13, Clément Rault wrote: >>>>> Hi, >>>>> >>>>> Ok, thanks. >>>>> >>>>>> I think it's right. >>>>>> OpenFlow Spec describes like as follows. >>>>>> >>>>>> ------- >>>>>> OpenFlow1.3.4 Spec: >>>>>> 5.6.1 Group Types >>>>>> ------- >>>>>> ... >>>>>> - Optional: fast failover: Execute the first live bucket. Each action >>>>>> bucket is associated with >>>>>> a specific port and/or group that controls its liveness. The buckets >>>>>> are evaluated in the order >>>>>> defined by the group, and the first bucket which is associated with >>>>>> a live port/group is selected. >>>>>> ... >>>>>> ------- >>>>>> >>>>>> Thanks >>>>> >>>>> I'm wondering what will happen if every bucket is down. Will it simply >>>>> stop the processing of this and drop it or do you think it will still >>>>> the examine the other (next) group tables (because what I understood >>>>> is that the switch will examine every group table one after each >>>>> other)? >>>> >>>> Is your question about the behavior of Group Table specified by OpenFlow? >>>> If so, please refer to OpenFlow Specification. >>>> (and see the section "5.6.1 Group Types".) >>>> >>>> https://www.opennetworking.org/sdn-resources/onf-specifications/openflow >>>> >>>> If you have still any questions, I guess you have a better chance >>>> to get an answer on ONF mailing list. >>>> >>>>> >>>>> Best, >>>>> Clément >>>>> ------------------------------------------------------------------------------ New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet _______________________________________________ Ryu-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ryu-devel
