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: <[email protected]> on behalf of Andrew Yourtchenko <[email protected]> Date: Thursday, September 5, 2019 at 7:20 AM To: Eyle Brinkhuis <[email protected]> Cc: "[email protected]" <[email protected]> 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 <[email protected]<mailto:[email protected]>> 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 80000000 pkt info 0000000000000000 0000000000000000 0000000000000000 3501909154019091 000a030100000008 0200ffff00000000 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 [0x5d50000000009, 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 00000000 pkt info 0000000000000000 0000000000000000 0000000000000000 3501909154019091 0009020100000008 0200ffff00000006 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 80000000 pkt info 0000000000000000 0000000000000000 0000000000000000 5401909135019091 0009030100000000 0200ffff00000000 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 00:53:47:316362: drop l2-input-acl: input ACL table-miss drops The packets get dropped.. I have found all the acl’s in vpp, but I cannot really see what would be wrong here, or what causes the packets to be dropped. Has anyone else had any experiences like this, or a solution? Regards, Eyle -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13909): https://lists.fd.io/g/vpp-dev/message/13909 Mute This Topic: https://lists.fd.io/mt/33152601/675608 Group Owner: [email protected]<mailto:[email protected]> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [[email protected]<mailto:[email protected]>] -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13912): https://lists.fd.io/g/vpp-dev/message/13912 Mute This Topic: https://lists.fd.io/mt/33152601/21656 Group Owner: [email protected] Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
