CheckPoint VE connectivity issues with standby cluster member

Marcelo_Fontana — Wed, 21 Aug 2019 12:46:08 GMT

After migrating from cluster 80.10 (VSX) to 80.10 (VE), we have identified the following issue with the standby member.

- Zabbix can't collect information.
- Standby member cannot go to internet
- Tacacs authentication does not work.
- Does not receive routes via OSPF

In contact with our SE he reported that another customer who migrated from 77.30 (VE) to 80.10 (VE), started to have this same problem.

We can solve almost all problems by creating no-NAT rules for interface IPs, the only problem that remains is OSPF.

On the active member OSPF works normally, if we fail over the standby member works normally and the standby member has the above problems.

I have already called calling with TAC, and this other client has also called but so far no answers.

Has anyone faced this problem and managed to solve the problem with OSPF?

The error you are experiencing on routerD cluster is due to OSPF.

NOTE :::
Everything works normally on either member since it was active in the cluster.

fw ver
This is Check Point's software version R80.10 - Build 068

---------------------------------------------------------------------------------------------

cphaprob stat

Cluster Mode: High Availability (Active Up) with IGMP Membership

Number Unique Address Assigned Load State

1 172.29.47.2 100% Active
2 (local) 10.172.232.154 0% Down

Local member is in current state since Wed Aug 21 08:48:55 2019

---------------------------------------------------------------------------------------------

cphaprob -l list

Device Name: routed
Registration number: 2
Timeout: none
Current state: problem
Time since last report: 2670.7 sec

---------------------------------------------------------------------------------------------

fw ctl pstat

System Capacity Summary:
Memory used: 10% (1561 MB out of 14950 MB) - below watermark
Concurrent Connections: 30 (Unlimited)
Aggressive Aging is enabled, not active

Hash kernel memory (hmem) statistics:
Total memory allocated: 1564475392 bytes in 381952 (4096 bytes) blocks using 1 pool
Total memory bytes used: 0 unused: 1564475392 (100.00%) peak: 556701100
Total memory blocks used: 0 unused: 381952 (100%) peak: 140227
Allocations: 233296966 alloc, 0 failed alloc, 230282398 free

System kernel memory (smem) statistics:
Total memory bytes used: 2672499956 peak: 2974774852
Total memory bytes wasted: 5024683
Blocking memory bytes used: 5970872 peak: 7632000
Non-Blocking memory bytes used: 2666529084 peak: 2967142852
Allocations: 449971 alloc, 0 failed alloc, 445902 free, 0 failed free
vmalloc bytes used: 2660849364 expensive: no

Kernel memory (kmem) statistics:
Total memory bytes used: 1372718648 peak: 1911725536
Allocations: 233739921 alloc, 0 failed alloc
230722602 free, 0 failed free
External Allocations: 0 for packets, 78677423 for SXL

Cookies:
2052132 total, 0 alloc, 0 free,
1827 dup, 1793398 get, 6635 put,
3263543 len, 0 cached len, 0 chain alloc,
0 chain free

Connections:
25630 total, 7377 TCP, 17328 UDP, 3 ICMP,
922 other, 0 anticipated, 0 recovered, 30 concurrent,
6443 peak concurrent

Fragments:
0 fragments, 0 packets, 0 expired, 0 short,
0 large, 0 duplicates, 0 failures

NAT:
5/0 forw, 0/0 bckw, 2 tcpudp,
0 icmp, 2-167 alloc

Sync:
Version: new
Status: Able to Send/Receive sync packets
Sync packets sent:
total : 87662, retransmitted : 0, retrans reqs : 0, acks : 0
Sync packets received:
total : 0, were queued : 0, dropped by net : 0
retrans reqs : 0, received 0 acks
retrans reqs for illegal seq : 0
dropped updates as a result of sync overload: 0
Callback statistics: handled 6 cb, average delay : 2, max delay : 4

---------------------------------------------------------------------------------------------

show ospf summary

OSPF Router with ID 10.173.30.40 Instance default

