Fifo errors

[gm446]

Hello,

i am having an issue with increasing rx drops on the Internet interface.
the Security Gateway is brand new and installed only a week, the appliance is 6900 Plus model (not clustered) who replaced a 7 years old 6600 gateway which not present this kind of errors. (configurations are exactly the same)
version of SMS and the Gateway is R80.40 take 180.

netstat -i shows RX-DRP errors on the interface
eth7 1500 0 329723032 0 16865 16865 247209762 0 0 0 BMRU

ethtool -S eth7 | grep error shows the number of RX-DRP (16865) on
rx_missed_errors: 16865
rx_fifo_errors: 16865

i will love to get some help on investigate this issue.

Thank you in advance, Yossi.

[the_rock]

Can you send the output of cpconfig and corexl info section?

[gm446]

Hi, thank you for the fast response.

Configuring Check Point CoreXL...
=================================

CoreXL is currently enabled with 14 IPv4 firewall instances.

(1) Change the number of firewall instances
(2) Disable Check Point CoreXL

(3) Exit
Enter your choice (1-3) :

[the_rock]

K, so that seems to be the default I believe, if it says 14, thats fine. What is eth7 used for? You can also run below and see what you get:

cat $FWDIR/conf/fwaffinity.conf

fw ctl affinity -l -r -v -a

Reference links:

https://community.checkpoint.com/t5/General-Topics/Automatic-sim-affinity-deprecated-in-R80-40/m-p/1...

https://community.checkpoint.com/t5/Scalable-Chassis/File-edit-FWDIR-conf-fwaffinity-conf/m-p/153237...

[gm446]

cat $FWDIR/conf/fwaffinity.conf

looks like all interfaces have multi queue enabled

[the_rock]

Forgot to mention, can you also run ethtool -i eth7 and under cpconfig, when you press corexl, if you do option 1, do NOT change anything, just curious, what is max number it lets you set firewals instances to? I am pretty sure its 16...

[gm446]

driver: igb
version: 5.3.5.18
firmware-version: 1.63, 0x800009f9
expansion-rom-version:
bus-info: 0000:04:00.1
supports-statistics: yes
supports-test: yes
supports-eeprom-access: yes
supports-register-dump: yes
supports-priv-flags: no

you are right i am actually can increase to 16 CoreXL

[the_rock]

Can you run mq_mng  -vv  --show  Tim Hall gave in one of the links I posted and see what it shows? I also did below in my lab, but of course it wont work, as its just esxi server in the lab, but yours would 100%

quantum-firewall> set interface eth0 multi-queue auto
No multiqueue supported interfaces available

quantum-firewall>

Also, as Chris mentioned, that sk is good reference. 

[Chris_Atkinson]

Which versions were each appliances running?

In some scenarios additional RX-DRPs are expected but perhaps not here e.g.

sk166424: Number of RX packet drops on interfaces increases on a Security Gateway R80.30 and higher with Gaia kernel 3.10

[gm446]

R80.40 Take 180

both old and new firewalls with the same version. this issue was not present in the old firewall

[the_rock]

Honestly, since reading all your answers, it suggests to me this is concerning, and I would be as well if I were you, I would open TAC support case and have them verify everything. 

[gm446]

thank you, i opened an SR.

[the_rock]

Please keep us posted how this gets solved, as we like to post those things...just the spirit of the community, as it helps others. As my good friend says, we are all brothers from different mothers helping each other out : - )

[gm446]

🙂

Of course I will update as soon as I find a solution

[Timothy_Hall]

FIFO errors shown by ethtool matching the RX-DRP counter indicate legitimate full ring buffer drops, and not unknown protocols arriving on the interface and being dropped as mentioned in sk166424.  You almost certainly need to adjust your default static CoreXL split from 2/14 to 4/12 or something like that due to a probably large amount of fully-accelerated traffic and limited number of blades enabled as shown by enabled_blades.  Will need to see Super Seven outputs to be sure.  However your drop rate is 0.005% which is well below the <0.1% threshold where you need to worry about it; these probably piled up during a period of high load such as a policy installation and are not a constant ongoing concern.  Use sar -n EDEV to see when the RX-DRP counter is being incremented.

[the_rock]

@gm446 ...what Tim suggested is an excellent idea, superseven would definitely give us much better idea, for sure.

[_Val_]

RX Drops mean that your NIC is dropping frames on the receiving side. Check the interface settings and the buffer side, plus multi-queue, then drill further based on the results