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 18.104.22.168
Unit 2 is running ExtremeXOS version 22.214.171.124
Everything about the basic OSPF configuration is matching:
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 126.96.36.199. 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 188.8.131.52
Switch 2 is running ExtremeXOS version 184.108.40.206
I don't know why the first pair of switches I've mentioned have this trouble.
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.