cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1207
Views
0
Helpful
3
Replies

OSPFv3 tunnel problem

smehrnia
Level 7
Level 7

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.

Hope it Helps!

Soroush.
1 Accepted Solution

Accepted Solutions

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

View solution in original post

3 Replies 3

smehrnia
Level 7
Level 7

Seriously? no body knows or has no idea??!

Hope it Helps!

Soroush.

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

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...

Hope it Helps!

Soroush.
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card