<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic CoreXL Causes R80.10 VEN GW Policy Installation Fail in General Topics</title>
    <link>https://community.checkpoint.com/t5/General-Topics/CoreXL-Causes-R80-10-VEN-GW-Policy-Installation-Fail/m-p/6357#M735</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi All,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I have deployed R80.10 HA Gateways on VMWare (Private Cloud). Each have 5 vCPUs assigned and are using ClusterXL.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Everything works perfectly with CoreXL disabled, however when I enable CoreXL for 5vCPU's, policy installation starts to fail with a TCP connectivity failure (port = 18191) error no.10. Disabling CoreXL fixes the policy installation failures.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I've been working with TAC over the past 4 weeks and have completely rebuilt my environment to R80.10 base thinking that it was a corruption issue with the Management Appliance or Firewalls, this has now been proven incorrect. Installing the latest Jumbo Hotfix also had no impact on the issue. A top shows that the CPU utilisation is generally no more than 50% on the active gateway member. Typically I can push policy after hours (sometimes it's intermittent), or on weekends when there is little to no traffic going through them.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I have read that it's best practice for environments with Heavy Logging to assign a dedicated CPU to the FWD process. Can you please advise if this could likely be the way to go here?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I attempted to reduce the CoreXL instances to 3 this morning leaving two free (however not specifically assigning FWD to an available one, refer to attachment, however I started to see alerts on some of my NAT rules and sites published by those rules (not all), stopped working. Disabling CoreXL fixed that issue also.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks for your assistance&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Wed, 20 Sep 2017 00:38:28 GMT</pubDate>
    <dc:creator>Tim_Ireland</dc:creator>
    <dc:date>2017-09-20T00:38:28Z</dc:date>
    <item>
      <title>CoreXL Causes R80.10 VEN GW Policy Installation Fail</title>
      <link>https://community.checkpoint.com/t5/General-Topics/CoreXL-Causes-R80-10-VEN-GW-Policy-Installation-Fail/m-p/6357#M735</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi All,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I have deployed R80.10 HA Gateways on VMWare (Private Cloud). Each have 5 vCPUs assigned and are using ClusterXL.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Everything works perfectly with CoreXL disabled, however when I enable CoreXL for 5vCPU's, policy installation starts to fail with a TCP connectivity failure (port = 18191) error no.10. Disabling CoreXL fixes the policy installation failures.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I've been working with TAC over the past 4 weeks and have completely rebuilt my environment to R80.10 base thinking that it was a corruption issue with the Management Appliance or Firewalls, this has now been proven incorrect. Installing the latest Jumbo Hotfix also had no impact on the issue. A top shows that the CPU utilisation is generally no more than 50% on the active gateway member. Typically I can push policy after hours (sometimes it's intermittent), or on weekends when there is little to no traffic going through them.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I have read that it's best practice for environments with Heavy Logging to assign a dedicated CPU to the FWD process. Can you please advise if this could likely be the way to go here?&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I attempted to reduce the CoreXL instances to 3 this morning leaving two free (however not specifically assigning FWD to an available one, refer to attachment, however I started to see alerts on some of my NAT rules and sites published by those rules (not all), stopped working. Disabling CoreXL fixed that issue also.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks for your assistance&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 20 Sep 2017 00:38:28 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/General-Topics/CoreXL-Causes-R80-10-VEN-GW-Policy-Installation-Fail/m-p/6357#M735</guid>
      <dc:creator>Tim_Ireland</dc:creator>
      <dc:date>2017-09-20T00:38:28Z</dc:date>
    </item>
    <item>
      <title>Re: CoreXL Causes R80.10 VEN GW Policy Installation Fail</title>
      <link>https://community.checkpoint.com/t5/General-Topics/CoreXL-Causes-R80-10-VEN-GW-Policy-Installation-Fail/m-p/6358#M736</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Bit of a shot in the dark here, but I can't recall ever seeing CoreXL enabled on a system with an odd number of total cores.&amp;nbsp; Can you reduce vCPUs to 4 or increase to 6?&amp;nbsp; If not try disabling the Dynamic Dispatcher if you have it enabled.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;--&lt;BR /&gt; My book "Max Power: Check Point Firewall Performance Optimization" &lt;BR /&gt; now available via &lt;A href="http://maxpowerfirewalls.com" target="_blank"&gt;http://maxpowerfirewalls.com&lt;/A&gt;.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 20 Sep 2017 12:09:20 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/General-Topics/CoreXL-Causes-R80-10-VEN-GW-Policy-Installation-Fail/m-p/6358#M736</guid>
      <dc:creator>Timothy_Hall</dc:creator>
      <dc:date>2017-09-20T12:09:20Z</dc:date>
    </item>
    <item>
      <title>Re: CoreXL Causes R80.10 VEN GW Policy Installation Fail</title>
      <link>https://community.checkpoint.com/t5/General-Topics/CoreXL-Causes-R80-10-VEN-GW-Policy-Installation-Fail/m-p/6359#M737</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi Tim,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks for your response on this.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I ran only 4 vCPU's for 4 weeks originally with the same issues, with this configuration I have 4 CoreXL instances enabled.&amp;nbsp;&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The thing that I'm struggling to understand is that if I have 4vCPU Cores, the documentation states that I get 3 Kernal Instances, as one Core is used for SND. Does this mean that when I enable CoreXL, that I enable only 3 CoreXL Instances in order to leave 1 for SND, or do I enable 4 instances, and the gateway will automatically make one of the cores SND only.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;My assumption from reading the doco was that it automatically assigned the SND to 1 core, which is why I enabled CoreXL for 4 instances, when I was running 4 cores. In the case that I now have now, my logic was to assign 5 as it would still assign one to SND automatically. The documentation states that if you have 8 CPU Cores, then two cores will be used for SND, again I thought this would occur automatically by enabling 8 CoreXL instances.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;The configuration that I now am thinking would be optimal for me is for 5 CPU Cores&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;1 x SND&lt;/P&gt;&lt;P&gt;3 x Kernal Instance&lt;/P&gt;&lt;P&gt;1 x FWD dedicated Core&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I'm hoping that I can get clarification on both my approach, but also the exact number of instances to enable through CPConfig.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks again.&lt;/P&gt;&lt;P&gt;Tim&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 20 Sep 2017 23:04:46 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/General-Topics/CoreXL-Causes-R80-10-VEN-GW-Policy-Installation-Fail/m-p/6359#M737</guid>
      <dc:creator>Tim_Ireland</dc:creator>
      <dc:date>2017-09-20T23:04:46Z</dc:date>
    </item>
    <item>
      <title>Re: CoreXL Causes R80.10 VEN GW Policy Installation Fail</title>
      <link>https://community.checkpoint.com/t5/General-Topics/CoreXL-Causes-R80-10-VEN-GW-Policy-Installation-Fail/m-p/6360#M738</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;With 4 total cores on the system, by default you get 3 Firewall Workers (CPUs 1-3) and one SND/IRQ core (CPU 0).&amp;nbsp; In the CoreXL screen of cpconfig this is represented by 3 "Firewall kernel instances" or some such verbiage.&amp;nbsp;&amp;nbsp; The Firewall Workers always take the highest numbered cores, and any left over is/are for SND/IRQ.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;In general you should avoid setting the overall number of Firewall Worker instances to the same number of physical cores, as this will cause the same core(s) to handle both SND/IRQ and Firewall Worker core functions which is grossly inefficient but unavoidable on 1-core or 2-core systems.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;As far as dedicating a core for FWD heavy logging, I'd recommend against it in this case.&amp;nbsp; Typically this is only done if you have at least 12 total cores if not many more.&amp;nbsp; Keep in mind that the firewall logging process can jump on any open core that is not busy in R77.30 to get its work done.&amp;nbsp;&amp;nbsp; However in a major shift for R80.10 gateway, by default all firewall processes are only allowed to jump on an open Firewall Worker core, and may not use the cores assigned to SND/IRQ at all.&amp;nbsp; I'm assuming this was done to permit the relatively small SND/IRQ routines to take up increased residence in the CPU fast caches of the SND/IRQ cores, and not have those caches get constantly trashed by some wayward process looking for an open CPU.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;So for 5 CPUs I'd recommend initially starting with 4 Firewall Worker instances which leaves 1 SND/IRQ core.&amp;nbsp; However if a large percentage of traffic is fully accelerated by SecureXL or there is heavy small-packet burstiness on your NICs, the single SND/IRQ core will get overrun.&amp;nbsp; Symptoms of this will be piling up RX-DRPs in netstat -ni, and extreme CPU utilization on core 0 but nowhere else.&amp;nbsp; In that case decrease Firewall Worker cores from 4 to 3 in cpconfig to allocate another SND/IRQ core.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;--&lt;BR /&gt; My book "Max Power: Check Point Firewall Performance Optimization" &lt;BR /&gt; now available via &lt;A href="http://maxpowerfirewalls.com" target="_blank"&gt;http://maxpowerfirewalls.com&lt;/A&gt;.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 21 Sep 2017 13:46:14 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/General-Topics/CoreXL-Causes-R80-10-VEN-GW-Policy-Installation-Fail/m-p/6360#M738</guid>
      <dc:creator>Timothy_Hall</dc:creator>
      <dc:date>2017-09-21T13:46:14Z</dc:date>
    </item>
    <item>
      <title>Re: CoreXL Causes R80.10 VEN GW Policy Installation Fail</title>
      <link>https://community.checkpoint.com/t5/General-Topics/CoreXL-Causes-R80-10-VEN-GW-Policy-Installation-Fail/m-p/6361#M739</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi Tim,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks for your help with this, thats the most concise answer that I've received from anyone to date.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;I'll try setting the CoreXL CPU's to 4 and let you know how I go.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Cheers&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 21 Sep 2017 23:41:51 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/General-Topics/CoreXL-Causes-R80-10-VEN-GW-Policy-Installation-Fail/m-p/6361#M739</guid>
      <dc:creator>Tim_Ireland</dc:creator>
      <dc:date>2017-09-21T23:41:51Z</dc:date>
    </item>
    <item>
      <title>Re: CoreXL Causes R80.10 VEN GW Policy Installation Fail</title>
      <link>https://community.checkpoint.com/t5/General-Topics/CoreXL-Causes-R80-10-VEN-GW-Policy-Installation-Fail/m-p/6362#M740</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Hi Tim,&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Just wanted to let you know that this resolved the issues that I was having with policy installation by configuring 4 CoreXL instances, and leaving one spare for the SND.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;Thanks again for your assistance.&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;Cheers&lt;/P&gt;&lt;P&gt;Tim&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 04 Oct 2017 03:17:13 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/General-Topics/CoreXL-Causes-R80-10-VEN-GW-Policy-Installation-Fail/m-p/6362#M740</guid>
      <dc:creator>Tim_Ireland</dc:creator>
      <dc:date>2017-10-04T03:17:13Z</dc:date>
    </item>
    <item>
      <title>Re: CoreXL Causes R80.10 VEN GW Policy Installation Fail</title>
      <link>https://community.checkpoint.com/t5/General-Topics/CoreXL-Causes-R80-10-VEN-GW-Policy-Installation-Fail/m-p/6363#M741</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;Great, thanks for the follow up.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;--&lt;BR /&gt; My book "Max Power: Check Point Firewall Performance Optimization" &lt;BR /&gt; now available via &lt;A href="http://maxpowerfirewalls.com" target="_blank"&gt;http://maxpowerfirewalls.com&lt;/A&gt;.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Thu, 05 Oct 2017 12:20:24 GMT</pubDate>
      <guid>https://community.checkpoint.com/t5/General-Topics/CoreXL-Causes-R80-10-VEN-GW-Policy-Installation-Fail/m-p/6363#M741</guid>
      <dc:creator>Timothy_Hall</dc:creator>
      <dc:date>2017-10-05T12:20:24Z</dc:date>
    </item>
  </channel>
</rss>

