ClusterXL topology - member interface names - Gaia config vs. CP topology

[Tobias_Moritz]

Hello Community,

my team and I are using CP products for a very long time, so we just know how some things always worked, but this does not have to be true in modern versions 🙂

Todays question to you folks, is about the good old network topology regarding ClusterXL.

We are pretty sure that in the past, ClusterXL member interface names in Check Point network topology had to match the actual interfaces names in Gaia OS. Otherwise there were issues with ClusterXL. The name of the cluster interface did not matter, but the member interfaces names. I even found old reddit threads were this dependency was discussed in R80 days.

We recently saw a ClusterXL system running R81.20 T84 which had ClusterXL member interface names not matching Gaia OS interface names and we could not see ClusterXL problems.

I did not found any official documentation regarding this. What is your knowledge folks? Is this still a dependency?

[ProxyOps]

Even if the dependency is no longer there between ClusterXL and Gaia OS, it is heresy to NOT have matching names 😁

I did not see any SK that would indicate that this dependency has been desolved

[_Val_]

Hi @Tobias_Moritz, any chance you can provide an example of those non-matching names?

[Tobias_Moritz]

gateway> show configuration interface
set interface eth3 state on
add interface eth3 vlan 400
[...]
set interface eth3 state on
set interface eth3 auto-negotiation on
set interface eth3.400 state on
set interface eth3.400 ipv4-address 10.aa.bb.2 mask-length 24
set interface eth3.400 ipv6-address 2001:aaaa:bbbb:cccc::2 mask-length 64
 

 

[the_rock]

Hey Tobias,

Interesting finding...personally, I had never seen that myself. Out of curiosity, what appliance is this?

Andy

[Tobias_Moritz]

No appliance, but bare metal open server (from CP HCL).

I asked the ops team: Interface mapping was correct at the time when "get interfaces [without topology]" was used years ago but later on, the interfaces were renumbered during reininstallation from ISO due to major upgrade. Reinstallation instead of CPUSE upgrade was done to get the new file system. They just forgot to update the topology and because ClusterXL does not throw errors about this missmatch, it  was not detected until now, when someone saw it by accident.

Question is: Is the dependency between ClusterXL member interface names and Gaia interfaces names officially removed in modern versions? Or is it just a bug, that it works despite the missmatch? 🙂

[the_rock]

I would be also very curious to find out the official answer. I know this could also be confusing to some, so I really appreciate you bringing it up.

Andy

[the_rock]

Did yopu end up opening TAC case to verify this?

Andy

[_Val_]

Could you please also provide output from "fw ctl iflists"  & "cphaprob -a if" commands?

[Tobias_Moritz]

[Expert@gateway:0]# fw ctl iflists
 Usage: fw ctl command args...

[Expert@gateway:0]# fw ctl iflist
1 : eth2
2 : eth0
3 : eth1
4 : eth3
6 : eth5
9 : eth3.792
10 : eth3.490
11 : eth3.909
12 : eth3.693
13 : eth3.590
14 : eth3.793
15 : eth3.402
16 : eth3.601
17 : eth3.600
18 : eth3.591
19 : eth3.401
20 : eth3.611
21 : eth3.603
22 : eth3.493
23 : eth3.692
24 : eth3.593
25 : eth3.592
26 : eth3.602
27 : eth3.491
28 : eth3.492
29 : eth3.400
30 : eth3.610
31 : eth3.494
[Expert@gateway:0]# cphaprob -a if

CCP mode: Manual (Unicast)
Required interfaces: 6
Required secured interfaces: 1


Interface Name:      Status:

eth2                 UP
eth0                 UP
eth1 (S)             UP
eth5                 UP
eth3.909             UP
eth3.400             UP

S - sync, HA/LS - bond type, LM - link monitor, P - probing

Virtual cluster interfaces: 26

eth2            10.aa.bb.cc        VMAC address: 00:1C:7F:00:AA:BB
                2001:aaaa:bbbb:cccc::dd
                fe80::aa:0:0:abcd
eth0            10.bb.aa.cc        VMAC address: 00:1C:7F:00:AA:BB
eth5            199.199.199.199        VMAC address: 00:1C:7F:00:AA:BB
                2001:aaaa:bbbb:eeee::dd
                fe80::bb:0:0:abcd
eth3.792        10.cc.bb.aa       VMAC address: 00:1C:7F:00:AA:BB
                2001:aaaa:bbbb:ffff::dd
                fe80::cc:0:0:abcd
eth3.490        10.bb.cc.aa         VMAC address: 00:1C:7F:00:AA:BB
                2001:aaaa:bbbb:dddd::dd
                fe80::dd:0:0:abcd
...

[Daniel_Hainich]

for a long time my interface names were different. in gaia it was like bond1.vlan and in dashboard i named the interface dmz.vlan

within migration to maestro i found the sk that the names should match. but i never had problems with different names - or i never noticed.