Healthcheck script results

[Ilmo_Anttonen]

Hi,

I just tried out the new healthcheck script on a production system and some of the 'warning' messages it produced are not clear to me what to do with. Partial output below:

# Core File Checks:
##########################
Usermode Cores:
-rw-r--r-- 1 admin root  35M Jun 29 12:33 DAService.5410.core.gz
-rw-r--r-- 1 admin root  77M Aug 30 09:29 DAService.623.core.gz

Core files detected on this system.
Please upload the following to Check Point for analysis:
 -Current cpinfo from this system
 -Usermode core files from /var/log/dump/usermode/

When I ran the script on a lab machine it also detected core files but that rendered no warning message. What's wrong with this and why should they be uploaded for analysis?

# Fragments Checks:
##########################
Expired – denotes how many fragments were expired when the firewall failed to reassemble them in a 20 seconds time frame or when due to memory exhaustion, they could not be kept in memory anymore.

This environment is struggling a little with high CPU caused by IPS not bypassing SQL-traffic even when instructed so, resulting in some packet loss at times. Could this have anything to do with the fragment checks warning? If no i'm lost as what to do with this message.

/ firstpost.

[Timothy_Hall]

DAService is the CPUSE Deployment Agent daemon that allows upgrades and hotfix applications to be executed from the Gaia web interface and clish.  Seems like it is always being updated (and it updates itself automatically) so I wouldn't be too worried about core dumps for this daemon hanging around, unless they are for the latest build which is currently 1405.

As far as the CPU utilization issue, if traffic is fragmented it is ineligible for any acceleration whatsoever and will always be handled in the Firewall Path (F2F).  Commands such as fw ctl pstat and fwaccel stats -p can be used to see how many fragments are being handled by the firewall.  While you can't control fragments arriving from the Internet, you really should correct any situations causing fragmentation on networks that you have control over.

--
My Book "Max Power: Check Point Firewall Performance Optimization"
Second Edition Coming Soon

[Ilmo_Anttonen]

Many thanks!

I’ll look into the fragmentation problem. 

[Timothy_Hall]

This handy tcpdump filter from my book should help you track down where the fragments are coming from, and includes the MAC address of the device that is sending them to the firewall:

tcpdump -eni any '((ip[6:2] > 0) and (not ip[6] = 64))'

--
My Book "Max Power: Check Point Firewall Performance Optimization"
Second Edition Coming Soon

[Alon_Alapi]

Hi Ilmo,

Can you please share more information on this script (syntax of running the script, script location, what was the trigger for you to run it etc.).

I want to see how the usability can be improved.

Thanks,

Alon

Diagnostics Group Manager

[Ilmo_Anttonen]

Hi Alon,

I got this script from our companys channel rep at Check Point and immediately wanted to try it out. So I followed the instructions from sk121447. I uploaded the script to user/home with winscp, chmoded it and ran with './healthcheck.sh'. I ran the script on a standalone VM lab machine with eval license.

I have a new client where I have scheduled an upgrade from their R77.30 environment to R80.10 next week. So, I thought i'd let them know about the tool and asked them to run the tool before the upgrade to see if anything of interest showed up, that needed fixing before the upgrade. I also thought it would be interesting to compare the script results before and after upgrade. Unfortunately I don't know where they placed the tool nor how they ran it. I provided them with the link to the SK article. Most likely they followed the instructions. They then sent me the log files. The output and questions from the OP are regarding the clients environment.

[Daniel_Moore]

Checkpoint TAC has an additional tool for doing healthchecks‌ "Check Point CPM Doctor tool". Rather robust summary of pain points.