SPF schedule delay: 2 secs
Hold time between two SPFs: 5 secs
Number of Areas in this router: 1
Normal: 1 Stub: 0 NSSA: 0
RFC1583 compability mode is on
Number of Virtual Links in this router: 0
Number of UpEvents: 1 Number of DownEvents: 0
Default ASE Cost: 1
Default ASE Type: 1

Area: backbone

Number of Interfaces in this area: 1
Number of ABRs: 0 Number of ASBRs: 0
Number of times SPF Algorithm executed: 2
No Area Ranges Configured
No Area Stubnets Configured

---------------------------------------------------------------------------------------------

show ospf interfaces

Name IP Address Area ID State NC DR Address BDR Address Errors
eth0.3346 10.173.17.30 0.0.0.0 DR 0 10.173.17.30 N/A 0

---------------------------------------------------------------------------------------------

show ospf errors

Hello Protocol Errors

Bad Size 0 Network Mask Mismatch 0
Dead Interval Mismatch 0 Hello Duplicate Router ID 0
External Option Mismatch 0 NSSA Option Mismatch 0
Runt 0 Hello Timer Mismatch 0

Link State Update Errors

Runt 0 LSU Duplicate Router ID 0
LSU TooLow 0 BadCSum 0
BadLSType 0 ASEinStub 0
Type7inNonNSSA 0 LSU TooNew 0
BadLSReq 0 SeqNumWrap 0
Invalid SeqNum 0 SummaryinTotalStub 0
BadRouterLSASize 0 BadNetworkLSASize 0
BadSummaryLSASize 0 BadASELSASize 0
BadType7LSASize 0

Link State ACK Errors

LSAck Duplicate Router ID 0 LSAck TooLow 0
BadSize 0 QuestionAck 0
BadLSType 0

Link State Request Errors

LSR Duplicate Router ID 0 BadSize 0
BadState 0 Empty Request 0

Database Description Errors

ASEinStub 0 Type7inNonNSSA 0
MTU 0 BadLSType 0
NotDuplicate 0 BadSize 0
OptionsMismatch 0 DuplicateLSA 0
DD Duplicate Router ID 0 InitSet 0
Runt 0 MasterMismatch 0
SlaveSeq 0 MasterSeq 0
DD TooLow 0

Protocol Errors

Bad Area ID 0 Area ID Mismatch 0
AuthCryptoSeq 0 AuthKey 0
AuthKeyId 0 AuthKeyTime 0
AuthKeyType 0 BadDestination 0
Checksum 0 NoNeighbor 0
NoOspf 0 Size 0
Version 0 NonLocal 0
VirtualLink 0 NoVirtualNeighbor 0
IfDown 0 PacketType 0
Passive Interface 0 TX 0
ZeroRID 0

IP Errors

Protocol 0 BadSource 0
BadDestination 0 Size 0
NoSuchIndex 0 OwnPacket 0

Re: CheckPoint VE connectivity issues with standby cluster member

PhoneBoy — Wed, 21 Aug 2019 20:40:43 GMT

Why R80.10 and not the recommended R80.20 or R80.30?

Re: CheckPoint VE connectivity issues with standby cluster member

Maarten_Sjouw — Wed, 21 Aug 2019 21:32:04 GMT

Keep in mind that R80.20 can use Unicast for cluster sync traffic, with R80.10 you are stuck with either Multicast or Broadcast. Multicast and clustering in a VM-Ware environment means you need to disable all security on all ports that your gateways are connected to.
OSPF also uses Multicast and will surely fail if the security is not disabled.
Have a look at the output of 'cphaprob -a if' this will show the protocol used and if all interfaces are working properly.
Other piece of advice, my personal experience with dynamic routing is that it works better in combination with VRRP.

topic CheckPoint VE connectivity issues with standby cluster member in General Topics

CheckPoint VE connectivity issues with standby cluster member

Re: CheckPoint VE connectivity issues with standby cluster member

Re: CheckPoint VE connectivity issues with standby cluster member