Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Collaborator

How to get interface status of particular time slot

Hi Team,

Our checkpoint cluster devices change suddenly there are status Active to Standby and Standby to Active. I check the log from smartview tracker and i found this 

"Record Details

cluster_info: (ClusterXL) member 1 (172.16.251.1) is down (Interface Active Check on member 1 (172.16.251.1) detected a problem (eth4.20 interface is down, 7 interfaces required, only 6 up).)."

 So how to get interface status of particular time slot ?

Currently detected interface is up 

Thanx 

20 Replies
Highlighted
Admin
Admin

It's not necessarily an interface up/down thing.

Start with this SK: Interface flapping (down/up) in a ClusterXL environment 

Highlighted
Collaborator

Thank you Dameon, but I'm not able to see the solution right now Smiley Sad 

0 Kudos
Highlighted

it does not mean necessary that the interface went down , probably ccp packet was not heard for a period of time , in my opinion the best way is still to check on the switch if the link went down you will have 100% accuracy with that Smiley Happy and beware of igmp snooping switch side

Highlighted
Collaborator

Hi Marco,

Thank you for your reply, can u explain what is CCP packet ?

BR

0 Kudos
Highlighted

clustering packet that are sent over all clustered interface used to detect when a failover between cluster member is needed sent on port 8116 with a multicast mac address if I remember correct

0 Kudos
Highlighted
Champion
Champion

Our ccc Script provides a solution:

show routed cluster-state detailed - Show ClusterXL failover history"

Additionally CPView provides history data that you can show via: cpview -t <timestamp>

SmartLog is also a great place to check for Cluster failovers.

Highlighted
Collaborator

Thank you Danny. I checked with Cpview, it didn't indicate the interface down

0 Kudos
Highlighted
Contributor

I think the best way to know if the physical interfaces went down is at /var/log/messages. Grep for "down" to filter the results.

Increase the number of rotated /var/log/messages as per sk36798.

Highlighted
Advisor

If the interface is eth4.20, I'm assuming that eth4 is configured as a trunk port going up to the Firewall from the switch? Are there other VLANS besides 20 defined on eth4? If there are, and those stayed up, it sounds like that VLAN had some issue. Maybe there was a spanning tree event on VLAN 20 that cause some CCP packets to get missed? 

R80 CCSA / CCSE
0 Kudos
Highlighted
Collaborator

Hi Daniel,

Yes there is one Vlan. At particular time all interface are up according to CPView. 

0 Kudos
Highlighted
Champion
Champion

Prashan,

I am not sure what version you are running, but there was an issue with r77.30 prior to Take_189, described here:

Adding a new VLAN with lowest/highest VLAN ID causes the ClusterXL member to go "Down" 

which may be applicable to your situation.

0 Kudos
Highlighted
Collaborator

Hi Vladimir,

It is R77.30 T286, btw thank you for the SK

0 Kudos
Highlighted
Champion
Champion

Please verify which mode the CCP is working in: multicast or broadcast.

If it is a multicast, in some instances and with some switches, complications are caused by the treatment of igmp.

I.e. Switch drops Check Point CCP packets when CCP is working in multicast mode 

You can always switch to broadcast mode to eliminate the multicast as a culprit:

How to set ClusterXL Control Protocol (CCP) in Broadcast / Multicast mode in ClusterXL 

Highlighted
Advisor

We had an issue with multicast on Cisco Nexus 7k's and VPC where some VLANS would just intermittently go down. Changing CCP to broadcast resolved our issues.

R80 CCSA / CCSE
Highlighted
Champion
Champion

Yep. When TAC troubleshooting clustering issues, this is typically one of the first steps they take.

I personally, like the multicast mode and was using it with HP ProCurve enterprise switches.

With Cisco it is hit or miss, depending on platform, iOS version, topology, etc..

I am curious if the unicast mode will be made available at some point for HA only clusters. I believe this is the only supported mode in vSEC.

In VSLS situations, you'll need the broadcast or multicast, but in HA only, unicast would work cleaner.

0 Kudos
Highlighted
Admin
Admin

I've been doing this long enough to remember the days when sync was unicast. Smiley Happy

I believe in the NG timeframe was when they changed sync to be multicast.

That's also when ClusterXL became a thing.

Note that even if sync is unicast, you still need multicast for the floating IP address.

In public clouds, which don't support multicast at all, we have to implement the "floating IP" concept differently (using API calls to change routing tables).

Highlighted
Collaborator

Thnx Vladimir

0 Kudos
Highlighted

Hi,

we had this particular issue also, but on physical interfaces. if the eth4.20 is your sync interface (hope it's not btw) you could check using Smartlog as mentioned before.

In our case it was caused by high CP loads, which caused missed CCP packets. this issue doesn't appear only when doing a policy install does it?

0 Kudos
Highlighted
Collaborator

Yes eth4.20 is one our sync interface.

Please find the log screenshot as follow

0 Kudos
Highlighted
Champion
Champion

Can you explain to me the need to have the VLAN 20 tagged on the eth4 for SYNC interface if this is the only VLAN defined on it?

This just seem to add complexity to your environment without any tangible benefits.

ClusterXL does support SYNC via VLAN:

"In ClusterXL, the synchronization network is supported on the lowest VLAN tag of a VLAN interface. For example, if three VLANs with tags 10, 20 and 30 are configured on interface eth1, interface eth1.10 may be used for synchronization."

Since this is a SYNC interface in HA environment, if possible, use direct patch between cluster members.

If you have to traverse switches, have the switch ports configured in access mode (if Cisco: switchport access vlan 20)  and use eth4 for SYNC without sub-interface.