[vpp-dev] ACL drops while pinging another interface
Hi guys, I’m using VPP 19.08 with networking-vpp in an openstack stein environment, where we are busy building an open environment that is specifically built for NFV applications. One of those functions is a firewall setup, where we firewall a customer’s traffic and provide said customer with a ‘clean and safe’ internet connection. As such, I am evaluating a VPP setup, which looks very promising. However: in the following scenario, I run into an issue: I have a compute host on which I have a firewall running ánd a guest (cirros for now). Setup is as follows: 145.144.1.53-fa:16:3e:7c:96:d0 – VirtualEthernet0/0/2 | firewall instance | VirtualEthernet0/03 145.144.1.78 - fa:16:3e:26:3e:0e <–> vlan 69 <–> 145.144.1.84 - fa:16:3e:93:0c:50- VirtualEthernet0/0/4 | cirros instance | From the cirros instance pingin the inside interface of the firewall (0/0/3) works like a charm, I wouldn’t have expected any different. When I try to ping the outside interface of the firewall (0/0/2), traces show the following: 0:53:47:316205: vhost-user-input VirtualEthernet0/0/4 queue 0 virtio flags: INDIRECT Indirect descriptor virtio_net_hdr first_desc_len 12 flags 0x00 gso_type 0 num_buff 0 00:53:47:316208: ethernet-input frame: flags 0x1, hw-if-index 7, sw-if-index 10 IP4: fa:16:3e:93:0c:50 -> fa:16:3e:26:3e:0e 00:53:47:316209: l2-input l2-input: sw_if_index 10 dst fa:16:3e:26:3e:0e src fa:16:3e:93:0c:50 00:53:47:316210: l2-input-feat-arc IN-FEAT-ARC: head 1 feature_bitmap 500525 ethertype 800 sw_if_index 10, next_index 22 00:53:47:316211: acl-plugin-in-ip4-l2 acl-plugin: lc_index: -1, sw_if_index 10, next index 1, action: 3, match: acl -1 rule 44 trace_bits 8000 pkt info 3501909154019091 000a03010008 0200 lc_index 0 l3 ip4 145.144.1.84 -> 145.144.1.53 l4 lsb_of_sw_if_index 10 proto 1 l4_is_input 1 l4_slow_path 1 l4_flags 0x03 port 8 -> 0 tcp flags (invalid) 00 rsvd 0 00:53:47:316214: l2-input-feat-arc-end IN-FEAT-ARC: head 0 feature_bitmap 100525 ethertype 0 sw_if_index -1, next_index 17 00:53:47:316215: l2-input-acl INACL: sw_if_index 10, next_index 9, table 41, offset 1392 00:53:47:316216: l2-learn l2-learn: sw_if_index 10 dst fa:16:3e:26:3e:0e src fa:16:3e:93:0c:50 bd_index 3 00:53:47:316218: l2-fwd l2-fwd: sw_if_index 10 dst fa:16:3e:26:3e:0e src fa:16:3e:93:0c:50 bd_index 3 result [0x5d509, 9] none 00:53:47:316219: l2-output l2-output: sw_if_index 9 dst fa:16:3e:26:3e:0e src fa:16:3e:93:0c:50 data 08 00 45 00 00 54 33 9c 40 00 40 01 00:53:47:316220: l2-output-feat-arc OUT-FEAT-ARC: head 1 feature_bitmap 4001 ethertype 800 sw_if_index 9, next_index 11 00:53:47:316220: acl-plugin-out-ip4-l2 acl-plugin: lc_index: 6, sw_if_index 9, next index 1, action: 1, match: acl 4 rule 2 trace_bits pkt info 3501909154019091 000902010008 02000006 lc_index 6 l3 ip4 145.144.1.84 -> 145.144.1.53 l4 lsb_of_sw_if_index 9 proto 1 l4_is_input 0 l4_slow_path 1 l4_flags 0x02 port 8 -> 0 tcp flags (invalid) 00 rsvd 0 00:53:47:316223: l2-output-feat-arc-end OUT-FEAT-ARC: head 0 feature_bitmap 1 ethertype 0 sw_if_index -1, next_index 0 00:53:47:316224: VirtualEthernet0/0/3-output VirtualEthernet0/0/3 l2_hdr_offset_valid l3_hdr_offset_valid IP4: fa:16:3e:93:0c:50 -> fa:16:3e:26:3e:0e ICMP: 145.144.1.84 -> 145.144.1.53 tos 0x00, ttl 64, length 84, checksum 0xe163 fragment id 0x339c, flags DONT_FRAGMENT ICMP echo_request checksum 0x9914 00:53:47:316225: VirtualEthernet0/0/3-tx VirtualEthernet0/0/3 queue 0 virtio flags: SINGLE_DESC Single descriptor packet virtio_net_hdr first_desc_len 4096 flags 0x00 gso_type 0 num_buff 1 Packet 3 00:53:47:316357: vhost-user-input VirtualEthernet0/0/3 queue 0 virtio flags: INDIRECT Indirect descriptor virtio_net_hdr first_desc_len 12 flags 0x00 gso_type 0 num_buff 0 00:53:47:316358: ethernet-input frame: flags 0x1, hw-if-index 6, sw-if-index 9 IP4: fa:16:3e:26:3e:0e -> fa:16:3e:93:0c:50 00:53:47:316358: l2-input l2-input: sw_if_index 9 dst fa:16:3e:93:0c:50 src fa:16:3e:26:3e:0e 00:53:47:316359: l2-input-feat-arc IN-FEAT-ARC: head 1 feature_bitmap 500525 ethertype 800 sw_if_index 9, next_index 22 00:53:47:316359: acl-plugin-in-ip4-l2 acl-plugin: lc_index: -1, sw_if_index 9, next index 1, action: 3, match: acl -1 rule 97 trace_bits 8000 pkt info 5401909135019091 00090301 0200 lc_index 0 l3 ip4 145.144.1.53 -> 145.144.1.84 l4 lsb_of_sw_if_index 9 proto 1 l4_is_input 1 l4_slow_path 1 l4_flags 0x03 port 0 -> 0 tcp flags (invalid) 00 rsvd 0 00:53:47:316359: l2-input-feat-arc-end IN-FEAT-ARC: head 0 feature_bitmap 100525 ethertype 0 sw_if_index -1, nex
Re: [vpp-dev] ACL drops while pinging another interface
Thanks for the traces ! MACIP acl uses the classifier-bases “ip-acl”; so it sounds like it is not programmed with the source Mac of your packets. “Show acl-plugin macip” will help to see what the acl plugin sees, and if it looks legit, then you can check the classifier tables applied as input acl to verify those are programmed correctly. Shout if you get stuck :) --a > On 5 Sep 2019, at 14:18, Eyle Brinkhuis wrote: > > Hi guys, > > I’m using VPP 19.08 with networking-vpp in an openstack stein environment, > where we are busy building an open environment that is specifically built for > NFV applications. One of those functions is a firewall setup, where we > firewall a customer’s traffic and provide said customer with a ‘clean and > safe’ internet connection. > > As such, I am evaluating a VPP setup, which looks very promising. However: in > the following scenario, I run into an issue: > > I have a compute host on which I have a firewall running ánd a guest (cirros > for now). Setup is as follows: > > 145.144.1.53-fa:16:3e:7c:96:d0 – VirtualEthernet0/0/2 | firewall instance | > VirtualEthernet0/03 145.144.1.78 - fa:16:3e:26:3e:0e <–> vlan 69 <–> > 145.144.1.84 - fa:16:3e:93:0c:50- VirtualEthernet0/0/4 | cirros instance | > > From the cirros instance pingin the inside interface of the firewall (0/0/3) > works like a charm, I wouldn’t have expected any different. > > When I try to ping the outside interface of the firewall (0/0/2), traces show > the following: > > 0:53:47:316205: vhost-user-input > VirtualEthernet0/0/4 queue 0 >virtio flags: > INDIRECT Indirect descriptor >virtio_net_hdr first_desc_len 12 > flags 0x00 gso_type 0 > num_buff 0 > 00:53:47:316208: ethernet-input > frame: flags 0x1, hw-if-index 7, sw-if-index 10 > IP4: fa:16:3e:93:0c:50 -> fa:16:3e:26:3e:0e > 00:53:47:316209: l2-input > l2-input: sw_if_index 10 dst fa:16:3e:26:3e:0e src fa:16:3e:93:0c:50 > 00:53:47:316210: l2-input-feat-arc > IN-FEAT-ARC: head 1 feature_bitmap 500525 ethertype 800 sw_if_index 10, > next_index 22 > 00:53:47:316211: acl-plugin-in-ip4-l2 > acl-plugin: lc_index: -1, sw_if_index 10, next index 1, action: 3, match: > acl -1 rule 44 trace_bits 8000 > pkt info > 3501909154019091 000a03010008 0200 >lc_index 0 l3 ip4 145.144.1.84 -> 145.144.1.53 l4 lsb_of_sw_if_index 10 > proto 1 l4_is_input 1 l4_slow_path 1 l4_flags 0x03 port 8 -> 0 tcp flags > (invalid) 00 rsvd 0 > 00:53:47:316214: l2-input-feat-arc-end > IN-FEAT-ARC: head 0 feature_bitmap 100525 ethertype 0 sw_if_index -1, > next_index 17 > 00:53:47:316215: l2-input-acl > INACL: sw_if_index 10, next_index 9, table 41, offset 1392 > 00:53:47:316216: l2-learn > l2-learn: sw_if_index 10 dst fa:16:3e:26:3e:0e src fa:16:3e:93:0c:50 > bd_index 3 > 00:53:47:316218: l2-fwd > l2-fwd: sw_if_index 10 dst fa:16:3e:26:3e:0e src fa:16:3e:93:0c:50 > bd_index 3 result [0x5d509, 9] none > 00:53:47:316219: l2-output > l2-output: sw_if_index 9 dst fa:16:3e:26:3e:0e src fa:16:3e:93:0c:50 data > 08 00 45 00 00 54 33 9c 40 00 40 01 > 00:53:47:316220: l2-output-feat-arc > OUT-FEAT-ARC: head 1 feature_bitmap 4001 ethertype 800 sw_if_index 9, > next_index 11 > 00:53:47:316220: acl-plugin-out-ip4-l2 > acl-plugin: lc_index: 6, sw_if_index 9, next index 1, action: 1, match: acl > 4 rule 2 trace_bits > pkt info > 3501909154019091 000902010008 02000006 >lc_index 6 l3 ip4 145.144.1.84 -> 145.144.1.53 l4 lsb_of_sw_if_index 9 > proto 1 l4_is_input 0 l4_slow_path 1 l4_flags 0x02 port 8 -> 0 tcp flags > (invalid) 00 rsvd 0 > 00:53:47:316223: l2-output-feat-arc-end > OUT-FEAT-ARC: head 0 feature_bitmap 1 ethertype 0 sw_if_index -1, > next_index 0 > 00:53:47:316224: VirtualEthernet0/0/3-output > VirtualEthernet0/0/3 l2_hdr_offset_valid l3_hdr_offset_valid > IP4: fa:16:3e:93:0c:50 -> fa:16:3e:26:3e:0e > ICMP: 145.144.1.84 -> 145.144.1.53 > tos 0x00, ttl 64, length 84, checksum 0xe163 > fragment id 0x339c, flags DONT_FRAGMENT > ICMP echo_request checksum 0x9914 > 00:53:47:316225: VirtualEthernet0/0/3-tx > VirtualEthernet0/0/3 queue 0 >virtio flags: > SINGLE_DESC Single descriptor packet >virtio_net_hdr first_desc_len 4096 > flags 0x00 gso_type 0 > num_buff 1 > > Packet 3 > > 00:53:47:316357: vhost-user-input > VirtualEthernet0/0/3 queue 0 >virtio flags: > INDIRECT Indirect descriptor >virtio_net_hdr first_desc_len 12 > flags 0x00 gso_type 0 > num_buff 0 > 00:53:47:316358: ethernet-input > frame: flags 0x1, hw-if-index 6, sw-if-index 9 > IP4: fa:16:3e:26:3e:0e -> fa:16:3e:93:0c:50 > 00:53:47:316358: l2-input > l2-input: sw_if_index 9 dst fa:16:3e:93:0c:50 src fa:16:3e:26:3e:0e > 00:53:47:316359: l2-input-feat-arc > IN-FEAT-ARC: head 1 feature_bitmap 500525 ethertype
Re: [vpp-dev] ACL drops while pinging another interface
From the trace, it appears like ICMP Echo reply is not permitted by the security-group applied on neutron’s port corresponding to VirtualEthernet0/0/3. This could be causing the ICMP reply packet from the firewall to drop. lc_index 0 l3 ip4 145.144.1.53 -> 145.144.1.84 l4 lsb_of_sw_if_index 9 proto 1 l4_is_input 1 l4_slow_path 1 l4_flags 0x03 port 0 -> 0 tcp flags (invalid) 00 rsvd 0 00:53:47:316359: l2-input-feat-arc-end IN-FEAT-ARC: head 0 feature_bitmap 100525 ethertype 0 sw_if_index -1, next_index 17 00:53:47:316360: l2-input-acl INACL: sw_if_index 9, next_index 0, table 12, offset -1 00:53:47:316361: error-drop rx:VirtualEthernet0/0/3 -Naveen From: on behalf of Andrew Yourtchenko Date: Thursday, September 5, 2019 at 7:20 AM To: Eyle Brinkhuis Cc: "vpp-dev@lists.fd.io" Subject: Re: [vpp-dev] ACL drops while pinging another interface Thanks for the traces ! MACIP acl uses the classifier-bases “ip-acl”; so it sounds like it is not programmed with the source Mac of your packets. “Show acl-plugin macip” will help to see what the acl plugin sees, and if it looks legit, then you can check the classifier tables applied as input acl to verify those are programmed correctly. Shout if you get stuck :) --a On 5 Sep 2019, at 14:18, Eyle Brinkhuis mailto:eyle.brinkh...@surfnet.nl>> wrote: Hi guys, I’m using VPP 19.08 with networking-vpp in an openstack stein environment, where we are busy building an open environment that is specifically built for NFV applications. One of those functions is a firewall setup, where we firewall a customer’s traffic and provide said customer with a ‘clean and safe’ internet connection. As such, I am evaluating a VPP setup, which looks very promising. However: in the following scenario, I run into an issue: I have a compute host on which I have a firewall running ánd a guest (cirros for now). Setup is as follows: 145.144.1.53-fa:16:3e:7c:96:d0 – VirtualEthernet0/0/2 | firewall instance | VirtualEthernet0/03 145.144.1.78 - fa:16:3e:26:3e:0e <–> vlan 69 <–> 145.144.1.84 - fa:16:3e:93:0c:50- VirtualEthernet0/0/4 | cirros instance | From the cirros instance pingin the inside interface of the firewall (0/0/3) works like a charm, I wouldn’t have expected any different. When I try to ping the outside interface of the firewall (0/0/2), traces show the following: 0:53:47:316205: vhost-user-input VirtualEthernet0/0/4 queue 0 virtio flags: INDIRECT Indirect descriptor virtio_net_hdr first_desc_len 12 flags 0x00 gso_type 0 num_buff 0 00:53:47:316208: ethernet-input frame: flags 0x1, hw-if-index 7, sw-if-index 10 IP4: fa:16:3e:93:0c:50 -> fa:16:3e:26:3e:0e 00:53:47:316209: l2-input l2-input: sw_if_index 10 dst fa:16:3e:26:3e:0e src fa:16:3e:93:0c:50 00:53:47:316210: l2-input-feat-arc IN-FEAT-ARC: head 1 feature_bitmap 500525 ethertype 800 sw_if_index 10, next_index 22 00:53:47:316211: acl-plugin-in-ip4-l2 acl-plugin: lc_index: -1, sw_if_index 10, next index 1, action: 3, match: acl -1 rule 44 trace_bits 8000 pkt info 3501909154019091 000a03010008 0200 lc_index 0 l3 ip4 145.144.1.84 -> 145.144.1.53 l4 lsb_of_sw_if_index 10 proto 1 l4_is_input 1 l4_slow_path 1 l4_flags 0x03 port 8 -> 0 tcp flags (invalid) 00 rsvd 0 00:53:47:316214: l2-input-feat-arc-end IN-FEAT-ARC: head 0 feature_bitmap 100525 ethertype 0 sw_if_index -1, next_index 17 00:53:47:316215: l2-input-acl INACL: sw_if_index 10, next_index 9, table 41, offset 1392 00:53:47:316216: l2-learn l2-learn: sw_if_index 10 dst fa:16:3e:26:3e:0e src fa:16:3e:93:0c:50 bd_index 3 00:53:47:316218: l2-fwd l2-fwd: sw_if_index 10 dst fa:16:3e:26:3e:0e src fa:16:3e:93:0c:50 bd_index 3 result [0x5d509, 9] none 00:53:47:316219: l2-output l2-output: sw_if_index 9 dst fa:16:3e:26:3e:0e src fa:16:3e:93:0c:50 data 08 00 45 00 00 54 33 9c 40 00 40 01 00:53:47:316220: l2-output-feat-arc OUT-FEAT-ARC: head 1 feature_bitmap 4001 ethertype 800 sw_if_index 9, next_index 11 00:53:47:316220: acl-plugin-out-ip4-l2 acl-plugin: lc_index: 6, sw_if_index 9, next index 1, action: 1, match: acl 4 rule 2 trace_bits pkt info 3501909154019091 000902010008 02000006 lc_index 6 l3 ip4 145.144.1.84 -> 145.144.1.53 l4 lsb_of_sw_if_index 9 proto 1 l4_is_input 0 l4_slow_path 1 l4_flags 0x02 port 8 -> 0 tcp flags (invalid) 00 rsvd 0 00:53:47:316223: l2-output-feat-arc-end OUT-FEAT-ARC: head 0 feature_bitmap 1 ethertype 0 sw_if_index -1, next_index 0 00:53:47:316224: VirtualEthernet0/0/3-output VirtualEthernet0/0/3 l2_hdr_offset_valid l3_hdr_offset_valid IP4: fa:16:3e:93:0c:50 -> fa:16:3e:26:3e:0e ICMP: 145.144.1.84 -> 145.144.1.53 tos 0x00, ttl 64, length 84, checksum 0xe163 fragment id 0x339c, flags DO
Re: [vpp-dev] ACL drops while pinging another interface
It hits the session, so it does pass the L3 acl. Just before ... --a > On 5 Sep 2019, at 18:52, Naveen Joy (najoy) wrote: > > From the trace, it appears like ICMP Echo reply is not permitted by the > security-group applied on neutron’s port corresponding to > VirtualEthernet0/0/3. > This could be causing the ICMP reply packet from the firewall to drop. >lc_index 0 l3 ip4 145.144.1.53 -> 145.144.1.84 l4 lsb_of_sw_if_index 9 > proto 1 l4_is_input 1 l4_slow_path 1 l4_flags 0x03 port 0 -> 0 tcp flags > (invalid) 00 rsvd 0 > 00:53:47:316359: l2-input-feat-arc-end > IN-FEAT-ARC: head 0 feature_bitmap 100525 ethertype 0 sw_if_index -1, > next_index 17 > 00:53:47:316360: l2-input-acl > INACL: sw_if_index 9, next_index 0, table 12, offset -1 > 00:53:47:316361: error-drop > rx:VirtualEthernet0/0/3 > > -Naveen > > From: on behalf of Andrew Yourtchenko > > Date: Thursday, September 5, 2019 at 7:20 AM > To: Eyle Brinkhuis > Cc: "vpp-dev@lists.fd.io" > Subject: Re: [vpp-dev] ACL drops while pinging another interface > > Thanks for the traces ! > > MACIP acl uses the classifier-bases “ip-acl”; so it sounds like it is not > programmed with the source Mac of your packets. > > “Show acl-plugin macip” will help to see what the acl plugin sees, and if it > looks legit, then you can check the classifier tables applied as input acl to > verify those are programmed correctly. > > Shout if you get stuck :) > > --a > > On 5 Sep 2019, at 14:18, Eyle Brinkhuis wrote: > > Hi guys, > > I’m using VPP 19.08 with networking-vpp in an openstack stein environment, > where we are busy building an open environment that is specifically built for > NFV applications. One of those functions is a firewall setup, where we > firewall a customer’s traffic and provide said customer with a ‘clean and > safe’ internet connection. > > As such, I am evaluating a VPP setup, which looks very promising. However: in > the following scenario, I run into an issue: > > I have a compute host on which I have a firewall running ánd a guest (cirros > for now). Setup is as follows: > > 145.144.1.53-fa:16:3e:7c:96:d0 – VirtualEthernet0/0/2 | firewall instance | > VirtualEthernet0/03 145.144.1.78 - fa:16:3e:26:3e:0e <–> vlan 69 <–> > 145.144.1.84 - fa:16:3e:93:0c:50- VirtualEthernet0/0/4 | cirros instance | > > From the cirros instance pingin the inside interface of the firewall (0/0/3) > works like a charm, I wouldn’t have expected any different. > > When I try to ping the outside interface of the firewall (0/0/2), traces show > the following: > > 0:53:47:316205: vhost-user-input > VirtualEthernet0/0/4 queue 0 >virtio flags: > INDIRECT Indirect descriptor >virtio_net_hdr first_desc_len 12 > flags 0x00 gso_type 0 > num_buff 0 > 00:53:47:316208: ethernet-input > frame: flags 0x1, hw-if-index 7, sw-if-index 10 > IP4: fa:16:3e:93:0c:50 -> fa:16:3e:26:3e:0e > 00:53:47:316209: l2-input > l2-input: sw_if_index 10 dst fa:16:3e:26:3e:0e src fa:16:3e:93:0c:50 > 00:53:47:316210: l2-input-feat-arc > IN-FEAT-ARC: head 1 feature_bitmap 500525 ethertype 800 sw_if_index 10, > next_index 22 > 00:53:47:316211: acl-plugin-in-ip4-l2 > acl-plugin: lc_index: -1, sw_if_index 10, next index 1, action: 3, match: > acl -1 rule 44 trace_bits 8000 > pkt info > 3501909154019091 000a03010008 0200 >lc_index 0 l3 ip4 145.144.1.84 -> 145.144.1.53 l4 lsb_of_sw_if_index 10 > proto 1 l4_is_input 1 l4_slow_path 1 l4_flags 0x03 port 8 -> 0 tcp flags > (invalid) 00 rsvd 0 > 00:53:47:316214: l2-input-feat-arc-end > IN-FEAT-ARC: head 0 feature_bitmap 100525 ethertype 0 sw_if_index -1, > next_index 17 > 00:53:47:316215: l2-input-acl > INACL: sw_if_index 10, next_index 9, table 41, offset 1392 > 00:53:47:316216: l2-learn > l2-learn: sw_if_index 10 dst fa:16:3e:26:3e:0e src fa:16:3e:93:0c:50 > bd_index 3 > 00:53:47:316218: l2-fwd > l2-fwd: sw_if_index 10 dst fa:16:3e:26:3e:0e src fa:16:3e:93:0c:50 > bd_index 3 result [0x5d509, 9] none > 00:53:47:316219: l2-output > l2-output: sw_if_index 9 dst fa:16:3e:26:3e:0e src fa:16:3e:93:0c:50 data > 08 00 45 00 00 54 33 9c 40 00 40 01 > 00:53:47:316220: l2-output-feat-arc > OUT-FEAT-ARC: head 1 feature_bitmap 4001 ethertype 800 sw_if_index 9, > next_index 11 > 00:53:47:316220: acl-plugin-out-ip4-l2 > acl-plugin: lc_index: 6, sw_if_index 9, next index 1, action: 1, match: acl > 4 rule 2 trace_bits > pkt info > 3501909154019091 000902010
Re: [vpp-dev] ACL drops while pinging another interface
Okay.. so when I pull up the macip acl’s:
vpp# show acl-plugin macip acl
MACIP acl_index: 0, count: 2 (true len 2) tag {} is free pool slot: 0
ip4_table_index 5, ip6_table_index 5, l2_table_index 5
out_ip4_table_index -1, out_ip6_table_index -1, out_l2_table_index -1
rule 0: ipv4 action 1 ip 0.0.0.0/32 mac fa:16:3e:79:87:05 mask
ff:ff:ff:ff:ff:ff
rule 1: ipv4 action 1 ip 145.144.1.5/32 mac fa:16:3e:79:87:05 mask
ff:ff:ff:ff:ff:ff
applied on sw_if_index(s):
MACIP acl_index: 1, count: 2 (true len 2) tag {} is free pool slot: 0
ip4_table_index 11, ip6_table_index 11, l2_table_index 11
out_ip4_table_index -1, out_ip6_table_index -1, out_l2_table_index -1
rule 0: ipv4 action 1 ip 0.0.0.0/32 mac fa:16:3e:79:87:05 mask
ff:ff:ff:ff:ff:ff
rule 1: ipv4 action 1 ip 145.144.1.5/32 mac fa:16:3e:79:87:05 mask
ff:ff:ff:ff:ff:ff
applied on sw_if_index(s): 4
MACIP acl_index: 2, count: 2 (true len 2) tag {} is free pool slot: 0
ip4_table_index 17, ip6_table_index 17, l2_table_index 17
out_ip4_table_index -1, out_ip6_table_index -1, out_l2_table_index -1
rule 0: ipv4 action 1 ip 0.0.0.0/32 mac fa:16:3e:26:3e:0e mask
ff:ff:ff:ff:ff:ff
rule 1: ipv4 action 1 ip 145.144.1.78/32 mac fa:16:3e:26:3e:0e mask
ff:ff:ff:ff:ff:ff
applied on sw_if_index(s): 9
MACIP acl_index: 3, count: 2 (true len 2) tag {} is free pool slot: 0
ip4_table_index 23, ip6_table_index 23, l2_table_index 23
out_ip4_table_index -1, out_ip6_table_index -1, out_l2_table_index -1
rule 0: ipv4 action 1 ip 0.0.0.0/32 mac fa:16:3e:10:04:3e mask
ff:ff:ff:ff:ff:ff
rule 1: ipv4 action 1 ip 145.144.1.29/32 mac fa:16:3e:10:04:3e mask
ff:ff:ff:ff:ff:ff
applied on sw_if_index(s): 5
MACIP acl_index: 4, count: 2 (true len 2) tag {} is free pool slot: 0
ip4_table_index 29, ip6_table_index 29, l2_table_index 29
out_ip4_table_index -1, out_ip6_table_index -1, out_l2_table_index -1
rule 0: ipv4 action 1 ip 0.0.0.0/32 mac fa:16:3e:7c:96:d0 mask
ff:ff:ff:ff:ff:ff
rule 1: ipv4 action 1 ip 145.144.1.53/32 mac fa:16:3e:7c:96:d0 mask
ff:ff:ff:ff:ff:ff
applied on sw_if_index(s): 7
MACIP acl_index: 6, count: 2 (true len 2) tag {} is free pool slot: 0
ip4_table_index 41, ip6_table_index 41, l2_table_index 41
out_ip4_table_index -1, out_ip6_table_index -1, out_l2_table_index -1
rule 0: ipv4 action 1 ip 0.0.0.0/32 mac fa:16:3e:93:0c:50 mask
ff:ff:ff:ff:ff:ff
rule 1: ipv4 action 1 ip 145.144.1.84/32 mac fa:16:3e:93:0c:50 mask
ff:ff:ff:ff:ff:ff
applied on sw_if_index(s): 10
But then compare that to the show hardware:
vpp# sh hard
NameIdx Link Hardware
VirtualEthernet0/0/0 3 up VirtualEthernet0/0/0
Link speed: unknown
Ethernet address fa:16:3c:c9:a8:50
VirtualEthernet0/0/1 4 up VirtualEthernet0/0/1
Link speed: unknown
Ethernet address fa:16:3c:70:15:b3
VirtualEthernet0/0/2 5 up VirtualEthernet0/0/2
Link speed: unknown
Ethernet address fa:16:3c:05:66:7c
VirtualEthernet0/0/3 6 up VirtualEthernet0/0/3
Link speed: unknown
Ethernet address fa:16:3c:f0:21:0a
VirtualEthernet0/0/4 7 up VirtualEthernet0/0/4
Link speed: unknown
Ethernet address fa:16:3c:0f:9d:5d
local0 0down local0
Link speed: unknown
local
rdma0 1 up rdma0
Link speed: 40 Gbps
Ethernet address 02:fe:99:32:82:4f
flags: admin-up promiscuous
rdma1 2 up rdma1
Link speed: 40 Gbps
Ethernet address 02:fe:27:ea:09:82
flags: admin-up
It looks like there doesn’t even exist an acl for VirtualEthernet0/0/3? Is that
why it is dropped?
Eyle
From: Andrew 👽 Yourtchenko
Date: Thursday, 5 September 2019 at 19:20
To: "Naveen Joy (najoy)"
Cc: Eyle Brinkhuis , "vpp-dev@lists.fd.io"
Subject: Re: [vpp-dev] ACL drops while pinging another interface
It hits the session, so it does pass the L3 acl. Just before ...
--a
On 5 Sep 2019, at 18:52, Naveen Joy (najoy)
mailto:na...@cisco.com>> wrote:
From the trace, it appears like ICMP Echo reply is not permitted by the
security-group applied on neutron’s port corresponding to VirtualEthernet0/0/3.
This could be causing the ICMP reply packet from the firewall to drop.
lc_index 0 l3 ip4 145.144.1.53 -> 145.144.1.84 l4 lsb_of_sw_if_index 9 proto
1 l4_is_input 1 l4_slow_path 1 l4_flags 0x03 port 0 -> 0 tcp flags (invalid) 00
rsvd 0
00:53:47:316359: l2-input-feat-arc-end
IN-FEAT-ARC: head 0 feature_bitmap 100525 ethertype 0 sw_if_index -1,
next_index 17
00:53:47:316360: l2-input-acl
INACL: sw_if_index 9, next_index 0, table 12, offset -1
00:53:47:316361: error-drop
rx:VirtualEthernet0/0/3
-Naveen
From: mailto:vpp-dev@lists.fd.io>> on behalf of Andrew
Yourtchenko mailto:ayour...@gmail.com>>
Date: Thursday, September 5, 2019 at 7:20 AM
To: Eyle Brinkhuis mailto:eyle.brinkh...@surf
Re: [vpp-dev] ACL drops while pinging another interface
_ip6_table_index -1, out_l2_table_index -1
> rule 0: ipv4 action 1 ip 0.0.0.0/32 mac fa:16:3e:10:04:3e mask
> ff:ff:ff:ff:ff:ff
> rule 1: ipv4 action 1 ip 145.144.1.29/32 mac fa:16:3e:10:04:3e mask
> ff:ff:ff:ff:ff:ff
> applied on sw_if_index(s): 5
> MACIP acl_index: 4, count: 2 (true len 2) tag {} is free pool slot: 0
> ip4_table_index 29, ip6_table_index 29, l2_table_index 29
> out_ip4_table_index -1, out_ip6_table_index -1, out_l2_table_index -1
> rule 0: ipv4 action 1 ip 0.0.0.0/32 mac fa:16:3e:7c:96:d0 mask
> ff:ff:ff:ff:ff:ff
> rule 1: ipv4 action 1 ip 145.144.1.53/32 mac fa:16:3e:7c:96:d0 mask
> ff:ff:ff:ff:ff:ff
> applied on sw_if_index(s): 7
> MACIP acl_index: 6, count: 2 (true len 2) tag {} is free pool slot: 0
> ip4_table_index 41, ip6_table_index 41, l2_table_index 41
> out_ip4_table_index -1, out_ip6_table_index -1, out_l2_table_index -1
> rule 0: ipv4 action 1 ip 0.0.0.0/32 mac fa:16:3e:93:0c:50 mask
> ff:ff:ff:ff:ff:ff
> rule 1: ipv4 action 1 ip 145.144.1.84/32 mac fa:16:3e:93:0c:50 mask
> ff:ff:ff:ff:ff:ff
> applied on sw_if_index(s): 10
>
>
>
> But then compare that to the show hardware:
> vpp# sh hard
> NameIdx Link Hardware
> VirtualEthernet0/0/0 3 up VirtualEthernet0/0/0
> Link speed: unknown
> Ethernet address fa:16:3c:c9:a8:50
> VirtualEthernet0/0/1 4 up VirtualEthernet0/0/1
> Link speed: unknown
> Ethernet address fa:16:3c:70:15:b3
> VirtualEthernet0/0/2 5 up VirtualEthernet0/0/2
> Link speed: unknown
> Ethernet address fa:16:3c:05:66:7c
> VirtualEthernet0/0/3 6 up VirtualEthernet0/0/3
> Link speed: unknown
> Ethernet address fa:16:3c:f0:21:0a
> VirtualEthernet0/0/4 7 up VirtualEthernet0/0/4
> Link speed: unknown
> Ethernet address fa:16:3c:0f:9d:5d
> local0 0down local0
> Link speed: unknown
> local
> rdma0 1 up rdma0
> Link speed: 40 Gbps
> Ethernet address 02:fe:99:32:82:4f
> flags: admin-up promiscuous
> rdma1 2 up rdma1
> Link speed: 40 Gbps
> Ethernet address 02:fe:27:ea:09:82
> flags: admin-up
>
> It looks like there doesn’t even exist an acl for VirtualEthernet0/0/3? Is
> that why it is dropped?
>
> Eyle
>
> From: Andrew 👽 Yourtchenko
> Date: Thursday, 5 September 2019 at 19:20
> To: "Naveen Joy (najoy)"
> Cc: Eyle Brinkhuis , "vpp-dev@lists.fd.io"
>
> Subject: Re: [vpp-dev] ACL drops while pinging another interface
>
> It hits the session, so it does pass the L3 acl. Just before ...
> --a
>
> On 5 Sep 2019, at 18:52, Naveen Joy (najoy)
> mailto:na...@cisco.com>> wrote:
> From the trace, it appears like ICMP Echo reply is not permitted by the
> security-group applied on neutron’s port corresponding to
> VirtualEthernet0/0/3.
> This could be causing the ICMP reply packet from the firewall to drop.
>
>lc_index 0 l3 ip4 145.144.1.53 -> 145.144.1.84 l4 lsb_of_sw_if_index 9
> proto 1 l4_is_input 1 l4_slow_path 1 l4_flags 0x03 port 0 -> 0 tcp flags
> (invalid) 00 rsvd 0
>
> 00:53:47:316359: l2-input-feat-arc-end
>
> IN-FEAT-ARC: head 0 feature_bitmap 100525 ethertype 0 sw_if_index -1,
> next_index 17
>
> 00:53:47:316360: l2-input-acl
>
> INACL: sw_if_index 9, next_index 0, table 12, offset -1
>
> 00:53:47:316361: error-drop
>
> rx:VirtualEthernet0/0/3
>
> -Naveen
>
> From: mailto:vpp-dev@lists.fd.io>> on behalf of Andrew
> Yourtchenko mailto:ayour...@gmail.com>>
> Date: Thursday, September 5, 2019 at 7:20 AM
> To: Eyle Brinkhuis
> mailto:eyle.brinkh...@surfnet.nl>>
> Cc: "vpp-dev@lists.fd.io<mailto:vpp-dev@lists.fd.io>"
> mailto:vpp-dev@lists.fd.io>>
> Subject: Re: [vpp-dev] ACL drops while pinging another interface
>
> Thanks for the traces !
>
> MACIP acl uses the classifier-bases “ip-acl”; so it sounds like it is not
> programmed with the source Mac of your packets.
>
> “Show acl-plugin macip” will help to see what the acl plugin sees, and if it
> looks legit, then you can check the classifier tables applied as input acl
> to verify those are programmed correctly.
>
> Shout if you get stuck :)
>
> --a
>
> On 5 Sep 2019, at 14:18, Eyle Brinkhuis
> mailto:eyle.brinkh...@surfnet.nl>> wrote:
> Hi guys,
>
> I’m using VPP 19.08 with networking-vpp in an openstack stein environment,
> where we are busy building an open environment that is specifically built
> for NFV applications. One of those functions is a firewall setup, w
Re: [vpp-dev] ACL drops while pinging another interface
_if_index(s):
> MACIP acl_index: 1, count: 2 (true len 2) tag {} is free pool slot: 0
> ip4_table_index 11, ip6_table_index 11, l2_table_index 11
> out_ip4_table_index -1, out_ip6_table_index -1, out_l2_table_index -1
> rule 0: ipv4 action 1 ip 0.0.0.0/32 mac fa:16:3e:79:87:05 mask
> ff:ff:ff:ff:ff:ff
> rule 1: ipv4 action 1 ip 145.144.1.5/32 mac fa:16:3e:79:87:05 mask
> ff:ff:ff:ff:ff:ff
> applied on sw_if_index(s): 4
> MACIP acl_index: 2, count: 2 (true len 2) tag {} is free pool slot: 0
> ip4_table_index 17, ip6_table_index 17, l2_table_index 17
> out_ip4_table_index -1, out_ip6_table_index -1, out_l2_table_index -1
> rule 0: ipv4 action 1 ip 0.0.0.0/32 mac fa:16:3e:26:3e:0e mask
> ff:ff:ff:ff:ff:ff
> rule 1: ipv4 action 1 ip 145.144.1.78/32 mac fa:16:3e:26:3e:0e mask
> ff:ff:ff:ff:ff:ff
> applied on sw_if_index(s): 9
> MACIP acl_index: 3, count: 2 (true len 2) tag {} is free pool slot: 0
> ip4_table_index 23, ip6_table_index 23, l2_table_index 23
> out_ip4_table_index -1, out_ip6_table_index -1, out_l2_table_index -1
> rule 0: ipv4 action 1 ip 0.0.0.0/32 mac fa:16:3e:10:04:3e mask
> ff:ff:ff:ff:ff:ff
> rule 1: ipv4 action 1 ip 145.144.1.29/32 mac fa:16:3e:10:04:3e mask
> ff:ff:ff:ff:ff:ff
> applied on sw_if_index(s): 5
> MACIP acl_index: 4, count: 2 (true len 2) tag {} is free pool slot: 0
> ip4_table_index 29, ip6_table_index 29, l2_table_index 29
> out_ip4_table_index -1, out_ip6_table_index -1, out_l2_table_index -1
> rule 0: ipv4 action 1 ip 0.0.0.0/32 mac fa:16:3e:7c:96:d0 mask
> ff:ff:ff:ff:ff:ff
> rule 1: ipv4 action 1 ip 145.144.1.53/32 mac fa:16:3e:7c:96:d0 mask
> ff:ff:ff:ff:ff:ff
> applied on sw_if_index(s): 7
> MACIP acl_index: 6, count: 2 (true len 2) tag {} is free pool slot: 0
> ip4_table_index 41, ip6_table_index 41, l2_table_index 41
> out_ip4_table_index -1, out_ip6_table_index -1, out_l2_table_index -1
> rule 0: ipv4 action 1 ip 0.0.0.0/32 mac fa:16:3e:93:0c:50 mask
> ff:ff:ff:ff:ff:ff
> rule 1: ipv4 action 1 ip 145.144.1.84/32 mac fa:16:3e:93:0c:50 mask
> ff:ff:ff:ff:ff:ff
> applied on sw_if_index(s): 10
>
>
>
> But then compare that to the show hardware:
> vpp# sh hard
> NameIdx Link Hardware
> VirtualEthernet0/0/0 3 up VirtualEthernet0/0/0
> Link speed: unknown
> Ethernet address fa:16:3c:c9:a8:50
> VirtualEthernet0/0/1 4 up VirtualEthernet0/0/1
> Link speed: unknown
> Ethernet address fa:16:3c:70:15:b3
> VirtualEthernet0/0/2 5 up VirtualEthernet0/0/2
> Link speed: unknown
> Ethernet address fa:16:3c:05:66:7c
> VirtualEthernet0/0/3 6 up VirtualEthernet0/0/3
> Link speed: unknown
> Ethernet address fa:16:3c:f0:21:0a
> VirtualEthernet0/0/4 7 up VirtualEthernet0/0/4
> Link speed: unknown
> Ethernet address fa:16:3c:0f:9d:5d
> local0 0down local0
> Link speed: unknown
> local
> rdma0 1 up rdma0
> Link speed: 40 Gbps
> Ethernet address 02:fe:99:32:82:4f
> flags: admin-up promiscuous
> rdma1 2 up rdma1
> Link speed: 40 Gbps
> Ethernet address 02:fe:27:ea:09:82
> flags: admin-up
>
> It looks like there doesn’t even exist an acl for VirtualEthernet0/0/3? Is
> that why it is dropped?
>
> Eyle
>
> From: Andrew 👽 Yourtchenko
> Date: Thursday, 5 September 2019 at 19:20
> To: "Naveen Joy (najoy)"
> Cc: Eyle Brinkhuis , "vpp-dev@lists.fd.io"
>
> Subject: Re: [vpp-dev] ACL drops while pinging another interface
>
> It hits the session, so it does pass the L3 acl. Just before ...
> --a
>
> On 5 Sep 2019, at 18:52, Naveen Joy (najoy)
> mailto:na...@cisco.com>> wrote:
> From the trace, it appears like ICMP Echo reply is not permitted by the
> security-group applied on neutron’s port corresponding to
> VirtualEthernet0/0/3.
> This could be causing the ICMP reply packet from the firewall to drop.
>
>lc_index 0 l3 ip4 145.144.1.53 -> 145.144.1.84 l4 lsb_of_sw_if_index 9
> proto 1 l4_is_input 1 l4_slow_path 1 l4_flags 0x03 port 0 -> 0 tcp flags
> (invalid) 00 rsvd 0
>
> 00:53:47:316359: l2-input-feat-arc-end
>
> IN-FEAT-ARC: head
Re: [vpp-dev] ACL drops while pinging another interface
gt;> vpp# show acl-plugin macip acl
>> MACIP acl_index: 0, count: 2 (true len 2) tag {} is free pool slot: 0
>> ip4_table_index 5, ip6_table_index 5, l2_table_index 5
>> out_ip4_table_index -1, out_ip6_table_index -1, out_l2_table_index -1
>>rule 0: ipv4 action 1 ip 0.0.0.0/32 mac fa:16:3e:79:87:05 mask
>> ff:ff:ff:ff:ff:ff
>>rule 1: ipv4 action 1 ip 145.144.1.5/32 mac fa:16:3e:79:87:05 mask
>> ff:ff:ff:ff:ff:ff
>> applied on sw_if_index(s):
>> MACIP acl_index: 1, count: 2 (true len 2) tag {} is free pool slot: 0
>> ip4_table_index 11, ip6_table_index 11, l2_table_index 11
>> out_ip4_table_index -1, out_ip6_table_index -1, out_l2_table_index -1
>>rule 0: ipv4 action 1 ip 0.0.0.0/32 mac fa:16:3e:79:87:05 mask
>> ff:ff:ff:ff:ff:ff
>>rule 1: ipv4 action 1 ip 145.144.1.5/32 mac fa:16:3e:79:87:05 mask
>> ff:ff:ff:ff:ff:ff
>> applied on sw_if_index(s): 4
>> MACIP acl_index: 2, count: 2 (true len 2) tag {} is free pool slot: 0
>> ip4_table_index 17, ip6_table_index 17, l2_table_index 17
>> out_ip4_table_index -1, out_ip6_table_index -1, out_l2_table_index -1
>>rule 0: ipv4 action 1 ip 0.0.0.0/32 mac fa:16:3e:26:3e:0e mask
>> ff:ff:ff:ff:ff:ff
>>rule 1: ipv4 action 1 ip 145.144.1.78/32 mac fa:16:3e:26:3e:0e mask
>> ff:ff:ff:ff:ff:ff
>> applied on sw_if_index(s): 9
>> MACIP acl_index: 3, count: 2 (true len 2) tag {} is free pool slot: 0
>> ip4_table_index 23, ip6_table_index 23, l2_table_index 23
>> out_ip4_table_index -1, out_ip6_table_index -1, out_l2_table_index -1
>>rule 0: ipv4 action 1 ip 0.0.0.0/32 mac fa:16:3e:10:04:3e mask
>> ff:ff:ff:ff:ff:ff
>>rule 1: ipv4 action 1 ip 145.144.1.29/32 mac fa:16:3e:10:04:3e mask
>> ff:ff:ff:ff:ff:ff
>> applied on sw_if_index(s): 5
>> MACIP acl_index: 4, count: 2 (true len 2) tag {} is free pool slot: 0
>> ip4_table_index 29, ip6_table_index 29, l2_table_index 29
>> out_ip4_table_index -1, out_ip6_table_index -1, out_l2_table_index -1
>>rule 0: ipv4 action 1 ip 0.0.0.0/32 mac fa:16:3e:7c:96:d0 mask
>> ff:ff:ff:ff:ff:ff
>>rule 1: ipv4 action 1 ip 145.144.1.53/32 mac fa:16:3e:7c:96:d0 mask
>> ff:ff:ff:ff:ff:ff
>> applied on sw_if_index(s): 7
>> MACIP acl_index: 6, count: 2 (true len 2) tag {} is free pool slot: 0
>> ip4_table_index 41, ip6_table_index 41, l2_table_index 41
>> out_ip4_table_index -1, out_ip6_table_index -1, out_l2_table_index -1
>>rule 0: ipv4 action 1 ip 0.0.0.0/32 mac fa:16:3e:93:0c:50 mask
>> ff:ff:ff:ff:ff:ff
>>rule 1: ipv4 action 1 ip 145.144.1.84/32 mac fa:16:3e:93:0c:50 mask
>> ff:ff:ff:ff:ff:ff
>> applied on sw_if_index(s): 10
>>
>>
>>
>> But then compare that to the show hardware:
>> vpp# sh hard
>> NameIdx Link Hardware
>> VirtualEthernet0/0/0 3 up VirtualEthernet0/0/0
>> Link speed: unknown
>> Ethernet address fa:16:3c:c9:a8:50
>> VirtualEthernet0/0/1 4 up VirtualEthernet0/0/1
>> Link speed: unknown
>> Ethernet address fa:16:3c:70:15:b3
>> VirtualEthernet0/0/2 5 up VirtualEthernet0/0/2
>> Link speed: unknown
>> Ethernet address fa:16:3c:05:66:7c
>> VirtualEthernet0/0/3 6 up VirtualEthernet0/0/3
>> Link speed: unknown
>> Ethernet address fa:16:3c:f0:21:0a
>> VirtualEthernet0/0/4 7 up VirtualEthernet0/0/4
>> Link speed: unknown
>> Ethernet address fa:16:3c:0f:9d:5d
>> local0 0down local0
>> Link speed: unknown
>> local
>> rdma0 1 up rdma0
>> Link speed: 40 Gbps
>> Ethernet address 02:fe:99:32:82:4f
>> flags: admin-up promiscuous
>> rdma1 2 up rdma1
>> Link speed: 40 Gbps
>> Ethernet address 02:fe:27:ea:09:82
>> flags: admin-up
>>
>> It looks like there doesn’t even exist an acl for VirtualEthernet0/0/3? Is
>> that why it is dropped?
>>
>> Eyle
>>
>> From: Andrew 👽 Yourtchenko
>> Date: Thursday, 5 September 2019 at 19:20
>> To: "Naveen Joy (najoy)"
>> Cc: Eyle Brinkhuis , "vpp-dev@lists.fd.io"
>>
>> Subject: Re: [vpp-dev] ACL drops while pinging another interface
>>
>> It hits the session, so it does pass the L3 acl. Just before ...
>> --a
>>
>> On 5 Sep 2019, at 18:52, Naveen Joy (najoy)
>> mailto:na...@cisco.com>> wrote:
>> From the trace, it appears like ICMP Echo reply is not permitted by the
>> security-group
