Observing Broadcast CCP messages when CCP mode is Multicast

[Tom_Cripps]

I am seeing Broadcast packets for CCP from my active gateway on two interfaces even though my CCP method is multicast? Has anyone seen this at all before? 

I'm also seeing RX_DRP and RX_OVR increase the same amount appearing to be in a "lockstep" as described in @Timothy_Hall's books. 

I suspect this may be causing us problems when our current standby member becomes active, as we see irregular behavior when it is handling traffic.

[Timothy_Hall]

Gateway code & kernel version? 

What CCP mode does cphaprob -a if show?

If you are getting RX-DRP/RX-OVR lockstep it usually means to need to add more SND cores and then possibly enable Multi-Queue, but this is version dependent.

[Tom_Cripps]

Hi Tim,

We're running R80.10 on these still and kernel version will still be 2.6

cphaprob -a if shows:

Required interfaces: 8
Required secured interfaces: 1

Sync UP sync(secured), multicast
Mgmt Disconnected non sync(non secured), multicast
eth2-01 UP non sync(non secured), multicast
eth1-01 UP non sync(non secured), multicast
eth1-03 UP non sync(non secured), multicast
eth3-07 UP non sync(non secured), multicast
eth3-03 UP non sync(non secured), multicast
bond0 UP non sync(non secured), multicast, bond Load Sharing
bond1 UP non sync(non secured), multicast, bond Load Sharing

Virtual cluster interfaces: 7

eth2-01 xxxx 
eth1-01 xxxx 
eth1-03 xxxx 
eth3-07 xxxx 
eth3-03 xxxx
bond0 xxxx
bond1 xxxx

These interfaces are not under load though so surely multi-queue or more SND cores won't help? 

[Timothy_Hall]

Tough to say, please provide output of "Super Seven" commands and enabled_blades.

https://community.checkpoint.com/t5/General-Topics/Super-Seven-Performance-Assessment-Commands-s7pac...

[Tom_Cripps]

Enabled Blades:

[Expert@XXXX:0]# enabled_blades
fw vpn mon vpn

Super Seven output is attached Tim. This is from our current standby member also.

[Timothy_Hall]

Please provide the Super Seven run on the active member, I can tell it was run on the standby due to the 100% F2F.

In regards to the high RX-DRP, it may be skewed by the fact that it is a standby member, and you are seeing unknown protocols in your network as mentioned here: https://community.checkpoint.com/t5/General-Topics/core-affinity-R80-40-two-cores/m-p/88834/highligh...

[Tom_Cripps]

Hi Tim,

Thank you getting back in touch, we have identified this being an with the Hardware module we are using. Changing the interface into a new module has resolved this. I suspect there is a problem with the NIC on that module, we are not seeing errors anymore, but are still seeing FWHA_IFCONF_REQ and FWHA_IF_PROBE_REQ requests on the second interface which was erroring, not anymore though.