Create a Post
Showing results for 
Search instead for 
Did you mean: 
Champion Champion

R80.x Performance Tuning and Debug Tips – TCPDUMP vs. CPPCAP

What is CPPCAP?

TCPDUMP is a Linux tool which at times is not suitable for use with Gaia. Running TCPDUMP causes a significant increase in CPU usage and as a result impact the performance of the device. Even while filtering by specific interface or port still high CPU occurs. Check Point created a tool which works better with Gaia OS.


More interesting articles:

- R80.x Architecture and Performance Tuning - Link Collection
- Article list (Heiko Ankenbrand)


Tip 1 

"CPPCAP" is a traffic capture tool which provides the most relevant outputs and is similar to Tcpdump. The tool is adjusted to Gaia operating system yet requires installation of an applicable RPM.

The good news! SecureXL can be enabled or disabled to capture with CPPCAP.

You can download this tool for R77.30, R80.10 and R80.20. Get more details here: sk141412

Instal and use:

  1. Download the RPM package (sk141412) and transfer the RPM package with winscp to appliance or open server.
  2. Install the RPM using the following command:
    # rpm -ivh --force --nodeps <RPM_FILE>
    # /etc/init.d/start_cppcap start
  3. Start cppcap to sniffing packages (for example on interface eth0 with parameter "N"):

    On internal Interface (example "ping" from client IP to server IP
    cppcap -i eth0 -N  |grep ICMP

        On external Interface:

        # cppcap -i eth2 -N  |grep ICMP


- To have all verbos information add "-DNT" to the syntax to filter out specific interface or VS by using capital letters.
- It will provide outputs on ARP IPV4/IPV6, TCP and UDP traffic. Dynamic routing information will not show all verbose information.

Tip 2

In and out (see red marked point in picture):

In       - Is the incoming packet on the firewall on the inbound interface from the point of view of the first packet. It is simalary to fw monitor inspection point "i" client to server packet.

Out    - Is the outgoing packet on the firewall on the inbound interface from the point of view of the first packet. It is simalary to fw monitor inspection point "O" server to client packet.

On the outgoing interface (see blue marked point in picture), the view is exactly inverse.

Tip 3

Flag Explanation
 -vV VSID                    lowercase to capture only from specific VSID, uppercase for all exec pt VSID
 -iI DEVICE  lowercase to capture only from specific DEVICE, uppercase for all execpt DEVICE         
 -d DIR  capture specific direction ('in' for inbound, 'out' for outbound)
 -f "EXPR"  filter specific expression, for syntax, see pcap-filter(7)
 -o FILE  save capture to a FILE
 -c NUM  capture up to NUM bytes of frame (default 96, '0' for any size)
 -p NUM  capture NUM frames before stopping
 -b NUM  capture NUM bytes before stopping
 -D  verbose datalink layer
 -N  verbose network layer
 -T  verbose transport layer
 -Q  omit time from output


15 Replies

Will this integated in the next jumbo hotfix for R80.10, R77.30?




FYI: As said in the CPPCAP tool cannot be run on 32 bit systems, only on 64 bit systems.

Currently this is not written in the sk141412 

Update 11/12: SK team modified the SK, under solution it is now stated: "Note: The tool is supported only on 64 bit OS."




Interresting information.

Is it also with fw monitor?

0 Kudos

Great post!

After installing the RPM, trying to start it causes an error. why is that?

# rpm -ivh --force --nodeps /home/admin/Check_point_R80.20_cp_pcap_sk141412.rpm
Preparing... ########################################### [100%]
1:cp_pcap ########################################### [100%]
# /etc/init.d/start_cppcap start
insmod: error inserting '/lib/modules/cppcap/cppcap_kern_64.o': -1 Unknown symbol in module
Failed to find major number for cppcap


0 Kudos

I faces the same issue and I did this.....

Delete the file...

#rm -r /lib/modules/cppcap/cppcap_kern_64.o

Stop the service

#/etc/init.d/start_cppcap stop

Uninstall it

#rpm -e cp_pcap


Now just reinstall and start....

#rpm -ivh --force --nodeps Check_point_R80.30_3.10_cp_pcap_sk141412.rpm

#/etc/init.d/start_cppcap start

This time prompt cameout without any error.

Hope this helps.


0 Kudos

Hi Heiko, I'm the author of cppcap,

You don't need to use grep icmp like "cppcap -i eth2 -N  |grep ICMP", for That you can simply run 'cppcap -i eth2 -N -f "icmp"'

0 Kudos
Legend Legend

Hi @Aviad_Hadarian,

Really loving the new cppcap tool, and I'm trying to understand the major differences between cppcap and tcpdump.  I have a few questions and assumptions that I was hoping you could look at:

1) cppcap is using libpcap for the actual grab of packets just like tcpdump correct?

