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

[Tom Beecher]

>
> # 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;
>      }
> }
>

This is still terribly inefficient. It only needs to be matched once, and
you can do the count / mirror / discard in the same stanza.

     then {
         count Corero-auto-block-term1;
         port-mirror;
         discard;
     }

I would assume that the Corero product gives you the option to mirror *OR*
not , and then accept *OR* discard, so whoever coded this just makes one
stanza for each option selected by the user, which is , HOLY SHIT stupid.
Juniper folks who I know are here :  you should REALLY get them to fix this
if you're going to keep pushing that partnership. :)

Trying to replicate an SRX doing heavy SPI on Trio chips can sorta work
depending on the environment, but usually isn't going to be a good idea.
You are 100% not going to maintain line rate when you start checking /32s
and TCP flags. Doing too much is going to crush the chip, as you saw.

Also, a couple people mentioned the FLT block. I would agree that might
have been a good idea, but I am 95% sure the FLT only supports the
traditional 5-tuple, so this couldn't have been loaded there anyways.


On Tue, Sep 10, 2024 at 3:57 PM Timur Maryin via juniper-nsp <
juniper-nsp at puck.nether.net> wrote:

> 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.
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>