topic Re: ClusterXL issue with MDPS enabled in Firewall and Security Management

ClusterXL issue with MDPS enabled

the_rock — Sat, 17 Jan 2026 12:56:15 GMT

Hey guys,

I really hope someone might be able to give some sigguestion/opinion on this, as to me, it makes no logical sense why this fails...could be because of mdps, not really sure. Anyway, to make long story short, customer is replacing their existing 4 15000 fws with new 4 9700 devices (2 separate clusters). We did migrate export from existing mgmt, imported to new one, connected both new clusters, built basic policy after setting up mdps, with ONLY 2 interfaces active (mgmt and sync).

But, here is the problem. Though policy is fine, when installed, only fw1 sdhows as active and fw is down (same on both clusters). We just assigned 169.254.x.x IPs as sync, since customer wanted to give it IP from same mgmt subnet, but that cannot work.

Oddly enough, pings to sync IP work from both members, but fw2 always shows as down...we tried cphastop; start, cprestart, reboot,. disable/re-enable cluster, no dice.

Worked with TAC, they kept telling us its layer 2 iussue, but I cant really understand how that can be the problem. Client even verified everything on of their Fortigates as well, all is allowed and even he was surprised they were "forcing" layer 2 argument.

Thoughts?

Thanks as always!

Re: ClusterXL issue with MDPS enabled

Vincent_Bacher — Thu, 15 Jan 2026 16:14:43 GMT

sorry for n00b like questions:

Both show themselves as active and mate as down?
Ping works and arp entry of mate present?
No drops in fw ctl zdebug + drop seen?

Re: ClusterXL issue with MDPS enabled

the_rock — Thu, 15 Jan 2026 16:24:32 GMT

Those are valid questions, Vince. So, fw2 member ALWAYS shows as down, just fw1 as active and if you try failover, same thing. Ping works and arp is fine and yes, no zdebug drops seen.

Oddly enough, even policy itself allows all communication between clusters, as well as access from internal networks. Its 3 rules in network layer and 2 in urlf layer, thats it.

Re: ClusterXL issue with MDPS enabled

Vincent_Bacher — Thu, 15 Jan 2026 16:32:58 GMT

Maybe some cluster kernel debugs shows something interesting?

https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_NextGenSecurityGateway_Guide/Topics-FWG/Kernel-Debug/Module-cluster.htm

Re: ClusterXL issue with MDPS enabled

the_rock — Thu, 15 Jan 2026 16:35:46 GMT

I should probably ask TAC about it. Problem is that since these are brand new fws, they are not in production yet, so I dont want customer to lose access to them via ssh, since they are located in another wing of the hospital and he does not have console access, so could be tough to reconnect if that happened.

Re: ClusterXL issue with MDPS enabled

Bob_Zimmerman — Thu, 15 Jan 2026 17:34:23 GMT

@the_rock wrote:

... built basic policy after setting up mdps, with ONLY 2 interfaces active (mgmt and sync).

This sounds like a problem. Management and sync are both typically on the mplane namespace, so your dplane namespace has no interfaces to do CCP heartbeats. The dplane namespace isn't getting CCP from the peer, so I would expect it to want to be down.

Re: ClusterXL issue with MDPS enabled

the_rock — Thu, 15 Jan 2026 17:44:28 GMT

Hey Bob,

Im not at all familiar with MDPS myself, but to me, logically anyway, seems that Sync would be on dplane, since thats how we did IP change from clish, since web UI is not available once we install policy.

This is what TAC gave us to configure initially.

set mdps interface Sync sync on

set mdps interface Mgmt management on

set mdps mgmt plane on

set mdps resource cpus 4

set mdps mgmt resource on

Re: ClusterXL issue with MDPS enabled

Vincent_Bacher — Thu, 15 Jan 2026 17:52:57 GMT

Just researched the web and what you stated seems to be valid.

Re: ClusterXL issue with MDPS enabled

the_rock — Thu, 15 Jan 2026 18:19:09 GMT

Seems like it, yes. But, here is my question...can we somehow make this work in the meantime with below config?

set mdps interface Sync sync on

set mdps interface Mgmt management on

set mdps mgmt plane on

set mdps resource cpus 4

