Hi, Yeah, I meant that packet.
Hmm How about the ping message ? Do you have any clues why ping message form 10.0.0.1 to 10.0.0.2 (Unreachable) are different from the one from 10.0.0.2 to 10.0.0.1 ( time out ) ? Best Regards, Hong Panha On Thu, Nov 17, 2016 at 5:04 PM, Iwase Yusuke <[email protected]> wrote: > > > On 2016年11月17日 16:18, ホンパンニャー wrote: > >> 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 ' ? >> > > Do you mean this packet? > > [FW][INFO] dpid=0000000000000001: Blocked packet = >>>> ethernet(dst='01:00:5e:7f:ff:fa',ethertype=2048,src='b8:6b:2 >>>> 3: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' >>>> >>> > dst='239.255.255.250' means the UPnP packet (from Google search results), > but I don't know further... > > Thanks, > Iwase > > > >> >> 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:7 >>>> a: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:2 >>>> 3: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:2 >>>> 3: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 >>>> >>>> >>>> >> >> >> >> ------------------------------------------------------------ >> ------------------ >> >> >> >> _______________________________________________ >> 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
