Skip to main content
AlexFeren
AlexFeren
New Member
October 7, 2015
Question

KB "Wrong firewall policy sequence will cause high CPU during policy add/modify"

  • October 7, 2015
  • 2 replies
  • 3828 views

Fortinet recently published (according to my RSS feed, 1st October) "Wrong firewall policy sequence will cause high CPU during policy add/modify" implying that for optimum performance during business-as-usual provisioning of firewall policies, most popular rules should be placed topmost in Policy sequence and in fact it is a "wrong firewall policy sequence" methodology to do it otherwise.

The issue I have is that Policy sequence dictates order of matching to traffic, and a policy that matches most traffic is most likely to be most general and hence be at the bottom. In fact, as per FortiOS Handbook for FortiOS 5.2.4, section 'Policy order', "... make sure that the more specific or specialized a policy is, the closer to the beginning of the sequence ..."

I feel that publication an KnowledgeBase like this is evidence that Fortigate's Policy-related algorithms are insufficiently engineered. Or, perhaps, I'm missing logic that justifies it?

    2 replies

    emnoc
    emnoc
    New Member
    October 7, 2015

    Quoting the B

     

    "more than 2,000 firewall policies in the same VDOM"

     

    Unless you have more than 2K  policies, I don't see this being a big event. All changes should be done at low oeak hours regardless and more so in big  firewall systems imho.

     

    gschmitt
    gschmitt
    New Member
    October 7, 2015

    AlexFeren wrote:

    implying that for optimum performance [...] most popular rules should be placed topmost in Policy sequence

    Well to me that makes perfect sense.

    Think of it like that:

    switch (packetMachesID) {
    case PolicyID1:
        usePolicy1();
        break;
    case PolicyID2:
        usePolicy2();
        break;
    default:
        deny();
    }

    Of course it uses less CPU load if the traffic matches on the first comparison instead of performing 2001 comparisons

    Terms & ConditionsAccessibility statement