set mdps mgmt resource on

Re: ClusterXL issue with MDPS enabled

Vincent_Bacher — Thu, 15 Jan 2026 18:40:40 GMT

I wonder if there might be a way to temporarily config an interface to have one active interface in the Dplane, even by configuring a temporary isolated VLAN on the attached switches?

Re: ClusterXL issue with MDPS enabled

the_rock — Thu, 15 Jan 2026 18:42:38 GMT

I can ask them, though not sure that might be doable atm. Currently, sync is simply connected with straight thru cable, no switch involved.

Re: ClusterXL issue with MDPS enabled

Bob_Zimmerman — Thu, 15 Jan 2026 18:46:14 GMT

On all of my clusters with working MDPS, the management and sync interfaces are owned by the mplane namespace (like VSID 0). The dplane namespace (functionally VSID 1) has all the other interfaces.

The separation is whether the interface is for traffic the member should send/receive for itself, versus traffic the cluster should carry for other endpoints. The member sends/receives sync traffic for itself, so that goes in mplane.

Re: ClusterXL issue with MDPS enabled

the_rock — Thu, 15 Jan 2026 18:48:47 GMT

In the meantime, with the config I sent, is there any way to make this work or you dont think so?

Re: ClusterXL issue with MDPS enabled

Vincent_Bacher — Thu, 15 Jan 2026 18:57:48 GMT

I am not familiar with mdps as well but you may ask tac if you can start with standard cluster and later enable it again?

Re: ClusterXL issue with MDPS enabled

the_rock — Thu, 15 Jan 2026 18:58:59 GMT

Let me see what TAC says. I gave them all the info I have.

Re: ClusterXL issue with MDPS enabled

Bob_Zimmerman — Thu, 15 Jan 2026 19:01:33 GMT

I don't think there's a way to get it to go Active/Standby like this, but with no data interfaces, the cluster state seems irrelevant. Could be considered a cosmetic issue for now.

Re: ClusterXL issue with MDPS enabled

the_rock — Thu, 15 Jan 2026 19:08:52 GMT

Forgive me for my ignorance, as I dont know much about how mdps works, but itns technically Sync dplane in this case? I say that since ONLY way to change IP was to make sure we were in dplane, rather than mplane.

Re: ClusterXL issue with MDPS enabled

the_rock — Thu, 15 Jan 2026 19:45:25 GMT

Thats where Im not clear, because to me, seems Sync would be on dplane...

Re: ClusterXL issue with MDPS enabled

Gennady — Fri, 16 Jan 2026 09:43:00 GMT

Good day!

The one thing that draw my attention is the APIPA address used for the Sync interface. An intuition told me that most probably you cannot use APIPA as a static address for Sync.

Quick check in a Lab shows that indeed we have ACTIVE/DOWN only because of the IP-addresses.

I have changed eth4-1(used for Sync) IP-address from

172.16.18.1/24 (23800_1) and 172.16.16.2/24 (23800_2)

169.254.1.50/24 (23800_1) and 169.254.1.51 (23800_2)

As a result, I got Active/Down from both ends after cpstop/cpstart. Your problem is replicated successfully. There is no MPDS used at all.

RFC 3927 states that 169.254.0.0/16 network is for automatic IP-address configuration. I may guess that Checkpoint follows the guideline and doesn't allow to configure an IP-address from this range manually.
Similar point is stated in sk179028

These IP subnets are reserved (you cannot use them in the CIN IP ranges):

0.0.0.0 / 8
127.0.0.0 / 8
169.254.0.0 / 16
192.0.2.0 / 24
224.0.0.0 / 4
203.0.113.0 / 24

Please, send my best regards to TAC engineers and don't make any unnecessary actions until you try to assign non-APIPA address for the Sync!

Re: ClusterXL issue with MDPS enabled

the_rock — Fri, 16 Jan 2026 12:17:10 GMT

@Gennady

I would have to disagee with that statement and here is why I say that. I had used 169.254.x.x range many times in the lab for sync, never had an issue. Had who knows how many customers do the same, always worked like a charm. As a matter of fact, we did try use different subnet for sync, had exact same problem, so Im fairly positive problem is something with mdps, I just cant figure out what exactly.