Re: OSPF dropouts [7:3964]
Brian, Thanks for that - I'm not running CEF at the moment but I'll keep that in mind as I'm sure it will spring on me in the future. As mentioned, there are a few FECNs/BECNs/DEs and a few CRC errors, but nothing too startling. JMcL -- Forwarded by Jenny Mcleod/NSO/CSDA on 11/05/2001 08:45 am --- "Brian" @groupstudy.com on 11/05/2001 12:10:29 am Please respond to "Brian" Sent by: [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: Re: OSPF dropouts [7:3964] I have had similar problems to this with OSPF. Wierd situations where adjacencies would drop out or could not form adjacencies, and yet everything looked good. In one instance it was a layer2 problem, and in the other it had to do with CEF (the feature I have a love/hate relationship with). If your running CEF, it could possibly be doing something here. To me however it smells of l2 problems. I assume you checked "sh frame pvc" and made sure the counters look ok? Brian On Thu, 10 May 2001, [EMAIL PROTECTED] wrote: > Hi all, > This isn't directly certification-related, but maybe people can practise > their trouble-shooting skills. > > I have a frame relay link that occasionally drops the OSPF adjacency across > it (average once a day maybe, but it can go several days with no problems > and then get several hits in a day). Apart from the brief disruption, this > causes the ISDN backup to kick in, which is not something I want to happen > unnecessarily since the call is from one side of Australia to the other : -) > Each access supports other PVCs as well, which do not have problems. > The PVC does not drop out. > > I have debug ip ospf events and debug ip ospf adjacency turned on. One > side will announce that the other neighbour is dead, and start rebuilding > the adjacency. The side that detects the problem first varies. > There are a small number of CRC errors at one end, and some broadcasts are > dropped at the other end, but the numbers are consistent with links > throughout the rest of the network which are problem-free. > Both routers have had the cables re-seated and have been reloaded. > Traffic shaping is in effect and should be preventing traffic from > overloading the smaller access rate. There are some FECN/BECN/DE packets, > but again, nothing at unusual levels. I have no reason to believe that the > traffic pattern on this link is different to others in the network. > > IOS is 11.2. One router is a 7505, the other a 4700M. > > I assume that hellos are being dropped occassionally (and fairly randomly) > across the link, and that sometimes enough in a row get dropped that the > timer expires. The links are monitored via MRTG, and there is some > correlation between increased usage and the problem, but there are plenty > of times of higher utilisation with no problems. Very short-term bursty > traffic may not show up in MRTG, though. > > Any tips on what to check/fiddle with next? My thought is to get the > carrier to check out the link and see whether they can see any problems in > their cloud. I have no doubt the answer will be 'no', but they may fix > something while they're looking :-). > > Ta, > JMcL > FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] > --- We have MOVED!! Make note of our new address!!! I'm buying / selling used CISCO gear!! email me for a quote Brian Feeny,CCDP,CCNP+VAS Scarlett Parria [EMAIL PROTECTED] [EMAIL PROTECTED] 318-213-4709 318-213-4701 Netjam, LLC http://www.netjam.net 333 Texas St. VISA/MC/AMEX/COD Suite 140130 day warranty Shreveport, LA 71101 Cisco Channel Partner p: 318-212-0245 f: 318-212-0246 FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=4100&t=3964 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF dropouts [7:3964]
Vincent, Thanks for the response, but... 1) IOS 11.2 doesn't support this command (I agree, it's a useful command, and I run it on other routers with a higher IOS level). 2) That's how I know about the CRC errors, BECNs/FECNs, dropped broadcasts etc. Anything in particular you suggest looking out for? JMcL -- Forwarded by Jenny Mcleod/NSO/CSDA on 11/05/2001 08:38 am --- "Vincent Chong" @groupstudy.com on 10/05/2001 07:10:00 pm Please respond to "Vincent Chong" Sent by: [EMAIL PROTECTED] To: [EMAIL PROTECTED] cc: Subject: Re: OSPF dropouts [7:3964] 1)First I will suggest you that you use log-adjancey-change command. By apply the command, the router will send a syslog message when an OSPF neighbor state changes. It can provides a higher level view of changes to the state of the peer relationship with less output. 2)Check the physical interface status, like show interface etc. Hi all, > This isn't directly certification-related, but maybe people can practise > their trouble-shooting skills. > > I have a frame relay link that occasionally drops the OSPF adjacency across > it (average once a day maybe, but it can go several days with no problems > and then get several hits in a day). Apart from the brief disruption, this > causes the ISDN backup to kick in, which is not something I want to happen > unnecessarily since the call is from one side of Australia to the other :-) > Each access supports other PVCs as well, which do not have problems. > The PVC does not drop out. > > I have debug ip ospf events and debug ip ospf adjacency turned on. One > side will announce that the other neighbour is dead, and start rebuilding > the adjacency. The side that detects the problem first varies. > There are a small number of CRC errors at one end, and some broadcasts are > dropped at the other end, but the numbers are consistent with links > throughout the rest of the network which are problem-free. > Both routers have had the cables re-seated and have been reloaded. > Traffic shaping is in effect and should be preventing traffic from > overloading the smaller access rate. There are some FECN/BECN/DE packets, > but again, nothing at unusual levels. I have no reason to believe that the > traffic pattern on this link is different to others in the network. > > IOS is 11.2. One router is a 7505, the other a 4700M. > > I assume that hellos are being dropped occassionally (and fairly randomly) > across the link, and that sometimes enough in a row get dropped that the > timer expires. The links are monitored via MRTG, and there is some > correlation between increased usage and the problem, but there are plenty > of times of higher utilisation with no problems. Very short-term bursty > traffic may not show up in MRTG, though. > > Any tips on what to check/fiddle with next? My thought is to get the > carrier to check out the link and see whether they can see any problems in > their cloud. I have no doubt the answer will be 'no', but they may fix > something while they're looking :-). > > Ta, > JMcL > FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=4098&t=3964 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF dropouts [7:3964]
This looks very much like a carrier problem to me particularly wit some FECN/BECN being seen, we have had a few problems thate were carrier related lately, with Telstra. Cheers Jim Gillen Snr Communications Engineer AUSTRAC Ph: 9950 0842 Fax: 9950 0074 >>> "[EMAIL PROTECTED]" 10/05/01 17:58:19 >>> This message has been scanned by MAILSweeper. Hi all, This isn't directly certification-related, but maybe people can practise their trouble-shooting skills. I have a frame relay link that occasionally drops the OSPF adjacency across it (average once a day maybe, but it can go several days with no problems and then get several hits in a day). Apart from the brief disruption, this causes the ISDN backup to kick in, which is not something I want to happen unnecessarily since the call is from one side of Australia to the other :-) Each access supports other PVCs as well, which do not have problems. The PVC does not drop out. I have debug ip ospf events and debug ip ospf adjacency turned on. One side will announce that the other neighbour is dead, and start rebuilding the adjacency. The side that detects the problem first varies. There are a small number of CRC errors at one end, and some broadcasts are dropped at the other end, but the numbers are consistent with links throughout the rest of the network which are problem-free. Both routers have had the cables re-seated and have been reloaded. Traffic shaping is in effect and should be preventing traffic from overloading the smaller access rate. There are some FECN/BECN/DE packets, but again, nothing at unusual levels. I have no reason to believe that the traffic pattern on this link is different to others in the network. IOS is 11.2. One router is a 7505, the other a 4700M. I assume that hellos are being dropped occassionally (and fairly randomly) across the link, and that sometimes enough in a row get dropped that the timer expires. The links are monitored via MRTG, and there is some correlation between increased usage and the problem, but there are plenty of times of higher utilisation with no problems. Very short-term bursty traffic may not show up in MRTG, though. Any tips on what to check/fiddle with next? My thought is to get the carrier to check out the link and see whether they can see any problems in their cloud. I have no doubt the answer will be 'no', but they may fix something while they're looking :-). Ta, JMcL FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ** Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=4090&t=3964 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF dropouts [7:3964]
I am not sure if this is a OSPF related problem but I recently encountered a strange problem in my network. I have a WAN link that has been running on frame relay encapsulation for the past few years without any problems. Just today, I noticed that I lost connectivity between site A and site B (these sites are directly connected) .The first thing I did was to do a show int on both ends. I found both the line protocol and interface to be up. I however, could not ping the two ends. I couldn't even ping the WAN interface of the router that I am connected by console to. How is that possible? Should I do a shut , no shut? Another interesting thing I discovered on this router (7500) is that when I ping the WAN IP address of other interfaces, I get a round trip delay. I always thought that since the IP address is assigned on that router, the ping should be less than 10ms ?? I run OSPF,BGP and MPLS. FR guys says that there is no problem with the PVC. I would appreciate any help rendered. Thanks! Kevin wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > I have had similar problems to this with OSPF. Wierd situations where > adjacencies would drop out or could not form adjacencies, and yet > everything looked good. In one instance it was a layer2 problem, and in > the other it had to do with CEF (the feature I have a love/hate > relationship with). > > If your running CEF, it could possibly be doing something here. To me > however it smells of l2 problems. I assume you checked "sh frame pvc" and > made sure the counters look ok? > > Brian > > > On Thu, 10 May 2001, [EMAIL PROTECTED] wrote: > > > Hi all, > > This isn't directly certification-related, but maybe people can practise > > their trouble-shooting skills. > > > > I have a frame relay link that occasionally drops the OSPF adjacency across > > it (average once a day maybe, but it can go several days with no problems > > and then get several hits in a day). Apart from the brief disruption, this > > causes the ISDN backup to kick in, which is not something I want to happen > > unnecessarily since the call is from one side of Australia to the other :-) > > Each access supports other PVCs as well, which do not have problems. > > The PVC does not drop out. > > > > I have debug ip ospf events and debug ip ospf adjacency turned on. One > > side will announce that the other neighbour is dead, and start rebuilding > > the adjacency. The side that detects the problem first varies. > > There are a small number of CRC errors at one end, and some broadcasts are > > dropped at the other end, but the numbers are consistent with links > > throughout the rest of the network which are problem-free. > > Both routers have had the cables re-seated and have been reloaded. > > Traffic shaping is in effect and should be preventing traffic from > > overloading the smaller access rate. There are some FECN/BECN/DE packets, > > but again, nothing at unusual levels. I have no reason to believe that the > > traffic pattern on this link is different to others in the network. > > > > IOS is 11.2. One router is a 7505, the other a 4700M. > > > > I assume that hellos are being dropped occassionally (and fairly randomly) > > across the link, and that sometimes enough in a row get dropped that the > > timer expires. The links are monitored via MRTG, and there is some > > correlation between increased usage and the problem, but there are plenty > > of times of higher utilisation with no problems. Very short-term bursty > > traffic may not show up in MRTG, though. > > > > Any tips on what to check/fiddle with next? My thought is to get the > > carrier to check out the link and see whether they can see any problems in > > their cloud. I have no doubt the answer will be 'no', but they may fix > > something while they're looking :-). > > > > Ta, > > JMcL > > FAQ, list archives, and subscription info: > http://www.groupstudy.com/list/cisco.html > > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] > > > > > --- > We have MOVED!! Make note of our new address!!! > > I'm buying / selling used CISCO gear!! > email me for a quote > > Brian Feeny,CCDP,CCNP+VAS Scarlett Parria > [EMAIL PROTECTED] [EMAIL PROTECTED] > 318-213-4709 318-213-4701 > > Netjam, LLC http://www.netjam.net > 333 Texas St.VISA/MC/AMEX/COD > Suite 1401 30 day warranty > Shreveport, LA 71101 Cisco Channel Partner > p: 318-212-0245 > f: 318-212-0246 > FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=4011&t=3964 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF dropouts [7:3964]
I have had similar problems to this with OSPF. Wierd situations where adjacencies would drop out or could not form adjacencies, and yet everything looked good. In one instance it was a layer2 problem, and in the other it had to do with CEF (the feature I have a love/hate relationship with). If your running CEF, it could possibly be doing something here. To me however it smells of l2 problems. I assume you checked "sh frame pvc" and made sure the counters look ok? Brian On Thu, 10 May 2001, [EMAIL PROTECTED] wrote: > Hi all, > This isn't directly certification-related, but maybe people can practise > their trouble-shooting skills. > > I have a frame relay link that occasionally drops the OSPF adjacency across > it (average once a day maybe, but it can go several days with no problems > and then get several hits in a day). Apart from the brief disruption, this > causes the ISDN backup to kick in, which is not something I want to happen > unnecessarily since the call is from one side of Australia to the other :-) > Each access supports other PVCs as well, which do not have problems. > The PVC does not drop out. > > I have debug ip ospf events and debug ip ospf adjacency turned on. One > side will announce that the other neighbour is dead, and start rebuilding > the adjacency. The side that detects the problem first varies. > There are a small number of CRC errors at one end, and some broadcasts are > dropped at the other end, but the numbers are consistent with links > throughout the rest of the network which are problem-free. > Both routers have had the cables re-seated and have been reloaded. > Traffic shaping is in effect and should be preventing traffic from > overloading the smaller access rate. There are some FECN/BECN/DE packets, > but again, nothing at unusual levels. I have no reason to believe that the > traffic pattern on this link is different to others in the network. > > IOS is 11.2. One router is a 7505, the other a 4700M. > > I assume that hellos are being dropped occassionally (and fairly randomly) > across the link, and that sometimes enough in a row get dropped that the > timer expires. The links are monitored via MRTG, and there is some > correlation between increased usage and the problem, but there are plenty > of times of higher utilisation with no problems. Very short-term bursty > traffic may not show up in MRTG, though. > > Any tips on what to check/fiddle with next? My thought is to get the > carrier to check out the link and see whether they can see any problems in > their cloud. I have no doubt the answer will be 'no', but they may fix > something while they're looking :-). > > Ta, > JMcL > FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] > --- We have MOVED!! Make note of our new address!!! I'm buying / selling used CISCO gear!! email me for a quote Brian Feeny,CCDP,CCNP+VAS Scarlett Parria [EMAIL PROTECTED] [EMAIL PROTECTED] 318-213-4709 318-213-4701 Netjam, LLC http://www.netjam.net 333 Texas St. VISA/MC/AMEX/COD Suite 140130 day warranty Shreveport, LA 71101 Cisco Channel Partner p: 318-212-0245 f: 318-212-0246 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=4004&t=3964 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: OSPF dropouts [7:3964]
1)First I will suggest you that you use log-adjancey-change command. By apply the command, the router will send a syslog message when an OSPF neighbor state changes. It can provides a higher level view of changes to the state of the peer relationship with less output. 2)Check the physical interface status, like show interface etc. Hi all, > This isn't directly certification-related, but maybe people can practise > their trouble-shooting skills. > > I have a frame relay link that occasionally drops the OSPF adjacency across > it (average once a day maybe, but it can go several days with no problems > and then get several hits in a day). Apart from the brief disruption, this > causes the ISDN backup to kick in, which is not something I want to happen > unnecessarily since the call is from one side of Australia to the other :-) > Each access supports other PVCs as well, which do not have problems. > The PVC does not drop out. > > I have debug ip ospf events and debug ip ospf adjacency turned on. One > side will announce that the other neighbour is dead, and start rebuilding > the adjacency. The side that detects the problem first varies. > There are a small number of CRC errors at one end, and some broadcasts are > dropped at the other end, but the numbers are consistent with links > throughout the rest of the network which are problem-free. > Both routers have had the cables re-seated and have been reloaded. > Traffic shaping is in effect and should be preventing traffic from > overloading the smaller access rate. There are some FECN/BECN/DE packets, > but again, nothing at unusual levels. I have no reason to believe that the > traffic pattern on this link is different to others in the network. > > IOS is 11.2. One router is a 7505, the other a 4700M. > > I assume that hellos are being dropped occassionally (and fairly randomly) > across the link, and that sometimes enough in a row get dropped that the > timer expires. The links are monitored via MRTG, and there is some > correlation between increased usage and the problem, but there are plenty > of times of higher utilisation with no problems. Very short-term bursty > traffic may not show up in MRTG, though. > > Any tips on what to check/fiddle with next? My thought is to get the > carrier to check out the link and see whether they can see any problems in > their cloud. I have no doubt the answer will be 'no', but they may fix > something while they're looking :-). > > Ta, > JMcL > FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html > Report misconduct and Nondisclosure violations to [EMAIL PROTECTED] Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=3967&t=3964 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
OSPF dropouts [7:3964]
Hi all, This isn't directly certification-related, but maybe people can practise their trouble-shooting skills. I have a frame relay link that occasionally drops the OSPF adjacency across it (average once a day maybe, but it can go several days with no problems and then get several hits in a day). Apart from the brief disruption, this causes the ISDN backup to kick in, which is not something I want to happen unnecessarily since the call is from one side of Australia to the other :-) Each access supports other PVCs as well, which do not have problems. The PVC does not drop out. I have debug ip ospf events and debug ip ospf adjacency turned on. One side will announce that the other neighbour is dead, and start rebuilding the adjacency. The side that detects the problem first varies. There are a small number of CRC errors at one end, and some broadcasts are dropped at the other end, but the numbers are consistent with links throughout the rest of the network which are problem-free. Both routers have had the cables re-seated and have been reloaded. Traffic shaping is in effect and should be preventing traffic from overloading the smaller access rate. There are some FECN/BECN/DE packets, but again, nothing at unusual levels. I have no reason to believe that the traffic pattern on this link is different to others in the network. IOS is 11.2. One router is a 7505, the other a 4700M. I assume that hellos are being dropped occassionally (and fairly randomly) across the link, and that sometimes enough in a row get dropped that the timer expires. The links are monitored via MRTG, and there is some correlation between increased usage and the problem, but there are plenty of times of higher utilisation with no problems. Very short-term bursty traffic may not show up in MRTG, though. Any tips on what to check/fiddle with next? My thought is to get the carrier to check out the link and see whether they can see any problems in their cloud. I have no doubt the answer will be 'no', but they may fix something while they're looking :-). Ta, JMcL Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=3964&t=3964 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
