Hi, Sorry for the inconvenience.
1. The rest_firewall is fixed. 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*')],options_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' 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:00: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 >> >> -- 東京工科大学 コンピュータサイエンス学部 ネットワークコース 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
