[c-nsp] Troubleshooting OSPFv3 "Neighbor Down: Too many retransmits"

[Brian Spade]

You might be hitting bug CSCsx54082.  Neighbors end up in an DBD exchange
loop.  Is CPU utilization increasing when the neighbors are in this
condition?

/bs

On Tue, Mar 1, 2011 at 11:01 AM, Devon True <devon at noved.org> 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/
>