Hi, Thanks for the response.
Could you explain me a bit about the Ryu-manager log ? Why dst='239.255.255.250' instead of dst='10.0.0.2 ' ? Just now i noticed if I ping from 10.0.0.1 to 10.0.0.2, the ping message will look like this: ping 10.0.0.2 PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data. >From 10.0.0.1 icmp_seq=1 Destination Host Unreachable >From 10.0.0.1 icmp_seq=2 Destination Host Unreachable >From 10.0.0.1 icmp_seq=3 Destination Host Unreachable ^C --- 10.0.0.2 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, Actually, I also try to reach Lagopus developer on Github but I haven't got any response yet. Best Regards, Hong Panha On Thu, Nov 17, 2016 at 3:47 PM, Iwase Yusuke <[email protected]> wrote: > Hi, > > > On 2016年11月17日 14:32, ホンパンニャー wrote: > >> Hi, >> >> Sorry for the inconvenience. >> >> 1. The rest_firewall is fixed. >> > > Thank you for testing my patch! > I will post the patch later. > > > >> 2. I did the experiment again today. The flow status remains the same. >> Only >> the first and the last flow's "packet_count" are increased. >> >> -- Below is the output of the ping : >> >> hongpanha$ ping -c 4 10.0.0.1 >> PING 10.0.0.1 (10.0.0.1): 56 data bytes >> Request timeout for icmp_seq 0 >> Request timeout for icmp_seq 1 >> Request timeout for icmp_seq 2 >> >> --- 10.0.0.1 ping statistics --- >> 4 packets transmitted, 0 packets received, 100.0% packet loss >> >> -- Below is a part of ryu-manager log: >> >> [FW][INFO] dpid=0000000000000001: Blocked packet = >> ethernet(dst='ff:ff:ff:ff:ff:ff',ethertype=2048,src='0c:c4:7a:6d:41:3b'), >> ipv4(csum=30894,dst='255.255.255.255',flags=0,header_length= >> 5,identification=0,offset=0,option=None,proto=17,src='0.0. >> 0.0',tos=0,total_length=576,ttl=64,version=4), >> udp(csum=47429,dst_port=67,src_port=68,total_length=556), >> dhcp(boot_file='\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 >> \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ >> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ >> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ >> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ >> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ >> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ >> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ >> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ >> x00\x00\x00\x00\x00',chaddr='0c:c4:7a:6d:41:3b',ciaddr='0. >> 0.0.0',flags=0,giaddr='0.0.0.0',hlen=6,hops=0,htype=1,op=1, >> options=options(magic_cookie='99.130.83.99',option_list=[ >> option(length=1,tag=53,value='\x01'), >> option(length=7,tag=61,value='\x01\x0c\xc4zmA;'), >> option(length=12,tag=60,value='udhcp 1.12.0'), >> option(length=2,tag=57,value='\x02@'), >> option(length=7,tag=55,value='\x01\x03\x06\x0c\x0f\x1c*')],o >> ptions_len=312),secs=0,siaddr='0.0.0.0',sname=u'\x00\x00\ >> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ >> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ >> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ >> x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\ >> x00\x00\x00\x00\x00\x00',xid=1336449065,yiaddr='0.0.0.0') >> >> [FW][INFO] dpid=0000000000000001: Blocked packet = >> ethernet(dst='01:00:5e:7f:ff:fa',ethertype=2048,src='b8:6b:23:59:07:10'), >> ipv4(csum=41548,dst='239.255.255.250',flags=0,header_length= >> 5,identification=7465,offset=0,option=None,proto=17,src=' >> 10.0.0.1',tos=0,total_length=125,ttl=1,version=4), >> udp(csum=58769,dst_port=1900,src_port=56636,total_length=105), 'M-SEARCH >> * >> HTTP/1.1\r\nHost:239.255.255.250:1900 >> \r\nST:upnp:rootdevice\r\nMan:"ssdp:discover"\r\nMX:3\r\n\r\n' >> >> [FW][INFO] dpid=0000000000000001: Blocked packet = >> ethernet(dst='01:00:5e:7f:ff:fa',ethertype=2048,src='b8:6b:23:59:07:10'), >> ipv4(csum=40572,dst='239.255.255.250',flags=0,header_length= >> 5,identification=7466,offset=0,option=None,proto=17,src=' >> 10.0.0.1',tos=0,total_length=332,ttl=4,version=4), >> udp(csum=38033,dst_port=1900,src_port=1900,total_length=312), 'NOTIFY * >> HTTP/1.1\r\nLOCATION: http://10.0.0.1:53872/\r\nDATE: Thu, 17 Nov 2016 >> 4:28:29 GMT\r\nHOST: 239.255.255.250:1900\r\nSERVER: WINDOWS, UPnP/1.0, >> Intel MicroStack/1.0.1497\r\nNTS: ssdp:alive\r\nUSN: >> uuid:8a18129f-e628-57e1-cbfb-e0f72d882a46::upnp:rootdevice\r >> \nCACHE-CONTROL: >> max-age=300\r\nNT: upnp:rootdevice\r\n\r\n' >> > > Hummm... ping command shows that the first flow for ARP packets works well > and > the second and third flows for ICMP flows do not match ICMP packets, then > the > last flow for reporting packets does match them. > > I could not investigate why, because Ryu does install the flows > correctly... > It seems to be the problems on Lagopus for me... > > Thanks, > Iwase > > > >> >> Best Regards, >> Hong Panha >> >> On Wed, Nov 16, 2016 at 4:07 PM, Iwase Yusuke <[email protected]> >> wrote: >> >> Hi, >>> >>> >>> On 2016年11月14日 15:46, ホンパンニャー wrote: >>> >>> Hi, >>>> >>>> Sorry for the late reply. >>>> >>>> I have done as you suggested to the the output:normal again. I ran both >>>> rest_firewall and ofctl_rest through ryu-manager and did the command as >>>> you >>>> advised. But i still couldn't ping one another between my two PCs. >>>> >>>> Below is the output of the flow before ping: >>>> >>>> { >>>> >>>> "1": [ >>>> >>>> { >>>> >>>> "actions": [ >>>> >>>> "OUTPUT:NORMAL" >>>> >>>> ], >>>> >>>> "byte_count": 0, >>>> >>>> "cookie": 0, >>>> >>>> "duration_nsec": 125163555, >>>> >>>> "duration_sec": 213, >>>> >>>> "flags": 0, >>>> >>>> "hard_timeout": 0, >>>> >>>> "idle_timeout": 0, >>>> >>>> "length": 88, >>>> >>>> "match": { >>>> >>>> "dl_type": 2054 >>>> >>>> }, >>>> >>>> "packet_count": 0, >>>> >>>> "priority": 65534, >>>> >>>> "table_id": 0 >>>> >>>> }, >>>> >>>> { >>>> >>>> "actions": [ >>>> >>>> "OUTPUT:NORMAL" >>>> >>>> ], >>>> >>>> "byte_count": 0, >>>> >>>> "cookie": 1, >>>> >>>> "duration_nsec": 85626243, >>>> >>>> "duration_sec": 95, >>>> >>>> "flags": 0, >>>> >>>> "hard_timeout": 0, >>>> >>>> "idle_timeout": 0, >>>> >>>> "length": 112, >>>> >>>> "match": { >>>> >>>> "dl_type": 2048, >>>> >>>> "nw_dst": "10.0.0.2/255.255.255.255", >>>> >>>> "nw_proto": 1, >>>> >>>> "nw_src": "10.0.0.1/255.255.255.255" >>>> >>>> }, >>>> >>>> "packet_count": 0, >>>> >>>> "priority": 1, >>>> >>>> "table_id": 0 >>>> >>>> }, >>>> >>>> { >>>> >>>> "actions": [ >>>> >>>> "OUTPUT:NORMAL" >>>> >>>> ], >>>> >>>> "byte_count": 0, >>>> >>>> "cookie": 2, >>>> >>>> "duration_nsec": 618908488, >>>> >>>> "duration_sec": 31, >>>> >>>> "flags": 0, >>>> >>>> "hard_timeout": 0, >>>> >>>> "idle_timeout": 0, >>>> >>>> "length": 112, >>>> >>>> "match": { >>>> >>>> "dl_type": 2048, >>>> >>>> "nw_dst": "10.0.0.1/255.255.255.255", >>>> >>>> "nw_proto": 1, >>>> >>>> "nw_src": "10.0.0.2/255.255.255.255" >>>> >>>> }, >>>> >>>> "packet_count": 0, >>>> >>>> "priority": 1, >>>> >>>> "table_id": 0 >>>> >>>> }, >>>> >>>> { >>>> >>>> "actions": [ >>>> >>>> "OUTPUT:CONTROLLER" >>>> >>>> ], >>>> >>>> "byte_count": 6588, >>>> >>>> "cookie": 0, >>>> >>>> "duration_nsec": 125060275, >>>> >>>> "duration_sec": 213, >>>> >>>> "flags": 0, >>>> >>>> "hard_timeout": 0, >>>> >>>> "idle_timeout": 0, >>>> >>>> "length": 80, >>>> >>>> "match": {}, >>>> >>>> "packet_count": 12, >>>> >>>> "priority": 0, >>>> >>>> "table_id": 0 >>>> >>>> } >>>> >>>> ] >>>> >>>> } >>>> >>>> Below is the flow after the ping: >>>> >>>> { >>>> >>>> "1": [ >>>> >>>> { >>>> >>>> "actions": [ >>>> >>>> "OUTPUT:NORMAL" >>>> >>>> ], >>>> >>>> "byte_count": 1140, >>>> >>>> "cookie": 0, >>>> >>>> "duration_nsec": 676362399, >>>> >>>> "duration_sec": 745, >>>> >>>> "flags": 0, >>>> >>>> "hard_timeout": 0, >>>> >>>> "idle_timeout": 0, >>>> >>>> "length": 88, >>>> >>>> "match": { >>>> >>>> "dl_type": 2054 >>>> >>>> }, >>>> >>>> "packet_count": 19, >>>> >>>> "priority": 65534, >>>> >>>> "table_id": 0 >>>> >>>> }, >>>> >>>> { >>>> >>>> "actions": [ >>>> >>>> "OUTPUT:NORMAL" >>>> >>>> ], >>>> >>>> "byte_count": 0, >>>> >>>> "cookie": 1, >>>> >>>> "duration_nsec": 636823937, >>>> >>>> "duration_sec": 627, >>>> >>>> "flags": 0, >>>> >>>> "hard_timeout": 0, >>>> >>>> "idle_timeout": 0, >>>> >>>> "length": 112, >>>> >>>> "match": { >>>> >>>> "dl_type": 2048, >>>> >>>> "nw_dst": "10.0.0.2/255.255.255.255", >>>> >>>> "nw_proto": 1, >>>> >>>> "nw_src": "10.0.0.1/255.255.255.255" >>>> >>>> }, >>>> >>>> "packet_count": 0, >>>> >>>> "priority": 1, >>>> >>>> "table_id": 0 >>>> >>>> }, >>>> >>>> { >>>> >>>> "actions": [ >>>> >>>> "OUTPUT:NORMAL" >>>> >>>> ], >>>> >>>> "byte_count": 0, >>>> >>>> "cookie": 2, >>>> >>>> "duration_nsec": 170106132, >>>> >>>> "duration_sec": 564, >>>> >>>> "flags": 0, >>>> >>>> "hard_timeout": 0, >>>> >>>> "idle_timeout": 0, >>>> >>>> "length": 112, >>>> >>>> "match": { >>>> >>>> "dl_type": 2048, >>>> >>>> "nw_dst": "10.0.0.1/255.255.255.255", >>>> >>>> "nw_proto": 1, >>>> >>>> "nw_src": "10.0.0.2/255.255.255.255" >>>> >>>> }, >>>> >>>> "packet_count": 0, >>>> >>>> "priority": 1, >>>> >>>> "table_id": 0 >>>> >>>> }, >>>> >>>> { >>>> >>>> "actions": [ >>>> >>>> "OUTPUT:CONTROLLER" >>>> >>>> ], >>>> >>>> "byte_count": 87975, >>>> >>>> "cookie": 0, >>>> >>>> "duration_nsec": 676257789, >>>> >>>> "duration_sec": 745, >>>> >>>> "flags": 0, >>>> >>>> "hard_timeout": 0, >>>> >>>> "idle_timeout": 0, >>>> >>>> "length": 80, >>>> >>>> "match": {}, >>>> >>>> "packet_count": 263, >>>> >>>> "priority": 0, >>>> >>>> "table_id": 0 >>>> >>>> } >>>> >>>> ] >>>> >>>> } >>>> >>>> >>> The first flow in the above is the flow for ARP packets and this flow >>> seems to be installed when switch connecting. >>> The second and third flows are for ICMP (ping) packets, but >>> "packet_count" >>> fields are not incremented. >>> And, the last one is for reporting packets to the controller, and its >>> "packet_count" is incremented. >>> >>> Then, how the outputs of ping command and ryu-manager logs look like? >>> If the first flow works well, ARP request should be resolved, and ping >>> command will look like: >>> >>> # No message will be shown. >>> mininet> h1 ping h2 >>> PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data. >>> ^C >>> --- 10.0.0.2 ping statistics --- >>> 3 packets transmitted, 0 received, 100% packet loss, time 1999ms >>> >>> If the first flow does NOT work well, because ARP request should not be >>> resolved, ping command will look: >>> >>> # ping shows the destination is not reachable. >>> mininet> h1 ping h2 >>> PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data. >>> From 10.0.0.1 icmp_seq=1 Destination Host Unreachable >>> From 10.0.0.1 icmp_seq=2 Destination Host Unreachable >>> From 10.0.0.1 icmp_seq=3 Destination Host Unreachable >>> ^C >>> --- 10.0.0.2 ping statistics --- >>> 4 packets transmitted, 0 received, +3 errors, 100% packet loss, time >>> 3014ms >>> pipe 3 >>> >>> Furthermore, if the last flow works well, ryu-manager will output: >>> [FW][INFO] dpid=0000000000000001: Blocked packet = >>> ethernet(dst='00:00:00:00:00:02',ethertype=2048,src='00:00:0 >>> 0:00:00:01'), >>> ipv4(csum=36240,dst='10.0.0.2',flags=2,header_length=5,ident >>> ification=39190,offset=0,option=None,proto=1,src='10.0.0.1', >>> tos=0,total_length=84,ttl=64,version=4), icmp(code=0,csum=12505,data=ec >>> ho(data=b'\xb2\x02,X\x00\x00\x00\x00\xbf\x97\n\x00\x00\x00\ >>> x00\x00\x10\x11\x12\x13\x14\x15\x16\x17\x18\x19\x1a\x1b\x1c\x1d\x1e\x1f >>> !"#$%&\'()*+,-./01234567',id=24658,seq=15),type=8) >>> >>> >>> Could you tell us these messages? >>> >>> >>> >>> And i have noticed one more thing related to the rules of the firewall. >>>> Even if i tried to set the action: "ALLOW", when i confirm the rules it >>>> always shows "DENY". Can this be a problem ? >>>> >>>> [ >>>> >>>> { >>>> >>>> "access_control_list": [ >>>> >>>> { >>>> >>>> "rules": [ >>>> >>>> { >>>> >>>> "actions": "DENY", >>>> >>>> "dl_type": "IPv4", >>>> >>>> "nw_dst": "10.0.0.2/255.255.255.255", >>>> >>>> "nw_proto": "ICMP", >>>> >>>> "nw_src": "10.0.0.1/255.255.255.255", >>>> >>>> "priority": 1, >>>> >>>> "rule_id": 1 >>>> >>>> }, >>>> >>>> { >>>> >>>> "actions": "DENY", >>>> >>>> "dl_type": "IPv4", >>>> >>>> "nw_dst": "10.0.0.1/255.255.255.255", >>>> >>>> "nw_proto": "ICMP", >>>> >>>> "nw_src": "10.0.0.2/255.255.255.255", >>>> >>>> "priority": 1, >>>> >>>> "rule_id": 2 >>>> >>>> } >>>> >>>> ] >>>> >>>> } >>>> >>>> ], >>>> >>>> "switch_id": "0000000000000001" >>>> >>>> } >>>> >>>> ] >>>> >>>> >>> Hummm... it looks like a bug of rest_firewall.py. >>> Does the following fix this bug? >>> >>> $ git diff >>> diff --git a/ryu/app/rest_firewall.py b/ryu/app/rest_firewall.py >>> index a04525f..16b2932 100644 >>> --- a/ryu/app/rest_firewall.py >>> +++ b/ryu/app/rest_firewall.py >>> @@ -1101,7 +1101,7 @@ class Action(object): >>> @staticmethod >>> def to_rest(dp, openflow): >>> if REST_ACTION in openflow: >>> - action_allow = 'OUTPUT:%d' % dp.ofproto.OFPP_NORMAL >>> + action_allow = 'OUTPUT:NORMAL' >>> if openflow[REST_ACTION] == [action_allow]: >>> action = {REST_ACTION: REST_ACTION_ALLOW} >>> else: >>> >>> Thanks, >>> Iwase >>> >>> >>> >>> >>>> Thanks, >>>> Panha >>>> >>>> On Thu, Nov 10, 2016 at 5:03 PM, Iwase Yusuke <[email protected]> >>>> wrote: >>>> >>>> Hi, >>>> >>>>> >>>>> >>>>> On 2016年11月10日 14:22, ホンパンニャー wrote: >>>>> >>>>> Hi, >>>>> >>>>>> >>>>>> Thanks for responding. >>>>>> >>>>>> I have tried to test the output:normal by running ofctl_rest.py as you >>>>>> suggested. After running that i did the following command. >>>>>> >>>>>> # Delete all flow entries from the switch dpid=1 >>>>>> $ curl -X DELETE http://localhost:8080/stats/flowentry/clear/1 >>>>>> >>>>>> # Add flow entry with output:normal action >>>>>> $ curl -X POST -d '{ >>>>>> "dpid": "1", >>>>>> "actions": [ >>>>>> { >>>>>> "port": "NORMAL", >>>>>> "type": "OUTPUT" >>>>>> } >>>>>> ] >>>>>> }' http://localhost:8080/stats/flowentry/add >>>>>> >>>>>> # Confirm flow entries >>>>>> $ curl -X GET http://localhost:8080/stats/flow/1 | python -m >>>>>> json.tool >>>>>> >>>>>> { >>>>>> >>>>>> "1": [ >>>>>> >>>>>> { >>>>>> >>>>>> "actions": [ >>>>>> >>>>>> "OUTPUT:NORMAL" >>>>>> >>>>>> ], >>>>>> >>>>>> "byte_count": 1238, >>>>>> >>>>>> "cookie": 0, >>>>>> >>>>>> "duration_nsec": 826712542, >>>>>> >>>>>> "duration_sec": 4, >>>>>> >>>>>> "flags": 0, >>>>>> >>>>>> "hard_timeout": 0, >>>>>> >>>>>> "idle_timeout": 0, >>>>>> >>>>>> "length": 80, >>>>>> >>>>>> "match": {}, >>>>>> >>>>>> "packet_count": 4, >>>>>> >>>>>> "priority": 0, >>>>>> >>>>>> "table_id": 0 >>>>>> >>>>>> } >>>>>> >>>>>> ] >>>>>> >>>>>> } >>>>>> >>>>>> And then i connected two PCs to the switch and tried to ping one >>>>>> another, >>>>>> but it didn't work. Below is the ping result. >>>>>> >>>>>> hongpanha$ ping -c 4 10.0.0.1 >>>>>> >>>>>> PING 10.0.0.1 (10.0.0.1): 56 data bytes >>>>>> >>>>>> Request timeout for icmp_seq 0 >>>>>> >>>>>> Request timeout for icmp_seq 1 >>>>>> >>>>>> Request timeout for icmp_seq 2 >>>>>> >>>>>> >>>>>> --- 10.0.0.1 ping statistics --- >>>>>> >>>>>> 4 packets transmitted, 0 packets received, 100.0% packet loss >>>>>> >>>>>> >>>>>> Well, this shows output:normal action does not work. >>>>> This seems to be the problem on the Lagopus side... >>>>> >>>>> For making sure that Ryu can install the flows correctly, >>>>> please check the flow entries by using ofctl_rest.py. >>>>> >>>>> e.g.) >>>>> # Run rest_firewall and ofctl_rest >>>>> $ ryu-manager ryu.app.rest_firewall ryu.app.ofctl_rest >>>>> >>>>> # Enable firewall on switch dpid=1 >>>>> $ curl -X PUT http://localhost:8080/firewall >>>>> /module/enable/000000000000000 >>>>> 1 >>>>> >>>>> # Install rules for ICMP connectivity. >>>>> # The following is sample rules from Ryu-Book. >>>>> $ curl -X POST -d '{"nw_src": "10.0.0.1/32", "nw_dst": "10.0.0.2/32", >>>>> "nw_proto": "ICMP"}' http://localhost:8080/firewall >>>>> /rules/0000000000000001 >>>>> $ curl -X POST -d '{"nw_src": "10.0.0.2/32", "nw_dst": "10.0.0.1/32", >>>>> "nw_proto": "ICMP"}' http://localhost:8080/firewall >>>>> /rules/0000000000000001 >>>>> >>>>> # Confirm the flows. >>>>> $ curl -X GET http://localhost:8080/stats/flow/1 | python -m json.tool >>>>> { >>>>> "1": [ >>>>> { >>>>> "actions": [ >>>>> "OUTPUT:NORMAL" >>>>> ], >>>>> "byte_count": 168, >>>>> "cookie": 0, >>>>> "duration_nsec": 105000000, >>>>> "duration_sec": 488, >>>>> "flags": 0, >>>>> "hard_timeout": 0, >>>>> "idle_timeout": 0, >>>>> "length": 88, >>>>> "match": { >>>>> "dl_type": 2054 >>>>> }, >>>>> "packet_count": 4, # Packet count should be incremented >>>>> "priority": 65534, >>>>> "table_id": 0 >>>>> }, >>>>> { >>>>> "actions": [ >>>>> "OUTPUT:NORMAL" >>>>> ], >>>>> "byte_count": 294, >>>>> "cookie": 1, >>>>> "duration_nsec": 268000000, >>>>> "duration_sec": 439, >>>>> "flags": 0, >>>>> "hard_timeout": 0, >>>>> "idle_timeout": 0, >>>>> "length": 104, >>>>> "match": { >>>>> "dl_type": 2048, >>>>> "nw_dst": "10.0.0.2", >>>>> "nw_proto": 1, >>>>> "nw_src": "10.0.0.1" >>>>> }, >>>>> "packet_count": 3, # Packet count should be incremented >>>>> "priority": 1, >>>>> "table_id": 0 >>>>> }, >>>>> { >>>>> "actions": [ >>>>> "OUTPUT:NORMAL" >>>>> ], >>>>> "byte_count": 294, >>>>> "cookie": 2, >>>>> "duration_nsec": 882000000, >>>>> "duration_sec": 429, >>>>> "flags": 0, >>>>> "hard_timeout": 0, >>>>> "idle_timeout": 0, >>>>> "length": 104, >>>>> "match": { >>>>> "dl_type": 2048, >>>>> "nw_dst": "10.0.0.1", >>>>> "nw_proto": 1, >>>>> "nw_src": "10.0.0.2" >>>>> }, >>>>> "packet_count": 3, # Packet count should be incremented >>>>> "priority": 1, >>>>> "table_id": 0 >>>>> }, >>>>> { >>>>> "actions": [ >>>>> "OUTPUT:CONTROLLER" >>>>> ], >>>>> "byte_count": 0, >>>>> "cookie": 0, >>>>> "duration_nsec": 105000000, >>>>> "duration_sec": 488, >>>>> "flags": 0, >>>>> "hard_timeout": 0, >>>>> "idle_timeout": 0, >>>>> "length": 80, >>>>> "match": {}, >>>>> "packet_count": 0, >>>>> "priority": 0, >>>>> "table_id": 0 >>>>> } >>>>> ] >>>>> } >>>>> >>>>> If ping (ICPM packets) can communicate, "packet_count" fields should be >>>>> incremented. >>>>> And if the flow is installed as expected and packet counts are not >>>>> incremented, >>>>> Lagopus might drop packets or not make matching packets to the flow. >>>>> >>>>> >>>>> Thanks, >>>>> Iwase >>>>> >>>>> >>>>> Regards, >>>>> >>>>>> Panha >>>>>> >>>>>> On Wed, Nov 9, 2016 at 9:47 AM, Iwase Yusuke <[email protected] >>>>>> > >>>>>> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>>> Sorry for the delay. >>>>>>> >>>>>>> I have no environment for running DPDK-enabled Lagopus, >>>>>>> and it takes times to investigate why... >>>>>>> (I know KVM can be available, but have not tried yet...) >>>>>>> >>>>>>> For pointing the cause, could you test your Lagopus whether >>>>>>> output:normal action works well or not? >>>>>>> >>>>>>> e.g.) If you use ofctl_rest.py, >>>>>>> $ ryu-manager ryu.app.ofctl_rest >>>>>>> ... >>>>>>> >>>>>>> # Delete all flow entries from the switch dpid=1 >>>>>>> $ curl -X DELETE http://localhost:8080/stats/flowentry/clear/1 >>>>>>> >>>>>>> # Add flow entry with output:normal action >>>>>>> $ curl -X POST -d '{ >>>>>>> "dpid": "1", >>>>>>> "actions": [ >>>>>>> { >>>>>>> "port": "NORMAL", >>>>>>> "type": "OUTPUT" >>>>>>> } >>>>>>> ] >>>>>>> }' http://localhost:8080/stats/flowentry/add >>>>>>> >>>>>>> # Confirm flow entries >>>>>>> # --> Please confirm the flow table has only one with output:normal >>>>>>> action >>>>>>> $ curl -X GET http://localhost:8080/stats/flow/1 | python -m >>>>>>> json.tool >>>>>>> { >>>>>>> "1": [ >>>>>>> { >>>>>>> "actions": [ >>>>>>> "OUTPUT:NORMAL" >>>>>>> ], >>>>>>> "byte_count": 0, >>>>>>> "cookie": 0, >>>>>>> "duration_nsec": 653000000, >>>>>>> "duration_sec": 25, >>>>>>> "flags": 0, >>>>>>> "hard_timeout": 0, >>>>>>> "idle_timeout": 0, >>>>>>> "length": 80, >>>>>>> "match": {}, >>>>>>> "packet_count": 0, >>>>>>> "priority": 0, >>>>>>> "table_id": 0 >>>>>>> } >>>>>>> ] >>>>>>> } >>>>>>> >>>>>>> # Test ping >>>>>>> $ ping -c 1 <Dest IP> >>>>>>> ... >>>>>>> >>>>>>> If ping does not work, output:normal action does not work as >>>>>>> expected. >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> Iwase >>>>>>> >>>>>>> >>>>>>> On 2016年10月25日 19:28, ホンパンニャー wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> >>>>>>>> Today, I already reinstalled Lagopus 0.2.6 on my environment with >>>>>>>> Hybrid >>>>>>>> enable following QUICKSTART.md. >>>>>>>> $ cd lagopus >>>>>>>> $ ./configure --with-dpdk-dir=${RTE_SDK} --enable-hybrid=yes >>>>>>>> $ make >>>>>>>> $ sudo make install >>>>>>>> >>>>>>>> After the installation, Lagopus works well with >>>>>>>> "simple_switch_13.py", >>>>>>>> But >>>>>>>> still not working with "rest_firewall.py". I did my experiment >>>>>>>> following >>>>>>>> Ryu-Book but I still cannot ping between host. >>>>>>>> >>>>>>>> Do you have any suggestions ? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Panha >>>>>>>> >>>>>>>> On Thu, Aug 18, 2016 at 4:15 PM, ホンパンニャー <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> >>>>>>>> Thanks for your responding. >>>>>>>>> >>>>>>>>> I will try to reinstall Lagopus with DPDK support ("./configure >>>>>>>>> --enable-hybrid=yes") and I will let you know again if it works or >>>>>>>>> not. >>>>>>>>> >>>>>>>>> Once again thanks. >>>>>>>>> >>>>>>>>> Best Regards, >>>>>>>>> Panha >>>>>>>>> >>>>>>>>> On Thu, Aug 18, 2016 at 10:19 AM, Iwase Yusuke < >>>>>>>>> [email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> >>>>>>>>> Sorry, I don't know much about Lagopus, but I think you need to >>>>>>>>>> reinstall >>>>>>>>>> Lagopus with "--enable-hybrid=yes" configure option. >>>>>>>>>> e.g.) According to the QUICKSTART.md and "./configure --help" >>>>>>>>>> page, >>>>>>>>>> $ cd lagopus >>>>>>>>>> $ ./configure --enable-hybrid=yes >>>>>>>>>> $ make >>>>>>>>>> $ sudo make install >>>>>>>>>> >>>>>>>>>> On my environment, I couldn't use the DPDK support, I use the >>>>>>>>>> following >>>>>>>>>> configure option: >>>>>>>>>> $ ./configure --disable-dpdk --enable-hybrid=yes >>>>>>>>>> but, it seems that "output": "normal" action does not work well. >>>>>>>>>> >>>>>>>>>> Could you try with the DPDK support? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Iwase >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2016年08月14日 21:55, ホンパンニャー wrote: >>>>>>>>>> >>>>>>>>>> Hi Iwase, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I am sorry to disturb you again. >>>>>>>>>>> >>>>>>>>>>> I have read the Lagopus issues page that you suggested last time >>>>>>>>>>> and >>>>>>>>>>> i >>>>>>>>>>> totally have the same problem. However, i don't know how to >>>>>>>>>>> specify >>>>>>>>>>> "--enable-hybrid" to Lagopus switch. I did ask them and they said >>>>>>>>>>> that >>>>>>>>>>> i >>>>>>>>>>> have to specify it through configure command during installing >>>>>>>>>>> steps, >>>>>>>>>>> but I >>>>>>>>>>> already installed lagopus following the QUICKSTART.md. Do i have >>>>>>>>>>> to >>>>>>>>>>> reinstall it or what ? Are there any other solutions ? Can it be >>>>>>>>>>> the >>>>>>>>>>> problem with Ryu like STP case? >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Panha >>>>>>>>>>> >>>>>>>>>>> On Wed, Aug 3, 2016 at 2:07 PM, University < >>>>>>>>>>> [email protected] >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks for responding. >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I am figuring out how to specify "--enable-hybrid" in lagopus >>>>>>>>>>>> configure >>>>>>>>>>>> now. I will let you know if it's work. >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> Panha >>>>>>>>>>>> >>>>>>>>>>>> Sent from my iPhone >>>>>>>>>>>> >>>>>>>>>>>> On Aug 3, 2016, at 12:04 PM, Iwase Yusuke < >>>>>>>>>>>> [email protected]> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> According to the issues page on Lagopus GitHub, >>>>>>>>>>>>> you need to specify '--enable-hybrid' in configure, I guess. >>>>>>>>>>>>> https://github.com/lagopus/lagopus/issues/76 >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Iwase >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 2016年08月02日 17:25, Hong Panha wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi everyone, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> I am trying run rest_firewall.py with ryu-manager, it’s not >>>>>>>>>>>>>> function >>>>>>>>>>>>>> >>>>>>>>>>>>>> well. I am using Lagopus as my open flow switch. Even I set >>>>>>>>>>>>>> the >>>>>>>>>>>>>> >>>>>>>>>>>>>> rule to >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> give the permission for the packet but i still cannot ping. >>>>>>>>>>>>> Please >>>>>>>>>>>>> >>>>>>>>>>>>> refer to >>>>>>>>>>>> the attachment file which consist of log from ryu- manager and >>>>>>>>>>>> rules >>>>>>>>>>>> of >>>>>>>>>>>> firewall. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I am looking forward to hearing back from you. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Best Regards, >>>>>>>>>>>>>> Hong Panha >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ------------------------------------------------------------ >>>>>>>>>>>>>> >>>>>>>>>>>>>> ------------------ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>> >>>>>>>>>>>>>> Ryu-devel mailing list >>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/ryu-devel >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> ------------------------------------------------------------ >>>>>>>>>>> ------------------ >>>>>>>>>>> What NetFlow Analyzer can do for you? Monitors network bandwidth >>>>>>>>>>> and >>>>>>>>>>> traffic >>>>>>>>>>> patterns at an interface-level. Reveals which users, apps, and >>>>>>>>>>> protocols >>>>>>>>>>> are >>>>>>>>>>> consuming the most bandwidth. Provides multi-vendor support for >>>>>>>>>>> NetFlow, >>>>>>>>>>> J-Flow, sFlow and other flows. Make informed decisions using >>>>>>>>>>> capacity >>>>>>>>>>> planning reports. http://sdm.link/zohodev2dev >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Ryu-devel mailing list >>>>>>>>>>> [email protected] >>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/ryu-devel >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>> 東京工科大学 コンピュータサイエンス学部 ネットワークコース 4年次 >>>>>>>>> ホン パンニャー >>>>>>>>> HONG Panha >>>>>>>>> Tel: 090 6523 1168 >>>>>>>>> Email: [email protected] >>>>>>>>> 〒192-0372 東京都八王子市下柚木1987-1大学セミナーハウス102号室 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------------------ >>>>>>>> ------------------ >>>>>>>> The Command Line: Reinvented for Modern Developers >>>>>>>> Did the resurgence of CLI tooling catch you by surprise? >>>>>>>> Reconnect with the command line and become more productive. >>>>>>>> Learn the new .NET and ASP.NET CLI. Get your free copy! >>>>>>>> http://sdm.link/telerik >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Ryu-devel mailing list >>>>>>>> [email protected] >>>>>>>> https://lists.sourceforge.net/lists/listinfo/ryu-devel >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> ------------------------------------------------------------ >>>>>> ------------------ >>>>>> Developer Access Program for Intel Xeon Phi Processors >>>>>> Access to Intel Xeon Phi processor-based developer platforms. >>>>>> With one year of Intel Parallel Studio XE. >>>>>> Training and support from Colfax. >>>>>> Order your platform today. http://sdm.link/xeonphi >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Ryu-devel mailing list >>>>>> [email protected] >>>>>> https://lists.sourceforge.net/lists/listinfo/ryu-devel >>>>>> >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> ------------------------------------------------------------ >>>> ------------------ >>>> Developer Access Program for Intel Xeon Phi Processors >>>> Access to Intel Xeon Phi processor-based developer platforms. >>>> With one year of Intel Parallel Studio XE. >>>> Training and support from Colfax. >>>> Order your platform today. http://sdm.link/xeonphi >>>> >>>> >>>> >>>> _______________________________________________ >>>> Ryu-devel mailing list >>>> [email protected] >>>> https://lists.sourceforge.net/lists/listinfo/ryu-devel >>>> >>>> >>>> >> >> >> >> ------------------------------------------------------------ >> ------------------ >> >> >> >> _______________________________________________ >> Ryu-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/ryu-devel >> >> -- 東京工科大学 コンピュータサイエンス学部 ネットワークコース 4年次 ホン パンニャー HONG Panha Tel: 090 6523 1168 Email: [email protected] 〒192-0372 東京都八王子市下柚木1987-1大学セミナーハウス102号室
------------------------------------------------------------------------------
_______________________________________________ Ryu-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ryu-devel
