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 <de...@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@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/