05-29-2012 04:03 PM - edited 03-07-2019 06:58 AM
Hi Guyz,
I set up the attached pic in my Lab and then made a tunnel between R1 and SW1 for OSPFv3.
my network already has ipv4 ospf running and all ip addresses are reachable from anywhere in the network.
ipv6 unicast-routing is enabled on my devices, sdm prefer dual-ipv4-and-ipv6 default is set on the switches, and reloaded. OSPFv3 instance is set.
Tunnel 1 is up - up. ip addresses ping-able. but as for the OSPFv3 Adj i get these messages between R1 and SW1:
May 29 14:27:26.978: %OSPFv3-5-ADJCHG: Process 1, Nbr 8.8.8.8 on Tunnel1 from EXSTART to DOWN, Neighbor Down: Too many retransmits
followed by:
May 29 14:28:26.980: %OSPFv3-5-ADJCHG: Process 1, Nbr 8.8.8.8 on Tunnel1 from DOWN to DOWN, Neighbor Down: Ignore timer expired
I did everything i could think about, but no luck...!
Any ideas?
thanks.
Soroush.
Solved! Go to Solution.
05-30-2012 02:55 PM
Hello Soroush,
Routers stuck in ExStart state very often exhibit MTU mismatch. It is possible that your SW1 is configured for a different MTU, typically 1504 bytes, while the router uses the MTU of 1500 bytes. OSPF indicates the MTU size in DBD packets exchanged during the ExStart/Exchange state, and drops all DBD packets whose indicated MTU is larger than the receiving interface's MTU. That could theoretically be responsible for the issue you are experiencing.
Please try to use the ipv6 ospf mtu-ignore command on both Tunnel interfaces and see if that helps.
Best regards,
Peter
05-30-2012 02:30 PM
Seriously? no body knows or has no idea??!
05-30-2012 02:55 PM
Hello Soroush,
Routers stuck in ExStart state very often exhibit MTU mismatch. It is possible that your SW1 is configured for a different MTU, typically 1504 bytes, while the router uses the MTU of 1500 bytes. OSPF indicates the MTU size in DBD packets exchanged during the ExStart/Exchange state, and drops all DBD packets whose indicated MTU is larger than the receiving interface's MTU. That could theoretically be responsible for the issue you are experiencing.
Please try to use the ipv6 ospf mtu-ignore command on both Tunnel interfaces and see if that helps.
Best regards,
Peter
05-30-2012 05:40 PM
Thx Peter, tried that mtu-ignore didnt work!
there was some 2611XM and 3550's involved in my scenario, i narrowed it down to just using 1841 and 3560's. turned out to be working flawless !
Im retrying with my previous plan again to see if it was the equipment or some other problms, i'll keep you posted...
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide