I have a 450G running 5.2 that has an established OSPFv2 session with a Cisco 3560 that is having problems dropping.
On the Cisco side, I see:
Oct 26 05:24:54: %OSPF-5-ADJCHG: Process 1, Nbr 209.x.x.14 on Vlan84 from FULL to EXSTART, SeqNumberMismatch
Oct 26 05:24:54: %OSPF-5-ADJCHG: Process 1, Nbr 209.x.x.14 on Vlan84 from EXSTART to EXCHANGE, Negotiation Done
Oct 26 05:24:54: %OSPF-5-ADJCHG: Process 1, Nbr 209.x.x.14 on Vlan84 from EXCHANGE to LOADING, Exchange Done
Oct 26 05:24:54: %OSPF-5-ADJCHG: Process 1, Nbr 209.x.x.14 on Vlan84 from LOADING to FULL, Loading Done
On the 450G, I see:
OSPFv2 neighbor 209.x.x.x: state change from FULL to DOWN.
The OSPF session then comes right back up, but this is causing connected routes on the 450G to drop. I have numerous other 450G's in the field that have OSPF sessions with Cisco gear running same/similar code with no issues. There is no packet loss between routers that could be causing the OSPF drops that we are aware of.
Cisco says this about "SeqNumberMismatch":
Has anyone else seen this? If so, what can I do to try and remedy this problem? Are there any more details that I can provide?A. The OSPF neighbor was changed state from FULL to EXSTART because of the receipt of a Database Description (DBD) packet from the neighbor with an unexpected sequence number. SeqNumberMismatch means that a DBD packet during OSPF neighborship negotiation has been received that either:
* has an unexpected DBD sequence number
* unexpectedly has the Init bit set
* has an Options field differing from the last Options field received in a Database Description packet.