thank you Andrew for you quick response.
sorry, I forgot correcting acl_interface_list_dump output. I do know
acl_interface_list_dump has problem in showing acl index list as input and
it's output is wrong. Indeed I had set acl list on interfaces in output
mode.
the corrected configuration is shown below. please check my configuration
and packet trace again. thanks in advance
Best Regards.
My topology
client1 ------- subif1_____router-vpp____if2-----------client2
In this configuration subif1 index is 8 and if2 index is 2
vat# acl_dump
vl_api_acl_details_t_handler:198: acl_index: 0, 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: 1, 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
vl_api_acl_details_t_handler:198: acl_index: 2, 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
vat# acl_interface_list_dump
vl_api_acl_interface_list_details_t_handler:152: sw_if_index: 0, count: 0,
n_input: 0
input
output
vl_api_acl_interface_list_details_t_handler:152: sw_if_index: 1, count: 2,
n_input: 0
input
output 21
vat# vl_api_acl_interface_list_details_t_handler:152: sw_if_index: 2,
count: 2, n_input: 0
input
output 01
vl_api_acl_interface_list_details_t_handler:152: sw_if_index: 3, count: 1,
n_input: 0
input
output 1
vl_api_acl_interface_list_details_t_handler:152: sw_if_index: 4, count: 0,
n_input: 0
input
output
vl_api_acl_interface_list_details_t_handler:152: sw_if_index: 5, count: 0,
n_input: 0
input
output
vl_api_acl_interface_list_details_t_handler:152: sw_if_index: 6, count: 0,
n_input: 0
input
output
vl_api_acl_interface_list_details_t_handler:152: sw_if_index: 7, count: 0,
n_input: 0
input
output
vl_api_acl_interface_list_details_t_handler:152: sw_if_index: 8, count: 2,
n_input: 0
input
output 21
In this configuration subif1 index is 8 and if2 index is 2
I expect that http connection will be established successfully from client2
to client1 but it is not.
root@debian:~# vppctl show trace
------------------- Start of thread 0 vpp_main -------------------
Packet 1
02:40:16:329252: dpdk-input
GigabitEthernetb/0/0 rx queue 0
buffer 0x1d256: current data 14, length 60, free-list 0, clone-count 0,
totlen-nifb 0, trace 0x0
PKT MBUF: port 1, nb_segs 1, pkt_len 74
buf_len 2176, data_len 74, ol_flags 0x0, data_off 128, phys_addr
0x5c145480
packet_type 0x10
Packet Types
RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers
IP4: 00:50:56:92:ce:1f -> 00:50:56:92:8e:b1
TCP: 20.20.20.206 -> 10.10.10.205
tos 0x00, ttl 64, length 60, checksum 0x35b9
fragment id 0xc74a, flags DONT_FRAGMENT
02:40:16:329456: ip4-input
TCP: 20.20.20.206 -> 10.10.10.205
tos 0x00, ttl 64, length 60, checksum 0x35b9
fragment id 0xc74a, flags DONT_FRAGMENT
02:40:16:329492: ip4-lookup
fib 0 dpo-idx 4 flow hash: 0x00000000
TCP: 20.20.20.206 -> 10.10.10.205
tos 0x00, ttl 64, length 60, checksum 0x35b9
fragment id 0xc74a, flags DONT_FRAGMENT
02:40:16:329544: ip4-rewrite
tx_sw_if_index 8 dpo-idx 4 : ipv4 via 10.10.10.205
GigabitEthernet3/0/0.1: 00505692236500505692607f810000010800 flow hash:
0x00000000
00000000: 00505692236500505692607f8100000108004500003cc74a40003f0636b91414
00000020: 14ce0a0a0acda1ce005078240ff800000000a00272108b2500000204
02:40:16:329548: acl-plugin-out-ip4-fa
acl-plugin: sw_if_index 8, next index 0, action: 0, match: acl 1 rule 0
trace_bits 00000000
pkt info 0000000000000000 b936063f00000000 0000000000000000
ce14141400000000 0000004a00000000 0000000000000800
02:40:16:329558: error-drop
acl-plugin-out-ip4-fa: ACL deny packets
Packet 2
02:40:17:327862: dpdk-input
GigabitEthernetb/0/0 rx queue 0
buffer 0x1d22f: current data 14, length 60, free-list 0, clone-count 0,
totlen-nifb 0, trace 0x1
PKT MBUF: port 1, nb_segs 1, pkt_len 74
buf_len 2176, data_len 74, ol_flags 0x0, data_off 128, phys_addr
0x5c144ac0
packet_type 0x10
Packet Types
RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers
IP4: 00:50:56:92:ce:1f -> 00:50:56:92:8e:b1
TCP: 20.20.20.206 -> 10.10.10.205
tos 0x00, ttl 64, length 60, checksum 0x35b8
fragment id 0xc74b, flags DONT_FRAGMENT
02:40:17:327881: ip4-input
TCP: 20.20.20.206 -> 10.10.10.205
tos 0x00, ttl 64, length 60, checksum 0x35b8
fragment id 0xc74b, flags DONT_FRAGMENT
02:40:17:327890: ip4-lookup
fib 0 dpo-idx 4 flow hash: 0x00000000
TCP: 20.20.20.206 -> 10.10.10.205
tos 0x00, ttl 64, length 60, checksum 0x35b8
fragment id 0xc74b, flags DONT_FRAGMENT
02:40:17:327893: ip4-rewrite
tx_sw_if_index 8 dpo-idx 4 : ipv4 via 10.10.10.205
GigabitEthernet3/0/0.1: 00505692236500505692607f810000010800 flow hash:
0x00000000
00000000: 00505692236500505692607f8100000108004500003cc74b40003f0636b81414
00000020: 14ce0a0a0acda1ce005078240ff800000000a00272108a2a00000204
02:40:17:327897: acl-plugin-out-ip4-fa
acl-plugin: sw_if_index 8, next index 0, action: 0, match: acl 1 rule 0
trace_bits 00000000
pkt info 0000000000000000 b836063f00000000 0000000000000000
ce14141400000000 0000004b00000000 0000000000000800
02:40:17:327902: error-drop
acl-plugin-out-ip4-fa: ACL deny packets
Packet 3
02:40:19:336554: dpdk-input
GigabitEthernetb/0/0 rx queue 0
buffer 0x1d208: current data 14, length 60, free-list 0, clone-count 0,
totlen-nifb 0, trace 0x2
PKT MBUF: port 1, nb_segs 1, pkt_len 74
buf_len 2176, data_len 74, ol_flags 0x0, data_off 128, phys_addr
0x5c144100
packet_type 0x10
Packet Types
RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers
IP4: 00:50:56:92:ce:1f -> 00:50:56:92:8e:b1
TCP: 20.20.20.206 -> 10.10.10.205
tos 0x00, ttl 64, length 60, checksum 0x35b7
fragment id 0xc74c, flags DONT_FRAGMENT
02:40:19:336590: ip4-input
TCP: 20.20.20.206 -> 10.10.10.205
tos 0x00, ttl 64, length 60, checksum 0x35b7
fragment id 0xc74c, flags DONT_FRAGMENT
02:40:19:336599: ip4-lookup
fib 0 dpo-idx 4 flow hash: 0x00000000
TCP: 20.20.20.206 -> 10.10.10.205
tos 0x00, ttl 64, length 60, checksum 0x35b7
fragment id 0xc74c, flags DONT_FRAGMENT
02:40:19:336603: ip4-rewrite
tx_sw_if_index 8 dpo-idx 4 : ipv4 via 10.10.10.205
GigabitEthernet3/0/0.1: 00505692236500505692607f810000010800 flow hash:
0x00000000
00000000: 00505692236500505692607f8100000108004500003cc74c40003f0636b71414
00000020: 14ce0a0a0acda1ce005078240ff800000000a0027210883300000204
02:40:19:336607: acl-plugin-out-ip4-fa
acl-plugin: sw_if_index 8, next index 0, action: 0, match: acl 1 rule 0
trace_bits 00000000
pkt info 0000000000000000 b736063f00000000 0000000000000000
ce14141400000000 0000004c00000000 0000000000000800
02:40:19:336612: error-drop
acl-plugin-out-ip4-fa: ACL deny packets
Packet 4
02:40:21:371646: dpdk-input
GigabitEthernetb/0/0 rx queue 0
buffer 0x1d1e1: current data 0, length 60, free-list 0, clone-count 0,
totlen-nifb 0, trace 0x3
PKT MBUF: port 1, nb_segs 1, pkt_len 60
buf_len 2176, data_len 60, ol_flags 0x0, data_off 128, phys_addr
0x5c143740
packet_type 0x0
ARP: 00:50:56:92:ce:1f -> 00:50:56:92:8e:b1
request, type ethernet/IP4, address size 6/4
00:50:56:92:ce:1f/20.20.20.206 -> 00:00:00:00:00:00/20.20.20.208
02:40:21:371663: ethernet-input
ARP: 00:50:56:92:ce:1f -> 00:50:56:92:8e:b1
02:40:21:371673: arp-input
request, type ethernet/IP4, address size 6/4
00:50:56:92:ce:1f/20.20.20.206 -> 00:00:00:00:00:00/20.20.20.208
02:40:21:371779: GigabitEthernetb/0/0-output
GigabitEthernetb/0/0
ARP: 00:50:56:92:8e:b1 -> 00:50:56:92:ce:1f
reply, type ethernet/IP4, address size 6/4
00:50:56:92:8e:b1/20.20.20.208 -> 00:50:56:92:ce:1f/20.20.20.206
02:40:21:371781: GigabitEthernetb/0/0-tx
GigabitEthernetb/0/0 tx queue 0
buffer 0x1d1e1: current data 0, length 60, free-list 0, clone-count 0,
totlen-nifb 0, trace 0x3
ARP: 00:50:56:92:8e:b1 -> 00:50:56:92:ce:1f
reply, type ethernet/IP4, address size 6/4
00:50:56:92:8e:b1/20.20.20.208 -> 00:50:56:92:ce:1f/20.20.20.206
As regards to my configuration, I expected packets 1,2,3 to be matched with
acl 2 and to be permitted but they were matched with acl 1 and dropped. It
seems that setting acl on subif caused this problem and there is
incompatibility between ACL plugin and subinterfaces
On Tue, Jun 20, 2017 at 5:28 PM, Andrew 👽 Yourtchenko <ayour...@gmail.com>
wrote:
> hi Ehsan,
>
> The packet trace confirms the packet gets dropped on egress by ACL#1,
> and the dump confirms all of the ACLs are applied on output (n_input =
> 0 - so the interface does not have). The "output" word is erroneously
> not printed. I made a fix for this in
> https://gerrit.fd.io/r/#/c/7227/, you can pull it in and check. (also,
> you might want the 7225 as well, it was on the backburner till I was
> finishing the new lookup code). Sorry for the confusing bug!
>
> To simplify looking at what is actually configured on the box, the
> latest master code has "show acl-plugin acl" and "show acl-plugin
> interface" debug CLI commands which should make life a bit easier -
> could you try your tests with that version and verify the outputs
> there ? Also there are a few more CLIs to get the insight into the
> internals of the new lookup - https://gerrit.fd.io/r/#/c/6858/ commit
> message has more info. (Obviously I'll doc that before the 1707
> release, but for now that's the authoritative source :)
>
> --a
>
>
> On 6/20/17, Ehsan Shahrokhi <ehsan...@gmail.com> wrote:
> > *Hi Andrew,*
> >
> > *My topology*
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > * client1 ------- subif1_____router-vpp____if2-----------client2 In this
> > configuration subif1 index is 8 and if2 index is 2 vat# acl_dump
> > vl_api_acl_details_t_handler:198: acl_index: 0, count: 1 ipv4 action
> 1
> > src 0.0.0.0/0 <http://0.0.0.0/0> dst 0.0.0.0/0 <http://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: 1, count: 1 ipv4 action
> 0
> > src 0.0.0.0/0 <http://0.0.0.0/0> dst 0.0.0.0/0 <http://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: 2, count: 1 ipv4 action
> 1
> > src 0.0.0.0/0 <http://0.0.0.0/0> dst 0.0.0.0/0 <http://0.0.0.0/0> proto
> 6
> > sport 1-65535 dport 80-80 tcpflags 0 mask 0 vat# acl_interface_list_dump
> > vl_api_acl_interface_list_details_t_handler:152: sw_if_index: 0, count:
> 0,
> > n_input: 0 input vl_api_acl_interface_list_details_t_handler:152:
> > sw_if_index: 1, count: 2, n_input: 0 input 21 vat#
> > vl_api_acl_interface_list_details_t_handler:152: sw_if_index: 2, count:
> 2,
> > n_input: 0 input 01 vl_api_acl_interface_list_details_t_handler:152:
> > sw_if_index: 3, count: 1, n_input: 0 input 1
> > vl_api_acl_interface_list_details_t_handler:152: sw_if_index: 4, count:
> 0,
> > n_input: 0 input vl_api_acl_interface_list_details_t_handler:152:
> > sw_if_index: 5, count: 0, n_input: 0 input
> > vl_api_acl_interface_list_details_t_handler:152: sw_if_index: 6, count:
> 0,
> > n_input: 0 input vl_api_acl_interface_list_details_t_handler:152:
> > sw_if_index: 7, count: 0, n_input: 0 input
> > vl_api_acl_interface_list_details_t_handler:152: sw_if_index: 8, count:
> 2,
> > n_input: 0 input 21 In this configuration subif1 index is 8 and if2
> > index is 2 I expect that http connection will be established successfully
> > from client2 to client1 but it is not. root@NGFW:~# vppctl show trace
> > ------------------- Start of thread 0 vpp_main -------------------
> Packet 1
> > 02:40:16:329252: dpdk-input GigabitEthernetb/0/0 rx queue 0 buffer
> > 0x1d256: current data 14, length 60, free-list 0, clone-count 0,
> > totlen-nifb 0, trace 0x0 PKT MBUF: port 1, nb_segs 1, pkt_len 74
> > buf_len 2176, data_len 74, ol_flags 0x0, data_off 128, phys_addr
> 0x5c145480
> > packet_type 0x10 Packet Types RTE_PTYPE_L3_IPV4 (0x0010)
> IPv4
> > packet without extension headers IP4: 00:50:56:92:ce:1f ->
> > 00:50:56:92:8e:b1 TCP: 20.20.20.206 -> 10.10.10.205 tos 0x00, ttl
> 64,
> > length 60, checksum 0x35b9 fragment id 0xc74a, flags DONT_FRAGMENT
> > 02:40:16:329456: ip4-input TCP: 20.20.20.206 -> 10.10.10.205 tos
> > 0x00, ttl 64, length 60, checksum 0x35b9 fragment id 0xc74a, flags
> > DONT_FRAGMENT 02:40:16:329492: ip4-lookup fib 0 dpo-idx 4 flow hash:
> > 0x00000000 TCP: 20.20.20.206 -> 10.10.10.205 tos 0x00, ttl 64,
> length
> > 60, checksum 0x35b9 fragment id 0xc74a, flags DONT_FRAGMENT
> > 02:40:16:329544: ip4-rewrite tx_sw_if_index 8 dpo-idx 4 : ipv4 via
> > 10.10.10.205 GigabitEthernet3/0/0.1: 00505692236500505692607f810000
> 010800
> > flow hash: 0x00000000 00000000:
> > 00505692236500505692607f8100000108004500003cc74a40003f0636b91414
> > 00000020: 14ce0a0a0acda1ce005078240ff800000000a00272108b2500000204
> > 02:40:16:329548: acl-plugin-out-ip4-fa acl-plugin: sw_if_index 8, next
> > index 0, action: 0, match: acl 1 rule 0 trace_bits 00000000 pkt info
> > 0000000000000000 b936063f00000000 0000000000000000 ce14141400000000
> > 0000004a00000000 0000000000000800 02:40:16:329558: error-drop
> > acl-plugin-out-ip4-fa: ACL deny packets Packet 2 02:40:17:327862:
> > dpdk-input GigabitEthernetb/0/0 rx queue 0 buffer 0x1d22f: current
> data
> > 14, length 60, free-list 0, clone-count 0, totlen-nifb 0, trace 0x1 PKT
> > MBUF: port 1, nb_segs 1, pkt_len 74 buf_len 2176, data_len 74,
> ol_flags
> > 0x0, data_off 128, phys_addr 0x5c144ac0 packet_type 0x10 Packet
> > Types RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension
> > headers IP4: 00:50:56:92:ce:1f -> 00:50:56:92:8e:b1 TCP: 20.20.20.206
> > -> 10.10.10.205 tos 0x00, ttl 64, length 60, checksum 0x35b8
> > fragment id 0xc74b, flags DONT_FRAGMENT 02:40:17:327881: ip4-input TCP:
> > 20.20.20.206 -> 10.10.10.205 tos 0x00, ttl 64, length 60, checksum
> > 0x35b8 fragment id 0xc74b, flags DONT_FRAGMENT 02:40:17:327890:
> > ip4-lookup fib 0 dpo-idx 4 flow hash: 0x00000000 TCP: 20.20.20.206 ->
> > 10.10.10.205 tos 0x00, ttl 64, length 60, checksum 0x35b8
> fragment
> > id 0xc74b, flags DONT_FRAGMENT 02:40:17:327893: ip4-rewrite
> > tx_sw_if_index 8 dpo-idx 4 : ipv4 via 10.10.10.205
> GigabitEthernet3/0/0.1:
> > 00505692236500505692607f810000010800 flow hash: 0x00000000 00000000:
> > 00505692236500505692607f8100000108004500003cc74b40003f0636b81414
> > 00000020: 14ce0a0a0acda1ce005078240ff800000000a00272108a2a00000204
> > 02:40:17:327897: acl-plugin-out-ip4-fa acl-plugin: sw_if_index 8, next
> > index 0, action: 0, match: acl 1 rule 0 trace_bits 00000000 pkt info
> > 0000000000000000 b836063f00000000 0000000000000000 ce14141400000000
> > 0000004b00000000 0000000000000800 02:40:17:327902: error-drop
> > acl-plugin-out-ip4-fa: ACL deny packets Packet 3 02:40:19:336554:
> > dpdk-input GigabitEthernetb/0/0 rx queue 0 buffer 0x1d208: current
> data
> > 14, length 60, free-list 0, clone-count 0, totlen-nifb 0, trace 0x2 PKT
> > MBUF: port 1, nb_segs 1, pkt_len 74 buf_len 2176, data_len 74,
> ol_flags
> > 0x0, data_off 128, phys_addr 0x5c144100 packet_type 0x10 Packet
> > Types RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension
> > headers IP4: 00:50:56:92:ce:1f -> 00:50:56:92:8e:b1 TCP: 20.20.20.206
> > -> 10.10.10.205 tos 0x00, ttl 64, length 60, checksum 0x35b7
> > fragment id 0xc74c, flags DONT_FRAGMENT 02:40:19:336590: ip4-input TCP:
> > 20.20.20.206 -> 10.10.10.205 tos 0x00, ttl 64, length 60, checksum
> > 0x35b7 fragment id 0xc74c, flags DONT_FRAGMENT 02:40:19:336599:
> > ip4-lookup fib 0 dpo-idx 4 flow hash: 0x00000000 TCP: 20.20.20.206 ->
> > 10.10.10.205 tos 0x00, ttl 64, length 60, checksum 0x35b7
> fragment
> > id 0xc74c, flags DONT_FRAGMENT 02:40:19:336603: ip4-rewrite
> > tx_sw_if_index 8 dpo-idx 4 : ipv4 via 10.10.10.205
> GigabitEthernet3/0/0.1:
> > 00505692236500505692607f810000010800 flow hash: 0x00000000 00000000:
> > 00505692236500505692607f8100000108004500003cc74c40003f0636b71414
> > 00000020: 14ce0a0a0acda1ce005078240ff800000000a0027210883300000204
> > 02:40:19:336607: acl-plugin-out-ip4-fa acl-plugin: sw_if_index 8, next
> > index 0, action: 0, match: acl 1 rule 0 trace_bits 00000000 pkt info
> > 0000000000000000 b736063f00000000 0000000000000000 ce14141400000000
> > 0000004c00000000 0000000000000800 02:40:19:336612: error-drop
> > acl-plugin-out-ip4-fa: ACL deny packets Packet 4 02:40:21:371646:
> > dpdk-input GigabitEthernetb/0/0 rx queue 0 buffer 0x1d1e1: current
> data
> > 0, length 60, free-list 0, clone-count 0, totlen-nifb 0, trace 0x3 PKT
> > MBUF: port 1, nb_segs 1, pkt_len 60 buf_len 2176, data_len 60,
> ol_flags
> > 0x0, data_off 128, phys_addr 0x5c143740 packet_type 0x0 ARP:
> > 00:50:56:92:ce:1f -> 00:50:56:92:8e:b1 request, type ethernet/IP4,
> > address size 6/4 00:50:56:92:ce:1f/20.20.20.206 <http://20.20.20.206>
> ->
> > 00:00:00:00:00:00/20.20.20.208 <http://20.20.20.208> 02:40:21:371663:
> > ethernet-input ARP: 00:50:56:92:ce:1f -> 00:50:56:92:8e:b1
> > 02:40:21:371673: arp-input request, type ethernet/IP4, address size 6/4
> > 00:50:56:92:ce:1f/20.20.20.206 <http://20.20.20.206> ->
> > 00:00:00:00:00:00/20.20.20.208 <http://20.20.20.208> 02:40:21:371779:
> > GigabitEthernetb/0/0-output GigabitEthernetb/0/0 ARP:
> 00:50:56:92:8e:b1
> > -> 00:50:56:92:ce:1f reply, type ethernet/IP4, address size 6/4
> > 00:50:56:92:8e:b1/20.20.20.208 <http://20.20.20.208> ->
> > 00:50:56:92:ce:1f/20.20.20.206 <http://20.20.20.206> 02:40:21:371781:
> > GigabitEthernetb/0/0-tx GigabitEthernetb/0/0 tx queue 0 buffer
> 0x1d1e1:
> > current data 0, length 60, free-list 0, clone-count 0, totlen-nifb 0,
> trace
> > 0x3 ARP: 00:50:56:92:8e:b1 -> 00:50:56:92:ce:1f reply, type
> > ethernet/IP4, address size 6/4 00:50:56:92:8*
> >
> >
> >
> > *e:b1/20.20.20.208 <http://20.20.20.208> -> 00:50:56:92:ce:1f/
> 20.20.20.206
> > <http://20.20.20.206> As regards to my configuration, I expected packets
> > 1,2,3 to be matched with acl 2 and to be permitted but they were matched
> > with acl 1 and dropped. It seems that setting acl on subif caused this
> > problem and there is incompatibility between ACL plugin and
> subinterfaces*
> >
> > *Thanks*
> >
> >
> > *Regards*
> >
> >
> >
> >
> > On Mon, Jun 19, 2017 at 5:13 PM, Andrew Yourtchenko <ayour...@gmail.com>
> > wrote:
> >
> >> 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
