Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 

Blocking the connection before final rule match: CPEarlyDrop

This widget could not be displayed.
5 Comments
_Val_
Admin
Admin

Nice one

Ewald_Beekman
Participant

So, is disabling optimization (as described in the SK) the only way to find out which rule is responsible for dropping the traffice?

Timothy_Hall
Champion
Champion

Depending on the size of your rulebase you may be able to eyeball it, but yes you must disable this optimization to see the drop rule number.  Essentially what happened is all rules with an Accept/Allow action were "thrown out" by Column-based Matching leaving only rules with drop actions; this "early drop" rulebase behavior was covered in my book:

 

Click to Expand

One interesting side effect of this new column-based policy evaluation technique is
the possibility for what is known as an “early drop” to occur. Suppose that candidate
traffic is being column-matched against a rulebase, and all rules with an Accept/Allow
action were excluded. In other words, the only surviving rules after the column-based
evaluation had Drop/Block as an action. In that case the traffic will of course be dropped
and logged, but no matching rule number will be present in the log entry.

While we generally don’t care about this situation since the packet was dropped
anyway, the lack of a logged rule number that caused the drop action can be a bit
confusing when attempting to troubleshoot. This “early drop” behavior can be disabled
if needed by toggling the up_early_drop_optimization kernel variable as
specified here: sk111643: Early Drop - dropping connection before final rule match

 

 

Stealth
Explorer

I can see that I'm going to be disabling/enabling this multiple times a day, followed by unnecessary policy installs. Surely, there is a way of letting us know which of the rules are blocking it without jumping through all of these hoops?

biskit
Advisor

I have this issue with some traffic randomly being dropped.

"Enable drop optimization" is off on the gateway.

I've also ran fw ctl set int up_early_drop_optimization 0 as per sk111643 (it was set to 1 before).

I'm still getting the early drops in the log.

What else can I do to find out what's actually dropping this traffic?