OSPF neighbour issue

[MartinS]

Hi, 

I have two switches that will not become OSPF neighbours. They are setup as follows:

Stack 1 needs to form an OSPF relationship with Unit 2. 

Stack 1 is running ExtremeXOS version 31.7.1.4
Unit 2 is running ExtremeXOS version 16.2.5.4

Everything about the basic OSPF configuration is matching:

• Area ID
• Subnet mask
• Hello/Dead Timers
• MD5 auth hash     (this is the bit in question)

The two switches can successfully ping each other on the subnet in question.
Neither side will show a neighbour in the 'show ospf neighbour' command output.

I was able to see the logs showing the problem:

05/17/2023 22:46:59.18 <Warn:ospf.hello.PktInv> Vlan1111 receives Hello pkt from 10.10.10.10 failed MD5 auth thru Vlan Vlan1111 keyID 1.

Now, something similar has happened before where I've previously had to downgrade to 16.x.x to be able to enter the ospf authentication command, then upgrade again back to 30.x.x.x to address the issue detailed in this article: https://extremeportal.force.com/ExtrArticleDetail?an=000060447

But what I'm faced with now is different to what that article describes, because I'm not actually getting any error when I go to enter the command: configure ospf vlan Vlan1111 authentication encrypted md5 1 "my_encrypted_key"

So there's obviously a compatibility issue here to do with the MD5 hash, and I am not sure if what we are trying to do here will work. I can't upgrade the Unit 2 running ExtremeXOS version 16.2.5.4. It is at the highest software level. the plan is to replace this Unit 2 with 670 G2s, but we need this to work for now. Is there a way for this to work? 

What I don't understand is that we have another OSPF linked pair with the exact same version differences, and they have become neighbours without issue. They are as follows:

Switch 1 is running ExtremeXOS version 31.7.1.4
Switch 2 is running ExtremeXOS version 16.2.5.4

I don't know why the first pair of switches I've mentioned have this trouble. 

[OscarK]

So this is what I think happens.

The upgrade mangles the MD5 hash, this is a known problem that can be fixed by reconfiguring the MD5 password. It is not that the MD5 hash cannot communicate with a 16.2 MD5 hash, it is just the upgrade that wrongly imports the old hash. After reconfiguring the MD5 on both ends they should see eachother. The fact they see each other without authentication should make this work.

[Alberto_Oter]

What happens if you try to remove the MD5 auth, this could help to discard that is a software issue? Does these OSPF sessions came UP?

[MartinS]

When the MD5 auth is removed, the neighbour relationship does come up, yes. How exactly does this discard it from being a software issue? 

[Alberto_Oter]

Cause the issue is not a compatibility problem between the difference of versions nor hashing, have you tried to use a less complex password first? like "test".