It hits the session, so it does pass the L3 acl. Just before ...

--a

> On 5 Sep 2019, at 18:52, Naveen Joy (najoy) <[email protected]> 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: <[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]> 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]
> Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub  [[email protected]]
> -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#13913): https://lists.fd.io/g/vpp-dev/message/13913
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]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to