We see all routes for a split second and then we then receive these errors on the 7.5 router: received wrong LS Ack for inter-area-prefix 10.10.0.0 10.10.9.14 0x80000006 expected 0x80000007.
This then brings DOWN the gre tunnel entirely, which is very interesting as without OSPF the tunnel is stable.
After this the gre tunnel comes back online and we start the loop again.
default-v2 { version: 2 router-id: x.x.x.13 } backbone { 0.0.0.0 } interface { p2p x.x.x.13%l2tp-x} neighbor { router-id: x.x.x.254 state: Full } received wrong LS Ack for router x.x.x.13 x.x.x.13 0x80000382 expected 0x80000383
Bumpbump, on between any 7.11.2.
(the so called +1 , 2 -> 3)Code: Select alldefault-v2 { version: 2 router-id: x.x.x.13 } backbone { 0.0.0.0 } interface { p2p x.x.x.13%l2tp-x} neighbor { router-id: x.x.x.254 state: Full } received wrong LS Ack for router x.x.x.13 x.x.x.13 0x80000382 expected 0x80000383
Not for me. I'm using MT as a VPN concentrator and I don't have NAT configured and still receiving "wrong LS Ack" messagesBumpbump, on between any 7.11.2.
(the so called +1 , 2 -> 3)Code: Select alldefault-v2 { version: 2 router-id: x.x.x.13 } backbone { 0.0.0.0 } interface { p2p x.x.x.13%l2tp-x} neighbor { router-id: x.x.x.254 state: Full } received wrong LS Ack for router x.x.x.13 x.x.x.13 0x80000382 expected 0x80000383
Responding to myself... ymmv, masqurade / nat seems to cause this (internal interfaces). Probably shouldn't, quite certainly a default type of logic bug.
Referenced here (without the +1 "received wrong LS Ack for router" keywords, why it can't be found, crossposting):
NAT killing OSPF
default-v2 { version: 2 router-id: 10.200.199.131 } area10-v2 { 0.0.0.10 } interface { p2p 172.23.253.9%VLAN18 } neighbor { router-id: 10.200.199.130 state: Full } received wrong LS Ack for router 10.200.199.131 10.200.199.131 0x80001186 expected 0x80001187
Regarding similar messages but for "received wrong LS Ack for router"Thank you for the report. It is cosmetical bug and does not influence OSPF working. It is reported to our specialists but currently I can't provide ETA.
If there is ROS version on v6 on one router and v7 - on the second side and adjacency is formed - then yes, it is same issue.
What's new in 7.13beta3 (2023-Nov-24 13:52):
...
*) ospf - fixed LSA Type3 advertisement for OSPFv2;
Hopefully 7.14 can fix this???This is a minor problem and is not fixed yet. You will receive a notification when the problem is resolved.
it is reported, but as it was mentioned it has very low priority, I cannot say when it will be fixed.
This mistake will result in its own specific and unique error message, will it not? Seems like there are at least 5 different variants of this log message all being thrown into the one discussion here...Same here
7.14.2... and it was showing the same error when maintaining adjacency with 6.49.8. Investigated, and ineed the router-id was duplicated in the network. Modified it and it never gave error again
THIS was my solution. ROUTING > Router ID > Add >I recently encountered this problem after a network overhaul. Turns out I had accidentally used the same router-id on two different routers. Might try checking to confirm that all your routers have a unique OSPF router-id.