Challenge: OSPF neighbor changing state from DOWN to DOWN
I’ve had an interesting discussion with Nicolas who optimized my OSPF neighbor loss EEM applet assuming the OSPF-5-ADJCHG message reports only OSPF neighbor state transitions from DOWN to FULL and from FULL to DOWN. I knew I'd seen stranger messages in my lab and was able to produce these ones after fumbling with OSPF configurations of two routers connected with a serial link:
*19:34:42.765: %OSPF-5-ADJCHG: Process 1, Nbr 10.0.1.1 on Serial1/0 from → EXSTART to DOWN, Neighbor Down: Too many retransmissions *19:35:42.773: %OSPF-5-ADJCHG: Process 1, Nbr 10.0.1.1 on Serial1/0 from → DOWN to DOWN, Neighbor Down: Ignore timer expired
The messages are repeated approximately every three minutes (using the default OSPF timers).
Here's the challenge: what was going on and how was I able to produce these messages?
5 comments:
MTU Mismatch
dbd packets are being filtered/dropped for some reason such as:
mtu mismatch.
access-list if you block unicast OSPF between the boxes you'll get exactly the symptoms ...
Hay,
Too many retransmissions - buggy line
Neighbor Down: Ignore timer expired - ospf message-digest-key is configured only one side
-jumbo
There is hidden "ignore" timer. If neighbor do something wrong its ignored for period of that timer.
How too reproduce this: on one of two routers connected by Ethernet interfaces filter unicast (but not multicast) packets of ospf protocol in both directions - routers will periodically establish two-way adjacency, but they can't exchange their databases...
MTU mismatch prevent establishing adjacency
sol
1-(config)#system mtu routing "mtu_value"
or
2-(config-if)#ip ospf mtu ignore
Zico
This blog is using JS-Kit comments. You have to enable JavaScript if you want to post a comment.