All,
I'm upgrading a VRRP cluster with a client from R80.20 to R80.40.
From the R80.40 installation and upgrade guide documentation I determine that Multi-Version Clustering (MVC) is supported.
As of R80.40 I think, MVC is replacing the Connectivity Upgrade (CU). Thus, session synchronization between two different versions should work.
Following the steps described at (which only describe detailed output for ClusterXL and VSX clusters): R80.40 Installation and Upgrade guide at: Upgrade of Security Gateways and Clusters > Upgrading ClusterXL, VSX Cluster, or VRRP Cluster > Multi-Version Cluster (MVC) Upgrade > Multi-Version Cluster Upgrade Procedure
FW1 = R80.20 / FW2 = R80.40
Cluster object in SmartConsole has been modified to R80.40 and firewall policy has been pushed to FW2 (SIC = OK).
MVC has been activated on FW2 with 'cphaconf mvc on', 'cphaprob mvc' shows 'on'.
FW1 reports:
[Expert@FW1:0]# cphaprob stat
Cluster Mode: Sync only (OPSEC) with IGMP Membership
ID Unique Address Firewall State (*)
1 (local) 192.168.22.5 Active
2 192.168.22.6 Down
(*) FW-1 monitors only the sync operation and the security policy
Use OPSEC's monitoring tool to get the cluster status
[Expert@FW1:0]#
FW2 reports:
[Expert@FW2:0]# cphaprob stat
Cluster Mode: Sync only (OPSEC) with IGMP Membership
ID Unique Address Firewall State (*)
2 (local) 192.168.22.6 Active
(*) FW-1 monitors only the sync operation and the security policy
Use OPSEC's monitoring tool to get the cluster status
[Expert@FW2:0]#
So on the ClusterXL layer, they don't seem to see each other.
While on VRRP layer (network layer) they do:
[Expert@FW1:0]# clish -c "show vrrp summary"
VRRP State
VRRP Router State: Up
Flags: On,MonitorFirewall
Coldstart delay (1 seconds): completed
Interface enabled: 16
Virtual routers configured: 19
In Init state 0
In Backup state 0
In Master state 19
[Expert@FW1:0]#
[Expert@FW2:0]# clish -c "show vrrp summary"
VRRP State
VRRP Router State: Up
Flags: On,MonitorFirewall
Coldstart delay (1 seconds): completed
Interface enabled: 16
Virtual routers configured: 19
In Init state 0
In Backup state 19
In Master state 0
[Expert@FW2:0]#
Troubleshooting further by using the guide 'Troubleshooting the Multi-Version Cluster'
Delta Sync status:
[Expert@FW1:0]# cphaprob syncstat
Delta Sync Statistics
Sync status: OK
Drops:
Lost updates................................. 0
Lost bulk update events...................... 0
Oversized updates not sent................... 0
Sync at risk:
Sent reject notifications.................... 0
Received reject notifications................ 0
Sent messages:
Total generated sync messages................ 79580232
Sent retransmission requests................. 0
Sent retransmission updates.................. 0
Peak fragments per update.................... 1
Received messages:
Total received updates....................... 0
Received retransmission requests............. 0
Queue sizes (num of updates):
Sending queue size........................... 512
Receiving queue size......................... 256
Fragments queue size......................... 50
Timers:
Delta Sync interval (ms)..................... 100
Reset on Thu Jul 2 19:30:47 2020 (triggered by fullsync).
[Expert@FW1:0]#
[Expert@FW2:0]# cphaprob syncstat
Delta Sync Statistics
Sync status: OK
Drops:
Lost updates................................. 0
Lost bulk update events...................... 0
Oversized updates not sent................... 0
Sync at risk:
Sent reject notifications.................... 0
Received reject notifications................ 0
Sent messages:
Total generated sync messages................ 98673
Sent retransmission requests................. 0
Sent retransmission updates.................. 0
Peak fragments per update.................... 1
Received messages:
Total received updates....................... 0
Received retransmission requests............. 0
Sync Interface:
Name......................................... Sync
Link speed................................... 1000Mb/s
Rate......................................... 10600 [Bps]
Peak rate.................................... 10920 [Bps]
Link usage................................... 0%
Total........................................ 770919[KB]
Queue sizes (num of updates):
Sending queue size........................... 512
Receiving queue size......................... 256
Fragments queue size......................... 50
Timers:
Delta Sync interval (ms)..................... 100
Reset on Wed Nov 25 17:09:40 2020 (triggered by fullsync).
[Expert@FW2:0]#
Session table:
[Expert@FW1:0]# fw tab -t connections -s
HOST NAME ID #VALS #PEAK #SLINKS
localhost connections 8158 36317 67622 108849
[Expert@FW1:0]#
[Expert@FW2:0]# fw tab -t connections -s
HOST NAME ID #VALS #PEAK #SLINKS
localhost connections 8158 30 83 14
[Expert@FW2:0]#
As you can see, the number of connection doesn't match at all, they don't come close...
So something is wrong at the ClusterXL layer I would think, while it was function before the upgrade.
What am I missing? Shouldn't the two cluster members see each other (on ClusterXL with cphaprob stat)?
Does anybody have experience with VRRP cluster MVC upgrade?
Thanks!
Kind regards,
Sean
