Re: [c-nsp] OSPFv3 down every 34 minutes
Wow, first of all, thanks to everyone who responded. I didn't expect so many responses on the weekend! One suggestion was to make the interface IPv4 only. I could do this, but I'm not sure what it would get me. The VLAN2 interface runs OSPF and OSPFv3 and only OSPFv3 has this weird problem. The VLAN is not configured as a P2P interface in the OSPFv3 config and I am not using authentication on the v3 OSPF session. I also checked the standby counters and I'm not experiencing any state changes. I also seriously doubt that it's related to periodic traffic - the fact that it's *every* 34 minutes, even overnight when there's just a couple of megs on the wire, I think rules that out. I am also pretty sure that I don't have a Cylon problem. ;-) My MTU sizes all look fine, both in v4 and v6. I just threw a Hail Mary and killed the IPv6/OSPFv3 config on this interface and reconfigured it, so I'll see how that goes. I'll re-visit some of the other suggestions everyone's made once I have some more coffee in me. Thanks again, evt From: Mike Louis [EMAIL PROTECTED] Sent: Sunday, April 13, 2008 9:02 PM To: Mike Louis; Brad Henshaw; Ben Steele; Eric Van Tol Cc: cisco-nsp@puck.nether.net Subject: RE: [c-nsp] OSPFv3 down every 34 minutes What type of link is this running? NBMA or PTP? Are you using authentication on the link? From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Mike Louis [EMAIL PROTECTED] Sent: Sunday, April 13, 2008 7:54 PM To: Brad Henshaw; Ben Steele; Eric Van Tol Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] OSPFv3 down every 34 minutes From what I recall, OSPF does a periodic sanity check every 30 minutes where it flushes its SPF table or something like that. Could this timing be related to something during that process? Wild guess, but I have seen issues with bouncing EIGRP adjacencies that were related to MTU sizes being set incorrectly on Gigabit and 10/100 interfaces facing each other. The problem only occurred when certain packets with DF bit were set. Just a thought. Like I said , wild guess. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brad Henshaw Sent: Sunday, April 13, 2008 7:23 PM To: Ben Steele; Eric Van Tol Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] OSPFv3 down every 34 minutes Ben Steele wrote: might also be worth setting up an ip sla probe Definitely. Since it happens fairly predictably, you should also be able to set the load-interval to 30 on the interfaces connecting to those neighbours and check if there's a momentary increase of traffic on those interfaces when the problem occurs. Can you route around the problem while you troublshoot? (maybe force a high ip ospf cost on the L3 interfaces) Regards, Brad ___ 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/ Note: This message and any attachments is intended solely for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, legally privileged, confidential, and/or exempt from disclosure. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the original sender immediately by telephone or return email and destroy or delete this message along with any attachments immediately. ___ 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/ Note: This message and any attachments is intended solely for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, legally privileged, confidential, and/or exempt from disclosure. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the original sender immediately by telephone or return email and destroy or delete this message along with any attachments immediately. ___ 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/
Re: [c-nsp] OSPFv3 down every 34 minutes
-Original Message- From: Mike Louis [mailto:[EMAIL PROTECTED] Sent: Monday, April 14, 2008 7:22 AM To: Eric Van Tol Subject: RE: [c-nsp] OSPFv3 down every 34 minutes Would you mind posting the show ipv6 ospf interfaces? Any possibility you could get a packet capture during the event that we could look at? I thought I did this already, but looking back, it was just the 'show ipv6 ospf neighbor'. :-/ In any case, my hail mary seemed to work. After removing and reconfiguring IPv6 and OSPFv3 on the interface with the same exact config, the problem appears to have stopped (at least for now). Thanks to all those who responded. -evt ___ 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/
Re: [c-nsp] OSPFv3 down every 34 minutes
Eric Van Tol wrote: In any case, the question now is, what would cause so many neighbors to retransmit and why on only one router? Packet loss or congestion on the physical links/interfaces connecting to this router? Not sure why it'd be every 34 minutes though. If it were every /30/ minutes, the OSPF refresh would be a real suspect. I notice input drops are shown for int vl2. Check these for the relevant physical interface(s) also. ~Brad ___ 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/
Re: [c-nsp] OSPFv3 down every 34 minutes
Hi Brad, Thanks for the response. I saw those drops, but they don't come close to the amount of times this is occurring. This happens literally, every 34 minutes (okay, 33 minutes and some seconds :-) ): Apr 13 06:13:03 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.10 on Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits Apr 13 06:13:03 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.9 on Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits Apr 13 06:13:07 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.11 on Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits Apr 13 06:46:52 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.10 on Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits Apr 13 06:46:53 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.9 on Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits Apr 13 06:46:57 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.11 on Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits Apr 13 07:20:35 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.10 on Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits Apr 13 07:20:36 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.11 on Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits Apr 13 07:20:40 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.9 on Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits Apr 13 07:53:48 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.10 on Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits Apr 13 07:53:49 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.11 on Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits Apr 13 07:53:52 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.9 on Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits Apr 13 08:27:36 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.11 on Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits Apr 13 08:27:37 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.10 on Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits Apr 13 08:27:42 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.9 on Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits Apr 13 09:01:31 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.10 on Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits Apr 13 09:01:31 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.11 on Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits Apr 13 09:01:35 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.9 on Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits The interfaces all show the same info: Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0 On the Vlan2 interface, I show one more drop since I sent the original message on Friday: Input queue: 0/75/17/17 (size/max/drops/flushes); Total output drops: 0 I'm baffled at this point. I'll likely be moving to IS-IS soon, but this is one of those problems that really makes you wonder. From: Brad Henshaw [EMAIL PROTECTED] Sent: Sunday, April 13, 2008 9:13 AM To: Eric Van Tol; cisco-nsp@puck.nether.net Subject: RE: [c-nsp] OSPFv3 down every 34 minutes Eric Van Tol wrote: In any case, the question now is, what would cause so many neighbors to retransmit and why on only one router? Packet loss or congestion on the physical links/interfaces connecting to this router? Not sure why it'd be every 34 minutes though. If it were every /30/ minutes, the OSPF refresh would be a real suspect. I notice input drops are shown for int vl2. Check these for the relevant physical interface(s) also. ~Brad ___ 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/
Re: [c-nsp] OSPFv3 down every 34 minutes
Does a sh standby 1 show any hsrp state changes? might also be worth setting up an ip sla probe to your neighbor for the 34 minutes to probe every second and just see if it fails at all when you lose your OSPF neighbor, that way you can discard OSPF from the problem and look into what is causing your dataflow issue. Ben On 13/04/2008, at 11:10 PM, Eric Van Tol wrote: Hi Brad, Thanks for the response. I saw those drops, but they don't come close to the amount of times this is occurring. This happens literally, every 34 minutes (okay, 33 minutes and some seconds :-) ): Apr 13 06:13:03 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.10 on Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits Apr 13 06:13:03 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.9 on Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits Apr 13 06:13:07 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.11 on Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits Apr 13 06:46:52 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.10 on Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits Apr 13 06:46:53 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.9 on Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits Apr 13 06:46:57 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.11 on Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits Apr 13 07:20:35 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.10 on Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits Apr 13 07:20:36 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.11 on Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits Apr 13 07:20:40 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.9 on Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits Apr 13 07:53:48 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.10 on Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits Apr 13 07:53:49 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.11 on Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits Apr 13 07:53:52 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.9 on Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits Apr 13 08:27:36 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.11 on Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits Apr 13 08:27:37 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.10 on Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits Apr 13 08:27:42 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.9 on Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits Apr 13 09:01:31 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.10 on Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits Apr 13 09:01:31 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.11 on Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits Apr 13 09:01:35 EDT: %OSPFv3-5-ADJCHG: Process 600, Nbr x.x.x.9 on Vlan2 from FULL to DOWN, Neighbor Down: Too many retransmits The interfaces all show the same info: Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0 On the Vlan2 interface, I show one more drop since I sent the original message on Friday: Input queue: 0/75/17/17 (size/max/drops/flushes); Total output drops: 0 I'm baffled at this point. I'll likely be moving to IS-IS soon, but this is one of those problems that really makes you wonder. From: Brad Henshaw [EMAIL PROTECTED] Sent: Sunday, April 13, 2008 9:13 AM To: Eric Van Tol; cisco-nsp@puck.nether.net Subject: RE: [c-nsp] OSPFv3 down every 34 minutes Eric Van Tol wrote: In any case, the question now is, what would cause so many neighbors to retransmit and why on only one router? Packet loss or congestion on the physical links/interfaces connecting to this router? Not sure why it'd be every 34 minutes though. If it were every /30/ minutes, the OSPF refresh would be a real suspect. I notice input drops are shown for int vl2. Check these for the relevant physical interface(s) also. ~Brad ___ 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/
Re: [c-nsp] OSPFv3 down every 34 minutes
Hi Brad, Thanks for the response. I saw those drops, but they don't come close to the amount of times this is occurring. This happens literally, every 34 minutes (okay, 33 minutes and some seconds :-) ): Maybe you have a Cylon infiltrator hiding in your network? :) http://www.scifi.com/battlestar/episodes/episodes.php?seas=1ep=101act=1 In the wake of the Cylon sneak attack, the ragtag fleet of human survivors is forced to play a deadly game of cat-and-mouse with their pursuers. Every 33 minutes, they make a jump to a new location. And every 33 minutes, the Cylons manage to find them. The pilots are on the brink of exhaustion, relying on artificial stimulants to keep fighting, and the civilians are beginning to doubt the leadership of Commander Adama and President Roslin. ___ 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/
Re: [c-nsp] OSPFv3 down every 34 minutes
Ben Steele wrote: might also be worth setting up an ip sla probe Definitely. Since it happens fairly predictably, you should also be able to set the load-interval to 30 on the interfaces connecting to those neighbours and check if there's a momentary increase of traffic on those interfaces when the problem occurs. Can you route around the problem while you troublshoot? (maybe force a high ip ospf cost on the L3 interfaces) Regards, Brad ___ 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/
Re: [c-nsp] OSPFv3 down every 34 minutes
From what I recall, OSPF does a periodic sanity check every 30 minutes where it flushes its SPF table or something like that. Could this timing be related to something during that process? Wild guess, but I have seen issues with bouncing EIGRP adjacencies that were related to MTU sizes being set incorrectly on Gigabit and 10/100 interfaces facing each other. The problem only occurred when certain packets with DF bit were set. Just a thought. Like I said , wild guess. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brad Henshaw Sent: Sunday, April 13, 2008 7:23 PM To: Ben Steele; Eric Van Tol Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] OSPFv3 down every 34 minutes Ben Steele wrote: might also be worth setting up an ip sla probe Definitely. Since it happens fairly predictably, you should also be able to set the load-interval to 30 on the interfaces connecting to those neighbours and check if there's a momentary increase of traffic on those interfaces when the problem occurs. Can you route around the problem while you troublshoot? (maybe force a high ip ospf cost on the L3 interfaces) Regards, Brad ___ 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/ Note: This message and any attachments is intended solely for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, legally privileged, confidential, and/or exempt from disclosure. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the original sender immediately by telephone or return email and destroy or delete this message along with any attachments immediately. ___ 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/
Re: [c-nsp] OSPFv3 down every 34 minutes
What type of link is this running? NBMA or PTP? Are you using authentication on the link? From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Mike Louis [EMAIL PROTECTED] Sent: Sunday, April 13, 2008 7:54 PM To: Brad Henshaw; Ben Steele; Eric Van Tol Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] OSPFv3 down every 34 minutes From what I recall, OSPF does a periodic sanity check every 30 minutes where it flushes its SPF table or something like that. Could this timing be related to something during that process? Wild guess, but I have seen issues with bouncing EIGRP adjacencies that were related to MTU sizes being set incorrectly on Gigabit and 10/100 interfaces facing each other. The problem only occurred when certain packets with DF bit were set. Just a thought. Like I said , wild guess. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brad Henshaw Sent: Sunday, April 13, 2008 7:23 PM To: Ben Steele; Eric Van Tol Cc: cisco-nsp@puck.nether.net Subject: Re: [c-nsp] OSPFv3 down every 34 minutes Ben Steele wrote: might also be worth setting up an ip sla probe Definitely. Since it happens fairly predictably, you should also be able to set the load-interval to 30 on the interfaces connecting to those neighbours and check if there's a momentary increase of traffic on those interfaces when the problem occurs. Can you route around the problem while you troublshoot? (maybe force a high ip ospf cost on the L3 interfaces) Regards, Brad ___ 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/ Note: This message and any attachments is intended solely for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, legally privileged, confidential, and/or exempt from disclosure. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the original sender immediately by telephone or return email and destroy or delete this message along with any attachments immediately. ___ 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/ Note: This message and any attachments is intended solely for the use of the individual or entity to which it is addressed and may contain information that is non-public, proprietary, legally privileged, confidential, and/or exempt from disclosure. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the original sender immediately by telephone or return email and destroy or delete this message along with any attachments immediately. ___ 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/
[c-nsp] OSPFv3 down every 34 minutes
Hi all, Wondering if anyone has seen this yet. I recently upgraded a pair of 6509s to 12.2(18)SXF13 and since then, one of them seems to lose OSPFv3 adjacencies every 34 minutes on the dot. The adjacencies to the three other routers on this *one* particular SVI drop due to too many retransmissions. Debug shows nothing particularly useful besides too many retransmits. I've checked configs on both the 6509s and the adjacent routers and all looks up-to-snuff. The other routers never lose adjacencies with the second 6509 and are all coming in across different physical interfaces. MTUs are correct, no interface errors or drops, no mis-matched timers, etc. Other neighbors have been up for over a week, since I last did a 'clear ipv6 ospf process' after updating OSPFv3 priorities. The outputs below show the 'ipv6 ospf neighbor detail' from the three affected neighbors. The only thing I can think of is that there is a process kicking off every 34 minutes on this one 6509, but I can't figure out what it could be. I was previously on 12.2(18)SXF3 and this wasn't happening. I checked Bug Navigator and couldn't find anything concrete or even similar in SXF13. Any ideas where to look? Thanks, evt ~ interface Vlan2 ip address x.x.x.x 255.255.255.224 no ip redirects no ip unreachables ip ospf authentication-key xxx ip ospf priority 90 ipv6 address x:x:x:x::/64 ipv6 enable ipv6 ospf priority 5 ipv6 ospf 600 area 75 standby 1 ip x.x.x.x standby 1 priority 90 standby 1 preempt standby 1 authentication xx ! Vlan2 is up, line protocol is up Hardware is EtherSVI, address is 00d0.02b6.3400 (bia 00d0.02b6.3400) Internet address is x.x.x.x/27 MTU 1500 bytes, BW 100 Kbit, DLY 10 usec, reliability 255/255, txload 17/255, rxload 10/255 Encapsulation ARPA, loopback not set Keepalive not supported ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of show interface counters never Input queue: 0/75/16/16 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 42406000 bits/sec, 11880 packets/sec 5 minute output rate 68446000 bits/sec, 11553 packets/sec L2 Switched: ucast: 1923473851 pkt, 1081449259861 bytes - mcast: 1839775 pkt, 193492810 bytes L3 in Switched: ucast: 6107349982 pkt, 3277271069494 bytes - mcast: 0 pkt, 0 bytes mcast L3 out Switched: ucast: 6976977824 pkt, 3721569539249 bytes mcast: 0 pkt, 0 bytes 6110601771 packets input, 3277564197885 bytes, 0 no buffer Received 1829472 broadcasts (0 IP multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 6980413289 packets output, 3722016274612 bytes, 0 underruns 0 output errors, 0 interface resets 0 output buffer failures, 0 output buffers swapped out ! sh ipv6 interface vlan 2 Vlan2 is up, line protocol is up IPv6 is enabled, link-local address is FE80::2D0:2FF:FEB6:3400 Global unicast address(es): x:x:x:x:x:x:x:x, subnet is x:x:x:x::/64 Joined group address(es): FF02::1 FF02::2 FF02::5 FF02::6 FF02::1:FFB6:3400 FF02::1:FFBC:D102 MTU is 1500 bytes ICMP error messages limited to one every 100 milliseconds ICMP redirects are enabled ND DAD is enabled, number of DAD attempts: 1 ND reachable time is 3 milliseconds ND advertised reachable time is 0 milliseconds ND advertised retransmit interval is 0 milliseconds ND router advertisements are sent every 200 seconds ND router advertisements live for 1800 seconds Hosts use stateless autoconfig for addresses. ! Neighbor x.x.x.x In the area 75 via interface Vlan2 Neighbor: interface-id 2, link-local address FE80::21B:C0FF:FE56:C502 Neighbor priority is 3, State is FULL, 6 state changes DR is x.x.x.9 BDR is x.x.x.8 Options is 0x56730A1D Dead timer due in 00:00:37 Neighbor is up for 00:10:10 Index 2/4/4, retransmission queue length 0, number of retransmission 0 First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0) Last retransmission scan length is 0, maximum is 0 Last retransmission scan time is 0 msec, maximum is 0 msec Neighbor x.x.x.9 In the area 75 via interface Vlan2 Neighbor: interface-id 111, link-local address FE80::2D0:4FF:FE48:1400 Neighbor priority is 10, State is FULL, 6 state changes DR is x.x.x.9 BDR is x.x.x.8 Options is 0x51A5AF75 Dead timer due in 00:00:30 Neighbor is up for 00:10:11 Index 1/3/3, retransmission queue length 0, number of retransmission 0 First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0) Last retransmission scan length is 0, maximum is 0 Last retransmission scan time is 0 msec, maximum is 0 msec Neighbor x.x.x.11 In the area 75 via interface Vlan2 Neighbor: interface-id 3, link-local address FE80::2D0:63FF:FE2F:7800 Neighbor priority is 1, State
Re: [c-nsp] OSPFv3 down every 34 minutes
Two seconds after I sent this, I realized that the database refreshes every 30 minutes, so that's likely the process that is triggering this. Duh... In any case, the question now is, what would cause so many neighbors to retransmit and why on only one router? -evt -Original Message- From: [EMAIL PROTECTED] [mailto:cisco-nsp- [EMAIL PROTECTED] On Behalf Of Eric Van Tol Sent: Friday, April 11, 2008 9:56 AM To: cisco-nsp@puck.nether.net Subject: [c-nsp] OSPFv3 down every 34 minutes Hi all, Wondering if anyone has seen this yet. I recently upgraded a pair of 6509s to 12.2(18)SXF13 and since then, one of them seems to lose OSPFv3 adjacencies every 34 minutes on the dot. The adjacencies to the three other routers on this *one* particular SVI drop due to too many retransmissions. Debug shows nothing particularly useful besides too many retransmits. I've checked configs on both the 6509s and the adjacent routers and all looks up-to-snuff. The other routers never lose adjacencies with the second 6509 and are all coming in across different physical interfaces. MTUs are correct, no interface errors or drops, no mis-matched timers, etc. Other neighbors have been up for over a week, since I last did a 'clear ipv6 ospf process' after updating OSPFv3 priorities. The outputs below show the 'ipv6 ospf neighbor detail' from the three affected neighbors. The only thing I can think of is that there is a process kicking off every 34 minutes on this one 6509, but I can't figure out what it could be. I was previously on 12.2(18)SXF3 and this wasn't happening. I checked Bug Navigator and couldn't find anything concrete or even similar in SXF13. Any ideas where to look? Thanks, evt ~ interface Vlan2 ip address x.x.x.x 255.255.255.224 no ip redirects no ip unreachables ip ospf authentication-key xxx ip ospf priority 90 ipv6 address x:x:x:x::/64 ipv6 enable ipv6 ospf priority 5 ipv6 ospf 600 area 75 standby 1 ip x.x.x.x standby 1 priority 90 standby 1 preempt standby 1 authentication xx ! Vlan2 is up, line protocol is up Hardware is EtherSVI, address is 00d0.02b6.3400 (bia 00d0.02b6.3400) Internet address is x.x.x.x/27 MTU 1500 bytes, BW 100 Kbit, DLY 10 usec, reliability 255/255, txload 17/255, rxload 10/255 Encapsulation ARPA, loopback not set Keepalive not supported ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of show interface counters never Input queue: 0/75/16/16 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 42406000 bits/sec, 11880 packets/sec 5 minute output rate 68446000 bits/sec, 11553 packets/sec L2 Switched: ucast: 1923473851 pkt, 1081449259861 bytes - mcast: 1839775 pkt, 193492810 bytes L3 in Switched: ucast: 6107349982 pkt, 3277271069494 bytes - mcast: 0 pkt, 0 bytes mcast L3 out Switched: ucast: 6976977824 pkt, 3721569539249 bytes mcast: 0 pkt, 0 bytes 6110601771 packets input, 3277564197885 bytes, 0 no buffer Received 1829472 broadcasts (0 IP multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 6980413289 packets output, 3722016274612 bytes, 0 underruns 0 output errors, 0 interface resets 0 output buffer failures, 0 output buffers swapped out ! sh ipv6 interface vlan 2 Vlan2 is up, line protocol is up IPv6 is enabled, link-local address is FE80::2D0:2FF:FEB6:3400 Global unicast address(es): x:x:x:x:x:x:x:x, subnet is x:x:x:x::/64 Joined group address(es): FF02::1 FF02::2 FF02::5 FF02::6 FF02::1:FFB6:3400 FF02::1:FFBC:D102 MTU is 1500 bytes ICMP error messages limited to one every 100 milliseconds ICMP redirects are enabled ND DAD is enabled, number of DAD attempts: 1 ND reachable time is 3 milliseconds ND advertised reachable time is 0 milliseconds ND advertised retransmit interval is 0 milliseconds ND router advertisements are sent every 200 seconds ND router advertisements live for 1800 seconds Hosts use stateless autoconfig for addresses. ! Neighbor x.x.x.x In the area 75 via interface Vlan2 Neighbor: interface-id 2, link-local address FE80::21B:C0FF:FE56:C502 Neighbor priority is 3, State is FULL, 6 state changes DR is x.x.x.9 BDR is x.x.x.8 Options is 0x56730A1D Dead timer due in 00:00:37 Neighbor is up for 00:10:10 Index 2/4/4, retransmission queue length 0, number of retransmission 0 First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0) Last retransmission scan length is 0, maximum is 0 Last retransmission scan time is 0 msec, maximum is 0 msec Neighbor x.x.x.9 In the area 75 via interface Vlan2 Neighbor: interface-id 111, link-local address FE80::2D0:4FF:FE48:1400
