Dear Matthew,
Thank you for the response.
Yes, we are using NAT44 ED mode and have an output-feature variant
configured on the wan interface.
wan-ens7 output-feature out
Will try to follow the suggestion you posted to re-order the NAT/ACL nodes
so that ACL gets applied post-SNAT of the original packet.
thanks again for the response
regards
Venkat
On Tue, Sep 22, 2020 at 11:48 AM Matthew Smith <mgsm...@netgate.com> wrote:
>
> On Tue, Sep 22, 2020 at 12:21 PM Andrew Yourtchenko <ayour...@gmail.com>
> wrote:
>
>> I suggest making a unit test that captures this behavior and fails, then
>> we can look at what is the best way of fixing it and incorporate into the
>> CI...
>>
>> I remember this type of scenario being addressed once, not sure if it was
>> the same one or not...
>>
>> But you could probably work around it by having the ACLs on the inner
>> interface.
>>
>> --a
>>
>>
> Hi Andrew,
>
> In general, for NAT and stateful ACL to coexist, the NAT and ACL nodes
> must be ordered in the opposite order for in2out vs out2in packets. E.g. if
> you the NAT ran first followed by a stateful output ACL for outbound
> packets, then inbound packets must use the reverse ordering - input ACL
> followed by NAT. I ran into the same problem Venkat is having a while back
> due to the order of the NAT & ACL features nodes being the same in both
> directions. I did fix it and added a unit test, but I think I only fixed it
> for endpoint dependent mode. The endpoint independent in2out nodes look
> like some of them are running after the ACL plugin output node:
>
> VNET_FEATURE_INIT (ip4_snat_in2out_output, static) = {
> .arc_name = "ip4-output",
> .node_name = "nat44-in2out-output",
> .runs_after = VNET_FEATURES
> ("acl-plugin-out-ip4-fa","ip4-sv-reassembly-output-feature"),
> };
> VNET_FEATURE_INIT (ip4_snat_in2out_output_worker_handoff, static) = {
> .arc_name = "ip4-output",
> .node_name = "nat44-in2out-output-worker-handoff",
> .runs_after = VNET_FEATURES
> ("acl-plugin-out-ip4-fa","ip4-sv-reassembly-output-feature"),
> };
> VNET_FEATURE_INIT (ip4_snat_hairpin_src, static) = {
> .arc_name = "ip4-output",
> .node_name = "nat44-hairpin-src",
> .runs_after = VNET_FEATURES
> ("acl-plugin-out-ip4-fa","ip4-sv-reassembly-output-feature"),
> };
>
> I'm not positive about the "hairpin" node, but I think it ought to work if
> the code above is changed to look like this:
>
> VNET_FEATURE_INIT (ip4_snat_in2out_output, static) = {
> .arc_name = "ip4-output",
> .node_name = "nat44-in2out-output",
> .runs_after = VNET_FEATURES ("ip4-sv-reassembly-output-feature"),
> .runs_before = VNET_FEATURES ("acl-plugin-out-ip4-fa"),
> };
> VNET_FEATURE_INIT (ip4_snat_in2out_output_worker_handoff, static) = {
> .arc_name = "ip4-output",
> .node_name = "nat44-in2out-output-worker-handoff",
> .runs_after = VNET_FEATURES ("ip4-sv-reassembly-output-feature"),
> .runs_before = VNET_FEATURES ("acl-plugin-out-ip4-fa"),
> };
> VNET_FEATURE_INIT (ip4_snat_hairpin_src, static) = {
> .arc_name = "ip4-output",
> .node_name = "nat44-hairpin-src",
> .runs_after = VNET_FEATURES ("ip4-sv-reassembly-output-feature"),
> .runs_before = VNET_FEATURES ("acl-plugin-out-ip4-fa"),
> };
>
> Venkat, are you using any of the nodes listed above (i.e. are you using
> the output-feature variant of the in2out node in endpoint independent
> mode)? If so, I suggest applying the change I described and building from
> that code and test whether it solves your problem.
>
> -Matt
>
>
>
>
>> On 22 Sep 2020, at 18:58, Venkat <venkat.dabb...@gmail.com> wrote:
>>
>>
>> Thank you Andrew for the pointers and setting the expectations for VPP
>> ACL.
>>
>> On another topic, since the stateful behavior of ACL is per interface, I
>> setup permit+reflect output ACL on WAN interface ( Internet-facing Public
>> IP) for internet bound traffic. And I also have to Deny all incoming
>> traffic (input ACL on WAN interface) for security purposes. In addition, I
>> have SNAT configured on the same interface so that packets get source NATed
>> when going to the internet.
>>
>> Now the problem is since the ACL node comes before the SNAT node in the
>> feature ARC, stateful ACL sessions are built for the original Source/Dest
>> IP pair prior to SNAT.
>> Return traffic coming into the WAN interface comes with WAN IP (public
>> IP), gets dropped because of Deny all input ACL and the purpose of stateful
>> ACL is lost.
>> How is this scenario typically addressed?
>>
>> thanks
>> Venkat
>>
>>
>>
>> On Thu, Sep 17, 2020 at 3:19 PM Andrew 👽 Yourtchenko <ayour...@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On 17 Sep 2020, at 23:55, Venkat <venkat.dabb...@gmail.com> wrote:
>>>
>>>
>>>
>>> 2. What happens when ACL config is modified while traffic is flowing?
>>> Would the packets continue to hit the special-case "-1" session until the
>>> session is timed out and re-claimed? If that's true, then packets would
>>> continue to sneak through even when a user modifies the ACL from
>>> Permit+Reflect to Deny.
>>>
>>>
>>> Yep. You can look at the code, there is a debug CLI tweak to reclassify
>>> sessions, but I am not sure anyone actually uses it.
>>>
>>> There is no “always right” answer to this ~20 year old question.
>>>
>>> ACL plugin is very explicitly not a “fancy firewall”.
>>>
>>> [VD]: One more question on this behavior. If packets continue to hit
>>> the special-case "-1" session, would they ever hit the modified ACL? Or
>>> does the reclassify sessions logic kick in periodically (every timeout
>>> independent of traffic hit) and cleans up the special-case "-1" sessions so
>>> that new sessions build up again based on the current state of ACLs rule? I
>>> would assume, it's the latter case, otherwise, modified ACL would never hit
>>> if traffic continues to flow.
>>>
>>>
>>> Only with the idle timeout.
>>>
>>> ACL plugin is not intended to participate in a SWAT team, really. :-)
>>>
>>> —a
>>>
>>>
>>>
>>> On Thu, Sep 17, 2020 at 10:39 AM Andrew 👽 Yourtchenko <
>>> ayour...@gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On 17 Sep 2020, at 19:29, Venkat <venkat.dabb...@gmail.com> wrote:
>>>>
>>>>
>>>> Andrew,
>>>>
>>>> I have a few follow up questions on the stated behavior.
>>>>
>>>> 1. Does the behavior you outlined about hitting special-case "-1"
>>>> entries apply to UDP traffic as well if the ACL rule is stateful?
>>>>
>>>>
>>>> Yup.
>>>>
>>>>
>>>> 2. What happens when ACL config is modified while traffic is flowing?
>>>> Would the packets continue to hit the special-case "-1" session until the
>>>> session is timed out and re-claimed? If that's true, then packets would
>>>> continue to sneak through even when a user modifies the ACL from
>>>> Permit+Reflect to Deny.
>>>>
>>>>
>>>> Yep. You can look at the code, there is a debug CLI tweak to reclassify
>>>> sessions, but I am not sure anyone actually uses it.
>>>>
>>>> There is no “always right” answer to this ~20 year old question.
>>>>
>>>> ACL plugin is very explicitly not a “fancy firewall”.
>>>>
>>>>
>>>> 3. And regarding the special-case "-1" lookups, I assume a stateful ACL
>>>> hit would result in the creation of such a session and subsequent packets
>>>> would by-pass ACL rules and continue to be served by special-case "-1".
>>>>
>>>>
>>>> ...as your have observed it. The return packets on that interface
>>>> matching the same five tuple, too.
>>>>
>>>> —a
>>>>
>>>>
>>>>
>>>> thanks
>>>> Venkat
>>>>
>>>>
>>>> On Tue, Sep 15, 2020 at 2:01 AM Andrew 👽 Yourtchenko <
>>>> ayour...@gmail.com> wrote:
>>>>
>>>>> Hi Venkat,
>>>>>
>>>>> Before doing ACL checks, acl-plugin checks the establshed sessions on
>>>>> the given interface.
>>>>>
>>>>> If an already established session is hit the action is set to "3" and
>>>>> no further ACL check is done, which is what you see in your output.
>>>>>
>>>>> For that case, the ACL# in the trace is a special-case "-1", same as
>>>>> lc_index-1 - because we actually never get it to ACL lookup so do not
>>>>> need it; and the rule# is the session index; and the trace_bits tells
>>>>> us that this session is classifed to use timeout type "3", which is
>>>>> defined in acl_timeout_e as "ACL_TIMEOUT_TCP_TRANSIENT" - which makes
>>>>> sense, since you are sending the packets in one direction and thus the
>>>>> session never establishes and the timeout type never changes to
>>>>> "TCP_IDLE".
>>>>>
>>>>> Of the packets you sent in total, 15002 packets had hit the ACL#3
>>>>> rule and caused the sessions to be created. The rest of the packets
>>>>> had hit the established session entries and this is one of those that
>>>>> you have captured.
>>>>>
>>>>> At the time of taking the outputs the traffic was stopped and the
>>>>> sessions were deleted by idle timeout (which for the transient state
>>>>> is short).
>>>>>
>>>>> Does this make sense ?
>>>>>
>>>>> --a
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 9/14/20, Venkat <venkat.dabb...@gmail.com> wrote:
>>>>> > Hello Andrew,
>>>>> >
>>>>> > I am doing a simple test by sending TCP flows from Trex traffic
>>>>> generator.
>>>>> > Traffic source is 16.0.0.1-16.0.0.100 and destination is
>>>>> > 48.0.0.1-48.0.0.100.
>>>>> > I am sending TCP traffic with CPS=50 from 100 clients to 100 servers
>>>>> via
>>>>> > Trex http profile.
>>>>> >
>>>>> > I have a reflective ACL to permit the flow for the above src and dst.
>>>>> > I expect the packet to hit acl index 3 rule 0 and get permitted.
>>>>> > However, I see the following match in the packet trace which doesn't
>>>>> seem
>>>>> > like it is hitting acl index 3 and rule 0 but hitting some other acl
>>>>> index
>>>>> > (acl -1 and lc_index -1).
>>>>> > What is the behavior here? Please provide some context here..
>>>>> >
>>>>> > 03:47:03:874624: acl-plugin-in-ip4-fa
>>>>> >
>>>>> > acl-plugin: lc_index: -1, sw_if_index 1, next index 1, action: 3,
>>>>> match: acl
>>>>> > -1 rule 13309 trace_bits 80010303
>>>>> >
>>>>> > pkt info 0000000000000000 0000000000000000 0000000000000000
>>>>> 4300003043000010
>>>>> > 0001010600502d14 0310ffff00000000
>>>>> >
>>>>> > lc_index 0 l3 ip4 16.0.0.67 -> 48.0.0.67 l4 lsb_of_sw_if_index 1
>>>>> proto 6
>>>>> > l4_is_input 1 l4_slow_path 0 l4_flags 0x01 port 11540 -> 80 tcp flags
>>>>> > (valid) 10 rsvd 0
>>>>> >
>>>>> > DBGvpp# show acl-plugin acl
>>>>> >
>>>>> > acl-index 0 count 2 tag
>>>>> > {99998-sra-inbound-sasefwpro-nags-explicit-deny-99998}
>>>>> >
>>>>> > 0: ipv4 deny src 0.0.0.0/0 dst 0.0.0.0/0 proto 0 sport 0 dport 0
>>>>> >
>>>>> > 1: ipv6 deny src ::/0 dst ::/0 proto 0 sport 0 dport 0
>>>>> >
>>>>> > applied inbound on sw_if_index: 1
>>>>> >
>>>>> > applied outbound on sw_if_index:
>>>>> >
>>>>> > used in lookup context index: 1
>>>>> >
>>>>> > acl-index 1 count 6 tag
>>>>> > {99999-sra-inbound-sasefwpro-sase-default-fw-profile}
>>>>> >
>>>>> > 0: ipv4 permit+reflect src 0.0.0.0/0 dst 0.0.0.0/0 proto 6 sport
>>>>> 0-65535
>>>>> > dport 0-65535
>>>>> >
>>>>> > 1: ipv6 permit+reflect src ::/0 dst ::/0 proto 6 sport 0-65535 dport
>>>>> > 0-65535
>>>>> >
>>>>> > 2: ipv4 permit+reflect src 0.0.0.0/0 dst 0.0.0.0/0 proto 17 sport
>>>>> 0-65535
>>>>> > dport 0-65535
>>>>> >
>>>>> > 3: ipv6 permit+reflect src ::/0 dst ::/0 proto 17 sport 0-65535 dport
>>>>> > 0-65535
>>>>> >
>>>>> > 4: ipv4 permit+reflect src 0.0.0.0/0 dst 0.0.0.0/0 proto 1 sport
>>>>> 0-65535
>>>>> > dport 0-65535
>>>>> >
>>>>> > 5: ipv4 permit+reflect src 0.0.0.0/0 dst 0.0.0.0/0 proto 1 sport
>>>>> 0-65535
>>>>> > dport 0-65535
>>>>> >
>>>>> > applied inbound on sw_if_index: 1
>>>>> >
>>>>> > applied outbound on sw_if_index:
>>>>> >
>>>>> > used in lookup context index: 1
>>>>> >
>>>>> > acl-index 2 count 6 tag
>>>>> > {99999-sra-outbound-sasefwpro-sase-default-fw-profile}
>>>>> >
>>>>> > 0: ipv4 deny src 0.0.0.0/0 dst 0.0.0.0/0 proto 6 sport 0-65535 dport
>>>>> > 0-65535
>>>>> >
>>>>> > 1: ipv6 deny src ::/0 dst ::/0 proto 6 sport 0-65535 dport 0-65535
>>>>> >
>>>>> > 2: ipv4 deny src 0.0.0.0/0 dst 0.0.0.0/0 proto 17 sport 0-65535
>>>>> dport
>>>>> > 0-65535
>>>>> >
>>>>> > 3: ipv6 deny src ::/0 dst ::/0 proto 17 sport 0-65535 dport 0-65535
>>>>> >
>>>>> > 4: ipv4 deny src 0.0.0.0/0 dst 0.0.0.0/0 proto 1 sport 0-65535 dport
>>>>> > 0-65535
>>>>> >
>>>>> > 5: ipv4 deny src 0.0.0.0/0 dst 0.0.0.0/0 proto 1 sport 0-65535 dport
>>>>> > 0-65535
>>>>> >
>>>>> > applied inbound on sw_if_index:
>>>>> >
>>>>> > applied outbound on sw_if_index: 1
>>>>> >
>>>>> > used in lookup context index: 0
>>>>> >
>>>>> > acl-index 3 count 1 tag {100-allow-48}
>>>>> >
>>>>> > 0: ipv4 permit+reflect src 16.0.0.0/16 dst 48.0.0.0/16 proto 0
>>>>> sport 0 dport
>>>>> > 0
>>>>> >
>>>>> > applied inbound on sw_if_index: 1
>>>>> >
>>>>> > used in lookup context index: 1
>>>>> >
>>>>> > DBGvpp#
>>>>> >
>>>>> > DBGvpp# show acl-plugin tables
>>>>> >
>>>>> > Stats counters enabled for interface ACLs: 0
>>>>> >
>>>>> > Mask-type entries:
>>>>> >
>>>>> > 0: 0000000000000000 0000000000000000 0000000000000000
>>>>> 0000000000000000
>>>>> > 0000000000000000 0800ffffffffffff refcount 4
>>>>> >
>>>>> > 1: 0000000000000000 0000000000000000 0000000000000000
>>>>> 0000000000000000
>>>>> > 000000ff00000000 0e00ffffffffffff refcount 24
>>>>> >
>>>>> > 2: 0000000000000000 0000000000000000 0000000000000000
>>>>> 0000ffff0000ffff
>>>>> > 0000000000000000 0800ffffffffffff refcount 2
>>>>> >
>>>>> > Mask-ready ACL representations
>>>>> >
>>>>> > acl-index 0 bitmask-ready layout
>>>>> >
>>>>> > applied lc_index list: 1
>>>>> >
>>>>> > 0: 0000000000000000 0000000000000000 0000000000000000
>>>>> 0000000000000000
>>>>> > 0000000000000000 0000000000000000 base mask index 0 acl 0 rule 0
>>>>> action 0
>>>>> >
>>>>> > 1: 0000000000000000 0000000000000000 0000000000000000
>>>>> 0000000000000000
>>>>> > 0000000000000000 0800000000000000 base mask index 0 acl 0 rule 1
>>>>> action 0
>>>>> >
>>>>> > acl-index 1 bitmask-ready layout
>>>>> >
>>>>> > applied lc_index list: 1
>>>>> >
>>>>> > 0: 0000000000000000 0000000000000000 0000000000000000
>>>>> 0000000000000000
>>>>> > 0000000600000000 0200000100000000 base mask index 1 acl 1 rule 0
>>>>> action 2
>>>>> >
>>>>> > 1: 0000000000000000 0000000000000000 0000000000000000
>>>>> 0000000000000000
>>>>> > 0000000600000000 0a00000100000000 base mask index 1 acl 1 rule 1
>>>>> action 2
>>>>> >
>>>>> > 2: 0000000000000000 0000000000000000 0000000000000000
>>>>> 0000000000000000
>>>>> > 0000001100000000 0200000100000000 base mask index 1 acl 1 rule 2
>>>>> action 2
>>>>> >
>>>>> > 3: 0000000000000000 0000000000000000 0000000000000000
>>>>> 0000000000000000
>>>>> > 0000001100000000 0a00000100000000 base mask index 1 acl 1 rule 3
>>>>> action 2
>>>>> >
>>>>> > 4: 0000000000000000 0000000000000000 0000000000000000
>>>>> 0000000000000000
>>>>> > 0000000100000000 0200000100000000 base mask index 1 acl 1 rule 4
>>>>> action 2
>>>>> >
>>>>> > 5: 0000000000000000 0000000000000000 0000000000000000
>>>>> 0000000000000000
>>>>> > 0000000100000000 0200000100000000 base mask index 1 acl 1 rule 5
>>>>> action 2
>>>>> >
>>>>> > acl-index 2 bitmask-ready layout
>>>>> >
>>>>> > applied lc_index list: 0
>>>>> >
>>>>> > 0: 0000000000000000 0000000000000000 0000000000000000
>>>>> 0000000000000000
>>>>> > 0000000600000000 0200000100000000 base mask index 1 acl 2 rule 0
>>>>> action 0
>>>>> >
>>>>> > 1: 0000000000000000 0000000000000000 0000000000000000
>>>>> 0000000000000000
>>>>> > 0000000600000000 0a00000100000000 base mask index 1 acl 2 rule 1
>>>>> action 0
>>>>> >
>>>>> > 2: 0000000000000000 0000000000000000 0000000000000000
>>>>> 0000000000000000
>>>>> > 0000001100000000 0200000100000000 base mask index 1 acl 2 rule 2
>>>>> action 0
>>>>> >
>>>>> > 3: 0000000000000000 0000000000000000 0000000000000000
>>>>> 0000000000000000
>>>>> > 0000001100000000 0a00000100000000 base mask index 1 acl 2 rule 3
>>>>> action 0
>>>>> >
>>>>> > 4: 0000000000000000 0000000000000000 0000000000000000
>>>>> 0000000000000000
>>>>> > 0000000100000000 0200000100000000 base mask index 1 acl 2 rule 4
>>>>> action 0
>>>>> >
>>>>> > 5: 0000000000000000 0000000000000000 0000000000000000
>>>>> 0000000000000000
>>>>> > 0000000100000000 0200000100000000 base mask index 1 acl 2 rule 5
>>>>> action 0
>>>>> >
>>>>> > acl-index 3 bitmask-ready layout
>>>>> >
>>>>> > applied lc_index list: 1
>>>>> >
>>>>> > 0: 0000000000000000 0000000000000000 0000000000000000
>>>>> 0000003000000010
>>>>> > 0000000000000000 0000000200000000 base mask index 2 acl 3 rule 0
>>>>> action 2
>>>>> >
>>>>> > Applied lookup entries for lookup contexts
>>>>> >
>>>>> > lc_index 0:
>>>>> >
>>>>> > applied acls: 2
>>>>> >
>>>>> > applied mask info entries:
>>>>> >
>>>>> > 0: mask type index 1 first rule index 0 num_entries 6 max_collisions
>>>>> 2
>>>>> >
>>>>> > lookup applied entries:
>>>>> >
>>>>> > 0: acl 2 rule 0 action 0 bitmask-ready rule 0 mask type index: 1
>>>>> > colliding_rules: 1 collision_head_ae_idx 0 hitcount 0 acl_pos: 0
>>>>> >
>>>>> > 0: acl 2 ace 0 acl pos 0 pae index: 0
>>>>> >
>>>>> > 1: acl 2 rule 1 action 0 bitmask-ready rule 1 mask type index: 1
>>>>> > colliding_rules: 1 collision_head_ae_idx 1 hitcount 0 acl_pos: 0
>>>>> >
>>>>> > 0: acl 2 ace 1 acl pos 0 pae index: 1
>>>>> >
>>>>> > 2: acl 2 rule 2 action 0 bitmask-ready rule 2 mask type index: 1
>>>>> > colliding_rules: 1 collision_head_ae_idx 2 hitcount 0 acl_pos: 0
>>>>> >
>>>>> > 0: acl 2 ace 2 acl pos 0 pae index: 2
>>>>> >
>>>>> > 3: acl 2 rule 3 action 0 bitmask-ready rule 3 mask type index: 1
>>>>> > colliding_rules: 1 collision_head_ae_idx 3 hitcount 0 acl_pos: 0
>>>>> >
>>>>> > 0: acl 2 ace 3 acl pos 0 pae index: 3
>>>>> >
>>>>> > 4: acl 2 rule 4 action 0 bitmask-ready rule 4 mask type index: 1
>>>>> > colliding_rules: 2 collision_head_ae_idx 4 hitcount 0 acl_pos: 0
>>>>> >
>>>>> > 0: acl 2 ace 4 acl pos 0 pae index: 4
>>>>> >
>>>>> > 1: acl 2 ace 5 acl pos 0 pae index: 5
>>>>> >
>>>>> > 5: acl 2 rule 5 action 0 bitmask-ready rule 5 mask type index: 1
>>>>> > colliding_rules: 0 collision_head_ae_idx 4 hitcount 0 acl_pos: 0
>>>>> >
>>>>> > lc_index 1:
>>>>> >
>>>>> > applied acls: 3, 0, 1
>>>>> >
>>>>> > applied mask info entries:
>>>>> >
>>>>> > 0: mask type index 2 first rule index 0 num_entries 1 max_collisions
>>>>> 1
>>>>> >
>>>>> > 1: mask type index 0 first rule index 1 num_entries 2 max_collisions
>>>>> 1
>>>>> >
>>>>> > 2: mask type index 1 first rule index 3 num_entries 6 max_collisions
>>>>> 2
>>>>> >
>>>>> > lookup applied entries:
>>>>> >
>>>>> > 0: acl 3 rule 0 action 2 bitmask-ready rule 0 mask type index: 2
>>>>> > colliding_rules: 1 collision_head_ae_idx 0 hitcount 150001 acl_pos: 0
>>>>> >
>>>>> > 0: acl 3 ace 0 acl pos 0 pae index: 0
>>>>> >
>>>>> > 1: acl 0 rule 0 action 0 bitmask-ready rule 0 mask type index: 0
>>>>> > colliding_rules: 1 collision_head_ae_idx 1 hitcount 0 acl_pos: 1
>>>>> >
>>>>> > 0: acl 0 ace 0 acl pos 1 pae index: 1
>>>>> >
>>>>> > 2: acl 0 rule 1 action 0 bitmask-ready rule 1 mask type index: 0
>>>>> > colliding_rules: 1 collision_head_ae_idx 2 hitcount 0 acl_pos: 1
>>>>> >
>>>>> > 0: acl 0 ace 1 acl pos 1 pae index: 2
>>>>> >
>>>>> > 3: acl 1 rule 0 action 2 bitmask-ready rule 0 mask type index: 1
>>>>> > colliding_rules: 1 collision_head_ae_idx 3 hitcount 0 acl_pos: 2
>>>>> >
>>>>> > 0: acl 1 ace 0 acl pos 2 pae index: 3
>>>>> >
>>>>> > 4: acl 1 rule 1 action 2 bitmask-ready rule 1 mask type index: 1
>>>>> > colliding_rules: 1 collision_head_ae_idx 4 hitcount 0 acl_pos: 2
>>>>> >
>>>>> > 0: acl 1 ace 1 acl pos 2 pae index: 4
>>>>> >
>>>>> > 5: acl 1 rule 2 action 2 bitmask-ready rule 2 mask type index: 1
>>>>> > colliding_rules: 1 collision_head_ae_idx 5 hitcount 0 acl_pos: 2
>>>>> >
>>>>> > 0: acl 1 ace 2 acl pos 2 pae index: 5
>>>>> >
>>>>> > 6: acl 1 rule 3 action 2 bitmask-ready rule 3 mask type index: 1
>>>>> > colliding_rules: 1 collision_head_ae_idx 6 hitcount 0 acl_pos: 2
>>>>> >
>>>>> > 0: acl 1 ace 3 acl pos 2 pae index: 6
>>>>> >
>>>>> > 7: acl 1 rule 4 action 2 bitmask-ready rule 4 mask type index: 1
>>>>> > colliding_rules: 2 collision_head_ae_idx 7 hitcount 0 acl_pos: 2
>>>>> >
>>>>> > 0: acl 1 ace 4 acl pos 2 pae index: 7
>>>>> >
>>>>> > 1: acl 1 ace 5 acl pos 2 pae index: 8
>>>>> >
>>>>> > 8: acl 1 rule 5 action 2 bitmask-ready rule 5 mask type index: 1
>>>>> > colliding_rules: 0 collision_head_ae_idx 7 hitcount 0 acl_pos: 2
>>>>> >
>>>>> > ACL lookup hash table:
>>>>> >
>>>>> > Hash table ACL plugin rule lookup bihash
>>>>> >
>>>>> > 13 active elements 13 active buckets
>>>>> >
>>>>> > 1 free lists
>>>>> >
>>>>> > 0 linear search buckets
>>>>> >
>>>>> > arena: base 7f7377ff0000, next 80d00
>>>>> >
>>>>> > used 527616 b (0 Mbytes) of 67108864 b (64 Mbytes)
>>>>> >
>>>>> > DBGvpp# show acl-plugin sessions
>>>>> >
>>>>> > Sessions total: add 150002 - del 150002 = 0
>>>>> >
>>>>> > Sessions active: add 150002 - deact 150002 = 0
>>>>> >
>>>>> > Sessions being purged: deact 150002 - del 150002 = 0
>>>>> >
>>>>> > now: 38259162493998 clocks per second: 2500000000
>>>>> >
>>>>> > Per-thread data:
>>>>> >
>>>>> > Thread #0:
>>>>> >
>>>>> > connection add/del stats:
>>>>> >
>>>>> > sw_if_index 0: add 0 - del 0 = 0; epoch chg: 0
>>>>> >
>>>>> > sw_if_index 1: add 150002 - del 150002 = 0; epoch chg: 0
>>>>> >
>>>>> > sw_if_index 2: add 0 - del 0 = 0; epoch chg: 0
>>>>> >
>>>>> > sw_if_index 3: add 0 - del 0 = 0; epoch chg: 0
>>>>> >
>>>>> > sw_if_index 4: add 0 - del 0 = 0; epoch chg: 0
>>>>> >
>>>>> > sw_if_index 5: add 0 - del 0 = 0; epoch chg: 0
>>>>> >
>>>>> > sw_if_index 6: add 0 - del 0 = 0; epoch chg: 0
>>>>> >
>>>>> > sw_if_index 7: add 0 - del 0 = 0; epoch chg: 0
>>>>> >
>>>>> > sw_if_index 8: add 0 - del 0 = 0; epoch chg: 0
>>>>> >
>>>>> > sw_if_index 9: add 0 - del 0 = 0; epoch chg: 0
>>>>> >
>>>>> > connection timeout type lists:
>>>>> >
>>>>> > fa_conn_list_head[0]: -1
>>>>> >
>>>>> > fa_conn_list_head[1]: -1
>>>>> >
>>>>> > fa_conn_list_head[2]: -1
>>>>> >
>>>>> > fa_conn_list_head[3]: -1
>>>>> >
>>>>> > fa_conn_list_head[4]: -1
>>>>> >
>>>>> > Next expiry time: 0
>>>>> >
>>>>> > Requeue until time: 0
>>>>> >
>>>>> > Current time wait interval: 0
>>>>> >
>>>>> > Count of deleted sessions: 150002
>>>>> >
>>>>> > Delete already deleted: 0
>>>>> >
>>>>> > Session timers restarted: 150750
>>>>> >
>>>>> > Swipe until this time: 0
>>>>> >
>>>>> > sw_if_index serviced bitmap: 2
>>>>> >
>>>>> > pending clear intfc bitmap :
>>>>> >
>>>>> > clear in progress: 0
>>>>> >
>>>>> > interrupt is pending: 0
>>>>> >
>>>>> > interrupt is needed: 0
>>>>> >
>>>>> > interrupt is unwanted: 0
>>>>> >
>>>>> > interrupt generation: 14572
>>>>> >
>>>>> > received session change requests: 0
>>>>> >
>>>>> > sent session change requests: 0
>>>>> >
>>>>> > Conn cleaner thread counters:
>>>>> >
>>>>> > 33: delete_by_sw_index events
>>>>> >
>>>>> > 30: delete_by_sw_index handled ok
>>>>> >
>>>>> > 0: unknown events received
>>>>> >
>>>>> > 0: session idle timers restarted
>>>>> >
>>>>> > 14567: event wait with timeout called
>>>>> >
>>>>> > 5: event wait w/o timeout called
>>>>> >
>>>>> > 14571: total event cycles
>>>>> >
>>>>> > Interrupt generation: 14572
>>>>> >
>>>>> > Sessions per interval: min 1 max 100 increment: 100 ms current: 500
>>>>> ms
>>>>> >
>>>>> > Reclassify sessions: 0
>>>>> >
>>>>> > IPv6 Session lookup hash table:
>>>>> >
>>>>> > Hash table ACL plugin FA IPv6 session bihash
>>>>> >
>>>>> > [empty, uninitialized]
>>>>> >
>>>>> > IPv4 Session lookup hash table:
>>>>> >
>>>>> > Hash table ACL plugin FA IPv4 session bihash
>>>>> >
>>>>> > 0 active elements 0 active buckets
>>>>> >
>>>>> > 5 free lists
>>>>> >
>>>>> > [len 1] 51199 free elts
>>>>> >
>>>>> > [len 2] 4504 free elts
>>>>> >
>>>>> > [len 4] 373 free elts
>>>>> >
>>>>> > [len 8] 9 free elts
>>>>> >
>>>>> > [len 16] 1 free elts
>>>>> >
>>>>> > 0 linear search buckets
>>>>> >
>>>>> > arena: base 7f5abb720000, next 7b84c0
>>>>> >
>>>>> > used 8094912 b (7 Mbytes) of 1073741824 b (1024 Mbytes)
>>>>> >
>>>>> > DBGvpp# show nat44 addresses
>>>>> >
>>>>> > NAT44 pool addresses:
>>>>> >
>>>>> > 172.24.114.39
>>>>> >
>>>>> > tenant VRF independent
>>>>> >
>>>>> > 0 busy udp ports
>>>>> >
>>>>> > 15001 busy tcp ports
>>>>> >
>>>>> > 0 busy icmp ports
>>>>> >
>>>>> > NAT44 twice-nat pool addresses:
>>>>> >
>>>>> > 10.40.1.254
>>>>> >
>>>>> > tenant VRF independent
>>>>> >
>>>>> > 0 busy udp ports
>>>>> >
>>>>> > 0 busy tcp ports
>>>>> >
>>>>> > 0 busy icmp ports
>>>>> >
>>>>> > DBGvpp#
>>>>> >
>>>>> > Packet 50
>>>>> >
>>>>> > 03:47:03:874592: dpdk-input
>>>>> >
>>>>> > lan-ens6 rx queue 0
>>>>> >
>>>>> > buffer 0x8b222: current data 0, length 54, buffer-pool 0, ref-count
>>>>> 1,
>>>>> > totlen-nifb 0, trace handle 0x31
>>>>> >
>>>>> > ext-hdr-valid
>>>>> >
>>>>> > l4-cksum-computed l4-cksum-correct
>>>>> >
>>>>> > PKT MBUF: port 0, nb_segs 1, pkt_len 54
>>>>> >
>>>>> > buf_len 2176, data_len 54, ol_flags 0x0, data_off 128, phys_addr
>>>>> 0x6fec8900
>>>>> >
>>>>> > packet_type 0x110 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
>>>>> >
>>>>> > rss 0x3aa73aa7 fdir.hi 0x0 fdir.lo 0x3aa73aa7
>>>>> >
>>>>> > Packet Types
>>>>> >
>>>>> > RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers
>>>>> >
>>>>> > RTE_PTYPE_L4_TCP (0x0100) TCP packet
>>>>> >
>>>>> > IP4: 02:85:36:20:e4:87 -> 02:2e:53:e6:4f:e1
>>>>> >
>>>>> > TCP: 16.0.0.67 -> 48.0.0.67
>>>>> >
>>>>> > tos 0x00, ttl 128, length 40, checksum 0x80f9
>>>>> >
>>>>> > fragment id 0x7951
>>>>> >
>>>>> > TCP: 11540 -> 80
>>>>> >
>>>>> > seq. 0x181a45db ack 0x181af226
>>>>> >
>>>>> > flags 0x10 ACK, tcp header: 20 bytes
>>>>> >
>>>>> > window 32768, checksum 0x59b4
>>>>> >
>>>>> > 03:47:03:874606: ethernet-input
>>>>> >
>>>>> > frame: flags 0x3, hw-if-index 1, sw-if-index 1
>>>>> >
>>>>> > IP4: 02:85:36:20:e4:87 -> 02:2e:53:e6:4f:e1
>>>>> >
>>>>> > 03:47:03:874620: ip4-input-no-checksum
>>>>> >
>>>>> > TCP: 16.0.0.67 -> 48.0.0.67
>>>>> >
>>>>> > tos 0x00, ttl 128, length 40, checksum 0x80f9
>>>>> >
>>>>> > fragment id 0x7951
>>>>> >
>>>>> > TCP: 11540 -> 80
>>>>> >
>>>>> > seq. 0x181a45db ack 0x181af226
>>>>> >
>>>>> > flags 0x10 ACK, tcp header: 20 bytes
>>>>> >
>>>>> > window 32768, checksum 0x59b4
>>>>> >
>>>>> > 03:47:03:874624: acl-plugin-in-ip4-fa
>>>>> >
>>>>> > acl-plugin: lc_index: -1, sw_if_index 1, next index 1, action: 3,
>>>>> match: acl
>>>>> > -1 rule 13309 trace_bits 80010303
>>>>> >
>>>>> > pkt info 0000000000000000 0000000000000000 0000000000000000
>>>>> 4300003043000010
>>>>> > 0001010600502d14 0310ffff00000000
>>>>> >
>>>>> > lc_index 0 l3 ip4 16.0.0.67 -> 48.0.0.67 l4 lsb_of_sw_if_index 1
>>>>> proto 6
>>>>> > l4_is_input 1 l4_slow_path 0 l4_flags 0x01 port 11540 -> 80 tcp flags
>>>>> > (valid) 10 rsvd 0
>>>>> >
>>>>> > 03:47:03:874634: ip4-lookup
>>>>> >
>>>>> > fib 0 dpo-idx 53 flow hash: 0x00000000
>>>>> >
>>>>> > TCP: 16.0.0.67 -> 48.0.0.67
>>>>> >
>>>>> > tos 0x00, ttl 128, length 40, checksum 0x80f9
>>>>> >
>>>>> > fragment id 0x7951
>>>>> >
>>>>> > TCP: 11540 -> 80
>>>>> >
>>>>> > seq. 0x181a45db ack 0x181af226
>>>>> >
>>>>> > flags 0x10 ACK, tcp header: 20 bytes
>>>>> >
>>>>> > window 32768, checksum 0x59b4
>>>>> >
>>>>> > 03:47:03:874639: ip4-load-balance
>>>>> >
>>>>> > fib 0 dpo-idx 14 flow hash: 0x00000000
>>>>> >
>>>>> > TCP: 16.0.0.67 -> 48.0.0.67
>>>>> >
>>>>> > tos 0x00, ttl 128, length 40, checksum 0x80f9
>>>>> >
>>>>> > fragment id 0x7951
>>>>> >
>>>>> > TCP: 11540 -> 80
>>>>> >
>>>>> > seq. 0x181a45db ack 0x181af226
>>>>> >
>>>>> > flags 0x10 ACK, tcp header: 20 bytes
>>>>> >
>>>>> > window 32768, checksum 0x59b4
>>>>> >
>>>>> > 03:47:03:874655: ip4-rewrite
>>>>> >
>>>>> > tx_sw_if_index 2 dpo-idx 14 : ipv4 via 172.24.115.166 wan-ens7:
>>>>> mtu:9000
>>>>> > 02fcbaad303302c6e54357a50800 flow hash: 0x00000000
>>>>> >
>>>>> > 00000000:
>>>>> 02fcbaad303302c6e54357a5080045000028795100007f0681f9100000433000
>>>>> >
>>>>> > 00000020: 00432d140050181a45db181af2265010800059b400002a2a2a2a2a2a
>>>>> >
>>>>> > 03:47:03:874660: nat44-ed-in2out-output
>>>>> >
>>>>> > NAT44_IN2OUT_ED_FAST_PATH: sw_if_index 1, next index 0, session 34066
>>>>> >
>>>>> > 03:47:03:874681: wan-ens7-output
>>>>> >
>>>>> > wan-ens7 l4-cksum-computed l4-cksum-correct natted
>>>>> l2_hdr_offset_valid
>>>>> > l3_hdr_offset_valid
>>>>> >
>>>>> > IP4: 02:c6:e5:43:57:a5 -> 02:fc:ba:ad:30:33
>>>>> >
>>>>> > TCP: 172.24.114.39 -> 48.0.0.67
>>>>> >
>>>>> > tos 0x00, ttl 127, length 40, checksum 0x73fc
>>>>> >
>>>>> > fragment id 0x7951
>>>>> >
>>>>> > TCP: 8447 -> 80
>>>>> >
>>>>> > seq. 0x181a45db ack 0x181af226
>>>>> >
>>>>> > flags 0x10 ACK, tcp header: 20 bytes
>>>>> >
>>>>> > window 32768, checksum 0x57cc
>>>>> >
>>>>> > 03:47:03:874685: wan-ens7-tx
>>>>> >
>>>>> > wan-ens7 tx queue 0
>>>>> >
>>>>> > buffer 0x8b222: current data 0, length 54, buffer-pool 0, ref-count
>>>>> 1,
>>>>> > totlen-nifb 0, trace handle 0x31
>>>>> >
>>>>> > ext-hdr-valid
>>>>> >
>>>>> > l4-cksum-computed l4-cksum-correct natted l2-hdr-offset 0
>>>>> l3-hdr-offset 14
>>>>> >
>>>>> > PKT MBUF: port 0, nb_segs 1, pkt_len 54
>>>>> >
>>>>> > buf_len 2176, data_len 54, ol_flags 0x0, data_off 128, phys_addr
>>>>> 0x6fec8900
>>>>> >
>>>>> > packet_type 0x110 l2_len 0 l3_len 0 outer_l2_len 0 outer_l3_len 0
>>>>> >
>>>>> > rss 0x3aa73aa7 fdir.hi 0x0 fdir.lo 0x3aa73aa7
>>>>> >
>>>>> > Packet Types
>>>>> >
>>>>> > RTE_PTYPE_L3_IPV4 (0x0010) IPv4 packet without extension headers
>>>>> >
>>>>> > RTE_PTYPE_L4_TCP (0x0100) TCP packet
>>>>> >
>>>>> > IP4: 02:c6:e5:43:57:a5 -> 02:fc:ba:ad:30:33
>>>>> >
>>>>> > TCP: 172.24.114.39 -> 48.0.0.67
>>>>> >
>>>>> > tos 0x00, ttl 127, length 40, checksum 0x73fc
>>>>> >
>>>>> > fragment id 0x7951
>>>>> >
>>>>> > TCP: 8447 -> 80
>>>>> >
>>>>> > seq. 0x181a45db ack 0x181af226
>>>>> >
>>>>> > flags 0x10 ACK, tcp header: 20 bytes
>>>>> >
>>>>> > window 32768, checksum 0x57cc
>>>>> >
>>>>>
>>>>
>>
>>
>>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#17484): https://lists.fd.io/g/vpp-dev/message/17484
Mute This Topic: https://lists.fd.io/mt/76852206/21656
Group Owner: vpp-dev+ow...@lists.fd.io
Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
