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