cphaprob syncstat: What is it? What Can you do with it for Check Point Firewalls?

This is a real life example of interesting Check Point Firewalls commands we found:

 

There is a command in the Check Point  world that isn’t widely known:
cphaprob syncstat

It’s for clusters. It’s there to share some stats on how the clustering mechanism is behaving and help identify certain issues. While there’s a Secure Knowledge article about this, we’ve discovered most users either don’t know the command exists or don’t know what to do with the output. Here’s a sample output:

Sync Statistics (IDs of F&A Peers - 1 2 3 4 5 6 7 ):  Other Member Updates: Sent retransmission requests...................165 Avg missing updates per request................1 Old or too-new arriving updates................5661 Unsynced missing updates.......................0 Lost sync connection (num of events)...........4354 Timed out sync connection .....................1  Local Updates: Total generated updates .......................9180670 Recv Retransmission requests...................1073 Recv Duplicate Retrans request.................2564  Blocking Events................................0 Blocked packets................................0 Max length of sending queue....................4598 Avg length of sending queue....................0 Hold Pkts events...............................1 Unhold Pkt events..............................1 Not held due to no members.....................16 Max held duration (sync ticks).................0 Avg held duration (sync ticks).................11  Timers: Sync tick (ms).................................100 CPHA tick (ms).................................100  Queues: Sending queue size.............................512 Receiving queue size...........................256

So – we’ve done quite a bit of work trying to understand what is possible with the stats. We’ve used some documentation made available by Check Point and others, as well as our own analysis. Interestingly, our indeni Insight service was extremely useful as some things we thought were true turned out to be wrong.

For example – we thought that every sync loss (see “Lost sync connection (num of events)” above) was a problem. But no, in almost every policy installation you’ll have up to 6 of these.

At the end of the day, our experience shows that an in-depth analysis of the syncstat can prove very useful for finding possible clustering issues. So, if you’re running into weird clustering issues with Check Point firewalls, take us for a spin, it’s free. If you got to this page because you saw an alert in indeni and are looking for clarification (this syncstat thing can get complicated) – you can use the comments section at the bottom or contact our support (best to simply copy and paste the alert text in the support ticket).

 

Get this and thousands of other checks performed algorithmically, 24/7/365. 

Want to see what indeni can find lurking in your environment? Click the pic below to reserve your spot at our High Availability Webinar:

Check Point Firewalls

indeni is like insurance for your Check Point Firewalls