Re: [vpp-dev] Question about acl match/permit behavior.
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 wrote:
>
> On Tue, Sep 22, 2020 at 12:21 PM Andrew Yourtchenko
> 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 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
>> wrote:
>>
>>>
>>>
>>> On 17 Sep 2020, at 23:55, Venkat 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
Re: [vpp-dev] Question about acl match/permit behavior.
On Tue, Sep 22, 2020 at 12:21 PM Andrew Yourtchenko
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 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
> wrote:
>
>>
>>
>> On 17 Sep 2020, at 23:55, Venkat 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,
Re: [vpp-dev] Question about acl match/permit behavior.
But you could probably work around it by having the ACLs on the inner interface. [VENKAT]: We currently are following that approach. Setting ACLs on the LAN interface. But it comes with its own problems. - First, the WAN interface is wide open to the internet without any FW rules - Second, input ACLs on LAN interferes with ABF functionality as the ACL node comes before the ABF node. It's getting trickier as we configure multiple features and it's co-existence. thanks Venkat On Tue, Sep 22, 2020 at 10:21 AM Andrew Yourtchenko 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 > > On 22 Sep 2020, at 18:58, Venkat 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 > wrote: > >> >> >> On 17 Sep 2020, at 23:55, Venkat 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 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.
Re: [vpp-dev] Question about acl match/permit behavior.
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 > On 22 Sep 2020, at 18:58, Venkat 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 > wrote: >> >> >>> On 17 Sep 2020, at 23:55, Venkat 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 >>> wrote: > On 17 Sep 2020, at 19:29, Venkat 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 > 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
Re: [vpp-dev] Question about acl match/permit behavior.
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 wrote: > > > On 17 Sep 2020, at 23:55, Venkat 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 > wrote: > >> >> >> On 17 Sep 2020, at 19:29, Venkat 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 >> 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 wrote: >>> > Hello Andrew, >>> > >>> > I am doing a simple test by sending TCP flows from Trex traffic >>> generator. >>> > Traffic source is
Re: [vpp-dev] Question about acl match/permit behavior.
> On 17 Sep 2020, at 23:55, Venkat 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 >> wrote: >> >> On 17 Sep 2020, at 19:29, Venkat 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 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 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 > >
Re: [vpp-dev] Question about acl match/permit behavior.
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.
On Thu, Sep 17, 2020 at 10:39 AM Andrew Yourtchenko
wrote:
>
>
> On 17 Sep 2020, at 19:29, Venkat 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
> 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 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
>> 43304310
>> > 0001010600502d14 0310
>> >
>> > 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
>> > {8-sra-inbound-sasefwpro-nags-explicit-deny-8}
>> >
>> > 0: ipv4 deny src
Re: [vpp-dev] Question about acl match/permit behavior.
> On 17 Sep 2020, at 21:21, Venkat wrote: > > > Thanks, Andrew, > > And I noticed that sessions get deleted/reclaimed when ACL is disassociated > from the interface to which it was attached prior. > Maybe that's one option to have ACL detach and reattach to the interface when > there is any modification to the ACL to have immediately expected behavior > instead of waiting for the sessions to reclaim and reclassify. It’s an option I considered and specifically discarded. I think there are folks (at least in test) running millions of connections. You don’t want to swoop all these connections all at once when you are changing an ACL and potentially recreate them all at once again. Of course, if you contribute the code that replaces the reclassification with your suggested approach and you have data that it improves the performance in at least some cases and doesn’t degrade it in the others - I will be very happy to discuss it. :-) —a > > thanks > Venkat > >> On Thu, Sep 17, 2020 at 10:39 AM Andrew Yourtchenko >> wrote: >> >> On 17 Sep 2020, at 19:29, Venkat 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 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 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 > 43304310 > 0001010600502d14 0310 > > 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
Re: [vpp-dev] Question about acl match/permit behavior.
Thanks, Andrew,
And I noticed that sessions get deleted/reclaimed when ACL is disassociated
from the interface to which it was attached prior.
Maybe that's one option to have ACL detach and reattach to the interface
when there is any modification to the ACL to have immediately expected
behavior instead of waiting for the sessions to reclaim and reclassify.
thanks
Venkat
On Thu, Sep 17, 2020 at 10:39 AM Andrew Yourtchenko
wrote:
>
>
> On 17 Sep 2020, at 19:29, Venkat 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
> 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 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
>> 43304310
>> > 0001010600502d14 0310
>> >
>> > 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
>> > {8-sra-inbound-sasefwpro-nags-explicit-deny-8}
>> >
>> > 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
>> > {9-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:
Re: [vpp-dev] Question about acl match/permit behavior.
> On 17 Sep 2020, at 19:29, Venkat 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
>> 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 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
>> > 43304310
>> > 0001010600502d14 0310
>> >
>> > 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
>> > {8-sra-inbound-sasefwpro-nags-explicit-deny-8}
>> >
>> > 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
>> > {9-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
>>
Re: [vpp-dev] Question about acl match/permit behavior.
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?
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.
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".
thanks
Venkat
On Tue, Sep 15, 2020 at 2:01 AM Andrew Yourtchenko
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 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
> 43304310
> > 0001010600502d14 0310
> >
> > 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
> > {8-sra-inbound-sasefwpro-nags-explicit-deny-8}
> >
> > 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
> > {9-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
> > {9-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
Re: [vpp-dev] Question about acl match/permit behavior.
Thank you Andrew for taking the time and responding to my questions.
Much appreciated.
On Tue, Sep 15, 2020 at 2:01 AM Andrew Yourtchenko
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 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
> 43304310
> > 0001010600502d14 0310
> >
> > 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
> > {8-sra-inbound-sasefwpro-nags-explicit-deny-8}
> >
> > 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
> > {9-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
> > {9-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:
> > 0800 refcount 4
> >
> > 1:
Re: [vpp-dev] Question about acl match/permit behavior.
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 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 43304310
> 0001010600502d14 0310
>
> 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
> {8-sra-inbound-sasefwpro-nags-explicit-deny-8}
>
> 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
> {9-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
> {9-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:
> 0800 refcount 4
>
> 1:
> 00ff 0e00 refcount 24
>
> 2:
> 0800 refcount 2
>
> Mask-ready ACL representations
>
> acl-index 0 bitmask-ready layout
>
> applied lc_index list: 1
>
> 0:
> base mask index 0 acl 0 rule 0 action 0
>
> 1:
[vpp-dev] Question about acl match/permit behavior.
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 43304310
0001010600502d14 0310
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 {8-sra-inbound-sasefwpro-nags-explicit-deny-8}
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 {9-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 {9-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:
0800 refcount 4
1:
00ff 0e00 refcount 24
2:
0800 refcount 2
Mask-ready ACL representations
acl-index 0 bitmask-ready layout
applied lc_index list: 1
0:
base mask index 0 acl 0 rule 0 action 0
1:
0800 base mask index 0 acl 0 rule 1 action 0
acl-index 1 bitmask-ready layout
applied lc_index list: 1
0:
0006 0201 base mask index 1 acl 1 rule 0 action 2
1:
0006 0a01 base mask index 1 acl 1 rule 1 action 2
2:
0011 0201 base mask index 1 acl 1 rule 2 action 2
3:
0011 0a01 base mask index 1 acl 1 rule 3 action 2
4:
0001 0201 base mask index 1 acl 1 rule 4 action 2
5:
0001 0201 base mask index 1 acl 1 rule 5 action 2
acl-index 2 bitmask-ready layout
applied lc_index list: 0
0:
0006 0201 base mask index 1 acl 2 rule 0 action 0
1:
