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] -=-=-=-=-=-=-=-=-=-=-=-