Hi Ehsan, You can make a packet trace (trace add dpdk-input 50), then redo the test, and see what is going on.
I suspect the behavior you see has to do that we can't do the ACL on the tagged subinterface yet. The subinterface support will require tweaking the 5-tuple extraction (which would be small enoh to tackle as a bug fix) and a more subtle change to the way acl plugin gets into the packet processing path - which was a bit too risky to get into 1707. I plan to look at it post-1707 release. Could you please send the show trace output from both of your test cases so we ensure they are covered ? Thanks! --a > On 19 Jun 2017, at 14:02, Ehsan Shahrokhi <ehsan...@gmail.com> wrote: > > hi, > > I have used ACL to control packet flow between one subinterface (subif1) and > one interface (if2). My problem is when I define an acl rule with condition > on destination port (service). In other words, I defined an ACL rule with > permit action on destination port 80. next, I connected this ACL to > subinterface. It is expected that packets comming from if2 and egressing to > subif2 ahould be permitted. but it isn't. If I define a permit ACL rule > without any condition on destination port and other parameters, packet > transfer from if2 to subif1 is done successfully. > > > Condsider the following scenario: > Devices are: > Client1 ip: 10.10.10.205 > Client2 ip: 20.20.20.206 > vpp router with two Interfaces: If1 has 1 subinterface(subif1). subif1 ip is > 10.10.10.208 and if2 ip is 20.20.20.208 > > Client1 is connected to if1 by a trunk link. Client2 is connected to if2 by a > access link. > > We defined 3 acl rules. the output of acl_dump command (in vat) is shown > below: > > vl_api_acl_details_t_handler:198: acl_index: 4, count: 1 > ipv4 action 1 src 0.0.0.0/0 dst 0.0.0.0/0 proto 6 sport 1-65535 dport 80-80 > tcpflags 0 mask 0 > > vl_api_acl_details_t_handler:198: acl_index: 5, count: 1 > ipv4 action 1 src 0.0.0.0/0 dst 0.0.0.0/0 proto 0 sport 1-65535 dport 1-65535 > tcpflags 0 mask 0 > > vl_api_acl_details_t_handler:198: acl_index: 0, count: 1 > ipv4 action 0 src 0.0.0.0/0 dst 0.0.0.0/0 proto 0 sport 1-65535 dport 1-65535 > tcpflags 0 mask 0 > > In the first scenario, we connected if1 and it's subinterface(subif1) to acl > index 4 and 0 respectively. And also, We connectd if2 to acl index 5 and 0 > respectively. > > the output of acl_interfaces_list_dump is shown below: > vl_api_acl_interface_list_details_t_handler:152: sw_if_index: 1, count: 2, > n_input: 0 > input 40 > > vl_api_acl_interface_list_details_t_handler:152: sw_if_index: 8, count: 2, > n_input: 0 > input 40 > > vl_api_acl_interface_list_details_t_handler:152: sw_if_index: 2, count: 2, > n_input: 0 > input 50 > > after this configuration, The http request from client1 to client2 has sent > successfully. > > then, I have changed input acl list related to if1, subif1 and if2 which are > shown below: > > vl_api_acl_interface_list_details_t_handler:152: sw_if_index: 1, count: 2, > n_input: 0 > input 50 > > vl_api_acl_interface_list_details_t_handler:152: sw_if_index: 8, count: 2, > n_input: 0 > input 50 > > vl_api_acl_interface_list_details_t_handler:152: sw_if_index: 2, count: 2, > n_input: 0 > input 40 > > After this new configuration, The http requests from client2 to client1 > didn't send successfully. > I don't know if it is a bug. Could you please help me :) > Thanks a lot > Regards > > _______________________________________________ > vpp-dev mailing list > vpp-dev@lists.fd.io > https://lists.fd.io/mailman/listinfo/vpp-dev
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
