Performance Made Easy – Turn off State Sync

Wow, this is an obvious one I got from a CP performance guy Watcha.

DNS/HTTP/icmp…not sure what others have redundancy built into the protocol. If a packet does not go through layer 7 application layer will resend. DNS/HTTP/icmp are probably 75% of most your traffic so they are filling the state tables. WHY???

If a cluster fails over and the state tables are all hosed up…DNS/HTTP/icmp may hesitate for 1 second but will retry at the layer  7 level. So WHY??? keep them in the state table. WHY make the members share HTTP information over the SYNC cable. Get rid of all that crap.

Turn this off for protocols that are redundant at the application 7 layer. SNMP, NTP, etc…but they are probably only a fragment of your traffic. FTP you want to keep enabled and probably database connections (NOT SURE).

dns

Advertisements
Post a comment or leave a trackback: Trackback URL.

Comments

  • Henrik  On March 25, 2015 at 3:42 pm

    But have you actually noticed any difference?
    I have not on various clusters – max being perhaps a 4 core open server pretty loaded with http traffic.

    /Henrik

  • Whatcha McCallum  On March 25, 2015 at 11:13 pm

    This will really depend on the amount of connections on your firewall. In 99% of cases (Not a proven number) it is certainly not necessary to sync these protocols. HTTP and DNS were designed to handle the internet. The Internet is inherently a very volatile environment with paths and routes changing constantly. The DNS and HTTP clients themselves are designed to retry connections automatically without end user interaction.

    The performance gains on your gateways will very greatly depending on your environment. It is certainly a waste of CPU cycles to process the synced traffic that will likely be terminated milliseconds later.

    fw ctl pstat has a great stat
    dropped updates as a result of sync overload: 0

    If this number is increasing on your cluster, disabling sync of HTTP and DNS is a great place to start.

    Also if you are dealing with a very large amount of DNS requests over your gateway, you could consider the placement of your own DNS servers. Likely placing them on the side of your clients could help cut down on thousands of unnecessary requests traversing your gateways.

    One more thing to point out is the setting right below the one pointed out by Mr. Dreezman. The delayed SYNC option can be used to help cut down on the sync if you are nervous about cutting it out all together. This setting will not sync until the configured time has elapsed. So if you connection is short lived, you save the CPU cycles, if the connection happens to last longer, then it will sync and will survive a cluster fail over.

    If you are uncertain on what the best option is for you, please consult your Check Point rep or friendly Check Point support engineer.

    • Dreezman  On March 26, 2015 at 6:27 am

      Wow, this man needs a blog. Whatcha that was great! Thanks!

  • Bob Mog  On May 5, 2015 at 10:51 pm

    This will cause major problems if you do this for most other applications (outside of HTTP and DNS) and databases. Most applications found on core networks will break and dont handle silent out of state drops well.

    See my comment here:
    https://dreezman.wordpress.com/2015/03/25/cluster-sync-cable-tricks/#comments

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

blog.lachmann.org

Michael Endrizzi's - St. Paul MN - CheckPoint blog on topics related to Check Point products and security in general.

%d bloggers like this: