[j-nsp] A low number of Firewall filters reducing the bandwidth capacity.

[Timur Maryin]

On 26-Aug-24 15:43, Gustavo Santos via juniper-nsp wrote:
> Awesome, thanks for the info!
> Rules are like the one below.
> after adjusting the detection engine to handle as /24 network instead of
> /32 hosts the issue is gone..
> As you said the issue was not caused by pps as the attack traffic was just
> about 30Mpps and with adjusted rules to /24 networks
> there were not more dropped packets from PFE.
> 
> Did you know or have how to check the PPE information that should show what
> may have happened?


EA utilization monitoring might not be straightforward on a first look
But we have internal tools(script) which print data in nicely manner.
JTAC may be able to share that.

But the key point here is filter optimization.
Filter can be re-arranged so that PPE spend less cycles processing each 
packet.


> Below a sample rule that was generated ( about 300 of them via netconf that
> caused the slowdown).
> 
>        set term e558d83516833f77dea28e0bd5e65871-match from
> destination-address 131.0.245.143/32
>                  set term e558d83516833f77dea28e0bd5e65871-match from


converting (and renaming long term name) that to more readable:

# show
term term1-match {
     from {
         destination-address {
             131.0.245.143/32;
         }
         packet-length 32-63;
         protocol 6;
         source-port 443;
         tcp-flags "syn & ack & !fin & !rst & !psh";
     }
     then {
         count Corero-auto-block-term1-match;
         port-mirror;
         next term;
     }
}
term term1-action {
     from {
         destination-address {
             131.0.245.143/32;
         }
         packet-length 32-63;
         protocol 6;
         source-port 443;
         tcp-flags "syn & ack & !fin & !rst & !psh";
     }
     then {
         count Corero-auto-block-term1-discard;
         discard;
     }
}

As you can see match conditions are duplicated in two terms.
I suspect addition optimization is possible in your filter.

General recommendations (not rules to follow) are:

-group similar terms
-group matches on the same protocol
-instead of large number of "small" terms for different host make one 
term with list of them
-try to arrange them by tuple matching, start with 2tuple terms then 
3tuple and so on.
- where possible put higher terms which will be hit by most of traffic


> As it is a "joint" solution by Corero / Juniper, they were supposed to know
> how to optimize or know platform limitations.
> Opened a Case with Corero to verify if they know something about that.


They are supposed but it's quite possible who develop such solutions are 
not aware of all PFE internals.