Failed to Build a Cluster Interface OSPF

[Herr_O]

Hi @ all,

I'm having a strange configuration issue during a hardware refresh. When I tried to set up a cluster interface, it was detected twice, namely in the following format:

eth1.123 VIP:10.20.20.121, Node1:10.20.20.119, Node2:noIP
eth1.123 VIP:noIP, Node1:noIP , Node2:10.20.20.119

So I deleted the second one and corrected the first one to

eth1.123 VIP:10.20.20.121, Node1:10.20.20.119, Node2:10.20.20.120

Afterward, the cluster crashed due to ARP problems. Upon closer inspection, I discovered that (for some reason) OSPF was installed on the eth1.123 interfaces in the cluster.

Node1:

add interface eth1 vlan 123
set interface eth1.123 state on
set interface eth1.123 ipv4-address 10.20.20.119 mask-length 28
set ospf instance default
interface eth1.123 area 0.0.0.51 on
set ospf instance default interface eth1.123 priority 1
set ospf instance default interface eth1.123 authtype cryptographic key 1 algorithm md5 secret .....

Node2:

add interface eth1 vlan 123
set interface eth1.123 state on
set interface eth1.123 ipv4-address 10.20.20.120 mask-length 28
set ospf instance default interface eth1.123 area 0.0.0.51 on
set ospf instance default interface eth1.123 priority 1
No key

OSPF is not configured on the opposite switch!!!

Maybe someone can explain to me

-why the configuration didn't cause any problems during operation (I assume the OSPF configuration was added after the cluster was build)

-eth1.123 was not recognized as a cluster interface. The OSPF configuration shouldn't have affected this?

Thank you very much for your effort,

Herr_O

[_Val_]

SW and HW details? What are you replacing? how did you configure the new appliances? Or do you still work with the older appliances?

[Herr_O]

Sorry Val! 
All  Devices Work with R81.20 T98. We did a Fallback  & had to deconfigure the ospf settings on the old devices also.  Only afer this  did the cluster work again. Unfortunatly then time was running out....

I suspect that the OSPF settings were implemented on the running system at some point for testing purposes. The rollback was probably only on the switches, not the checkpoints. But so far no one has been able to deny or confirm this. 

Unfortunately, I now have to provide technical evidence to prove my assumption before repeating the change.

[Herr_O]

HW

Old: 5600
New: 9100

[_Val_]

So, how did you configure the new appliances? FTW and then copy/paste config from the older ones? 

OSPF does not run on switches; it is for routers, as far as I know, but it does not matter. It might be that someone played with it and broke the config in the process.

I would recommend taking the new appliances in the lab, cable them fully and test before production replacement. And of course, you need to figure out whether you need that OSPF in the first place. Check the dynamic routing status to see if it is talking to external routers, before dismissing it. If not, clean it from the config in the lab, ir even as text, before applying to the new boxes.

[Herr_O]

Hi Val, I'm configuring it using copy/paste.
The switch is a Layer 3 switch with routing functionality. My mistake in the description. 

I do not have physical access to the machines, but am waiting for lab time to at least be able to recreate the misconfiguration there in order to identify the exact problem more precisely.