[c-nsp] Troubleshooting OSPFv3 "Neighbor Down: Too many retransmits"
David Rothera
david.rothera at gmail.com
Tue Mar 1 15:20:26 EST 2011
Not too sure if the same applies in OSPFv3 as I haven't rolled it out yet but we had a similar issue with OSPFv2.
We had two routers and the connection kept dropping due to retransmits, the connection between them was fine, not overloaded etc.
To configure OSPF to not tear down the neighbourship you can use:
limit retransmissions non-dc disable
Hope this helps
David
On 1 Mar 2011, at 19:01, Devon True wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> All:
>
> I am troubleshooting an issue between two 7600 routers running
> 12.2(33)SRE3. The ospfv3 session between these two routers keeps going
> down and up. Other ospfv2/v3 sessions on either router do not have this
> problem.
>
> Mar 1 18:44:22 ROUTER notice 4645: Mar 1 13:44:21.465 Eastern:
> %OSPFv3-5-ADJCHG: Process 19271, Nbr x.y.161.253 on GigabitEthernet3/2
> from FULL to DOWN, Neighbor Down: Too many retransmits
> Mar 1 18:45:23 ROUTER notice 4646: Mar 1 13:45:22.926 Eastern:
> %OSPFv3-5-ADJCHG: Process 19271, Nbr x.y.161.253 on GigabitEthernet3/2
> from LOADING to FULL, Loading Done
> Mar 1 18:47:27 ROUTER notice 4647: Mar 1 13:47:26.216 Eastern:
> %OSPFv3-5-ADJCHG: Process 19271, Nbr x.y.161.253 on GigabitEthernet3/2
> from FULL to DOWN, Neighbor Down: Too many retransmits
>
> This occurs approximately every 3 minutes.
>
> Troubleshooting steps I have tried:
>
> * applied ipv6 ospf mtu-ignore
> * removed ipv6 ospf configuration from interface and re-applied
> * passive-interface -> no passive-interface
>
> - -- ospfv3 interface configuration --
>
> ipv6 ospf network point-to-point
> ipv6 ospf cost 350
> ipv6 ospf 1 area 0
>
> - -- show ipv6 ospf neighbor from router logging "too many retransmits" --
>
> #sh ipv6 ospf neighbor g3/2 detail
> Neighbor x.y.161.253
> In the area 0 via interface GigabitEthernet3/2
> Neighbor: interface-id 14, link-local address FE80::106:C2
> Neighbor priority is 0, State is FULL, 6 state changes
> Options is 0x000013 in Hello (V6-Bit, E-Bit, R-bit)
> Options is 0x000013 in DBD (V6-Bit, E-Bit, R-bit)
> Dead timer due in 00:00:38
> Neighbor is up for 00:01:29
> Index 1/7/7, retransmission queue length 4, number of retransmission 19
> First 0x0(0)/0x543B7C10(26714)/0x543B6B80(9515088) Next
> 0x0(0)/0x543B7C10(26714)/0x543B6B80(9515088)
> Last retransmission scan length is 1, maximum is 1
> Last retransmission scan time is 0 msec, maximum is 0 msec
> Link State retransmission due in 529 msec
>
> #sh ipv6 ospf neighbor g3/2 detail
> Neighbor x.y.161.253
> In the area 0 via interface GigabitEthernet3/2
> Neighbor: interface-id 14, link-local address FE80::106:C2
> Neighbor priority is 0, State is DOWN, 7 state changes
> Neighbor ignored, reenable in 00:00:10
> Options is 0x000013 in Hello (V6-Bit, E-Bit, R-bit)
> Index 0/0/0, retransmission queue length 0, number of retransmission 27
> First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0)
> Last retransmission scan length is 1, maximum is 1
> Last retransmission scan time is 0 msec, maximum is 0 msec
>
> Any other things I can look at before opening a TAC case?
>
> - --
> Devon
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.14 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk1tQqUACgkQWP2WrBTHBS9hOQCgj+xxqANnd8lLE85iHxb8lx8B
> 8JYAn3dG5WXiWqN/go3Eo0uNZrWrfEzy
> =oy0Z
> -----END PGP SIGNATURE-----
> _______________________________________________
> cisco-nsp mailing list cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
More information about the cisco-nsp
mailing list