2) It seems like the main advantages of cppcap over tcpdump are the ability to capture only to/from a specific VS, the ability to see direction (In|Out) and interface name in the CLI output, and the ability to capture traffic on VTI's.    Are there other major advantages to cppcap over tcpdump?

3) Can you be a bit more specific about how cppcap has less overhead than tcpdump, I assume it is mainly the ability to capture only from one VS (-Vv) on VSX systems?  Or erphaps that cppcap only captures the first 96 bytes of packets by default, instead of tcpdump and fw monitor that capture the whole thing?

4) Check Point added the -eP option to tcpdump to overcome a limitation in the standard tcpdump that did not allow the interface name to be displayed in the CLI output.  Are there other "hidden" command line switches Check Point added to tcpdump beyond -eP that might be useful?

5) Did anything change in cppcap for the R81 release?  I can see that capture output size can be limited in R81 (-w) and there are some file rotation settings, anything else new?

6) Does cppcap have any kind of indication that the capture taken was not complete due to overload, similar to the "packets dropped by kernel" counter tcpdump shows at the end of a capture?

7) Can cppcap capture VLAN tagged frames?  There are reports that it cannot here:

😎 Any chance cppcap might have trouble with NAT on the outbound side of the firewall as described here: sk100194: TCPdump shows wrong IP addresses for NATed traffic when SecureXL is enabled and sk100071: "tcpdump" output does not show the NATed IP address correctly. Does this problem not happen anymore for tcpdump?


Gateway Performance Optimization R81.20 Course
now available at
0 Kudos

1. cppcap is using libpcap to match packets according to filter.

2. Isn't it enough :)?

3. tcpdump by default captures 96 bytes (same as cppcap), use '-c' to capture the different packet size, It just works differently from tcpdump on how packets are copied from the NIC into the tool itself.

4. I'm not familiar with those tcpdump addons

5. Indeed, Capture file size and rotation (including number of files) has been added, As well As details SCTP traffic.

6. No such indication.

7. I'm not familiar with such limitation.

0 Kudos
Legend Legend

Hi Aviad thanks so much for the answers!  Just FYI the default snaplen for tcpdump 4.9.0 included with Gaia 3.10 appears to now be 262144 bytes, whereas the default snaplen for tcpdump 3.9.4 included with Gaia kernel 2.6.18 was 96 bytes, so the default behavior has changed under the new Gaia kernel.

Also have you seen any issues with cppcap showing the correct post-NAT address similar to the issues tcpdump had with that as mentioned in sk100194 and sk100171 referenced above?  It seems like this was an issue with SecureXL fixed in R80.10+, but just curious if you have heard about anyone running into it again given the major SecureXL changes in R80.20+.  Thanks!

Gateway Performance Optimization R81.20 Course
now available at
0 Kudos

Hi @Timothy_Hall , sk100194 is relevant to R7x versions (which are no longer supported) I did not encountered such issues like you described on newer versions.

0 Kudos

Does anyone know why I receive duplicated traffic?

0 Kudos

what do you mean, duplicated?

0 Kudos

Like this one.

0 Kudos


Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events