Re: Serial interface stats and troubleshooting [7:70266]
Clear the counters and what them. If the errors continue to increment, then you have a problem. If not, then don't worry about it. Dave wrote in message news:[EMAIL PROTECTED] > Here's a really dumb question which I should have an answer to, but I > really don't: > > I'm looking at a serial interface, a 128k Frame Relay line. The last time > the counters were reset was 4w4d ago. Here are some vital stats of note: > > txload and rxload: 3/255 > 502 input errors > 255 CRC > 239 frame > 68 interface resets > 2 carrier transitions > > My question is, at what point do these statistics indicate a *problem*? > How many interface resets is too many? How many carrier transitions are > normal and acceptable? At what point do I call the provider and complain? > > BJ > > > mail2web - Check your email from the web at > http://mail2web.com/ . Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=70289&t=70266 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Serial interface stats and troubleshooting [7:70266]
I've seen troubles with T-1 loops in wet weather due to moisture getting into poor splices or repeaters. Actually any physical fault in the cable - could be squirrels chewing the insulation or (in rural areas) hunters with poor aim. Many years ago I worked for Ma Bell in Brooklyn, NY. This was before fiber optic. T-1 links were all copper with repeaters about every 1/3 mile. (Others can be more specific as to seperation between repeaters.) Repeaters were in housings in manholes. After any maintenance the housing was supposed to be pressurized with compressed air. Anyway, either due to poor seals or workers with an attitude - every time it rained T-1s would start to fail as the manhole(s) filled with water. In time we knew the order of failure - depending on the repeaters location in the housing. Bottom first, etc. > -Original Message- > From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED] > Daniel Cotts wrote: then also look for correlations such as errors when it > > rains. >PO asked: > Seriously? When it rains? Why is that an issue? And how about > fiber-optic, > it could be affected by rain too, couldn't it? > > A local company here in Oregon spent a bunch of money to put > a fiber-optic > link under the ground out to a foreman's office at a timber company. > Unfortunately, they put this link underneath the path where > the big lumber > trucks drive in and out, causing lots of mud and guck and > standing water. > The fiber-optic link had all sorts of problems! > > So then they tried wireless. Guess what? A wireless signal doesn't go > through tall trucks stacked with logs very well. > > Last I heard, the final solution was a copper link in a > sealed conduit. Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=70287&t=70266 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Serial interface stats and troubleshooting [7:70266]
Daniel Cotts wrote: > > Problem is that you don't know if the issue is ongoing or a one > time event. > Best to check counters every day. > If you can view the stats on the CSU/DSU or Service Module or > NM-CSU then > look for physical problems - errored seconds, etc. If part of > your loop is > copper then also look for correlations such as errors when it > rains. Seriously? When it rains? Why is that an issue? And how about fiber-optic, it could be affected by rain too, couldn't it? A local company here in Oregon spent a bunch of money to put a fiber-optic link under the ground out to a foreman's office at a timber company. Unfortunately, they put this link underneath the path where the big lumber trucks drive in and out, causing lots of mud and guck and standing water. The fiber-optic link had all sorts of problems! So then they tried wireless. Guess what? A wireless signal doesn't go through tall trucks stacked with logs very well. Last I heard, the final solution was a copper link in a sealed conduit. It exceeds the supposed 100 meter limitation, (which is why they had originally thought fiber), but it works fine and was cheapter than replacing the water-logged fiber equipment. Just a fun story from the Pacific Northwest that I thought you would all enjoy. :-) And guess what, it hasn't rained here for almost 2 weeks! Hooray. Priscilla > > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Sent: Friday, June 06, 2003 9:13 AM > > To: [EMAIL PROTECTED] > > Subject: Serial interface stats and troubleshooting [7:70266] > > > > > > Here's a really dumb question which I should have an answer > to, but I > > really don't: > > > > I'm looking at a serial interface, a 128k Frame Relay line. > > The last time > > the counters were reset was 4w4d ago. Here are some vital > > stats of note: > > > > txload and rxload: 3/255 > > 502 input errors > > 255 CRC > > 239 frame > > 68 interface resets > > 2 carrier transitions > > > > My question is, at what point do these statistics indicate a > > *problem*? > > How many interface resets is too many? How many carrier > > transitions are > > normal and acceptable? At what point do I call the provider > > and complain? > > > > BJ > > > > > > > mail2web - Check your email from the web at > > http://mail2web.com/ . > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=70282&t=70266 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Serial interface stats and troubleshooting [7:70266]
My guess is that these counters are not incrementing and that at some point in the past 4&1/2 weeks you may have experienced a problem. It doesn't take long for the counters to increment. Clear your counters and keep an eye on it if you suspect and WAN problem. To answer your oringinal qestions the counters you listed should be 0, at least if you connected to Qwest;) Dave [EMAIL PROTECTED] wrote: > Here's a really dumb question which I should have an answer to, but I > really don't: > > I'm looking at a serial interface, a 128k Frame Relay line. The last time > the counters were reset was 4w4d ago. Here are some vital stats of note: > > txload and rxload: 3/255 > 502 input errors > 255 CRC > 239 frame > 68 interface resets > 2 carrier transitions > > My question is, at what point do these statistics indicate a *problem*? > How many interface resets is too many? How many carrier transitions are > normal and acceptable? At what point do I call the provider and complain? > > BJ > > > mail2web - Check your email from the web at > http://mail2web.com/ . -- David Madland CCIE# 2016 Sr. Network Engineer Qwest Communications 612-664-3367 "Government can do something for the people only in proportion as it can do something to the people." -- Thomas Jefferson Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=70277&t=70266 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Serial interface stats and troubleshooting [7:70266]
Problem is that you don't know if the issue is ongoing or a one time event. Best to check counters every day. If you can view the stats on the CSU/DSU or Service Module or NM-CSU then look for physical problems - errored seconds, etc. If part of your loop is copper then also look for correlations such as errors when it rains. > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Friday, June 06, 2003 9:13 AM > To: [EMAIL PROTECTED] > Subject: Serial interface stats and troubleshooting [7:70266] > > > Here's a really dumb question which I should have an answer to, but I > really don't: > > I'm looking at a serial interface, a 128k Frame Relay line. > The last time > the counters were reset was 4w4d ago. Here are some vital > stats of note: > > txload and rxload: 3/255 > 502 input errors > 255 CRC > 239 frame > 68 interface resets > 2 carrier transitions > > My question is, at what point do these statistics indicate a > *problem*? > How many interface resets is too many? How many carrier > transitions are > normal and acceptable? At what point do I call the provider > and complain? > > BJ > > > mail2web - Check your email from the web at > http://mail2web.com/ . Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=70276&t=70266 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Serial interface stats and troubleshooting [7:70266]
[EMAIL PROTECTED] wrote: > > Here's a really dumb question which I should have an answer to, > but I > really don't: > > I'm looking at a serial interface, a 128k Frame Relay line. > The last time > the counters were reset was 4w4d ago. Here are some vital > stats of note: > > txload and rxload: 3/255 > 502 input errors > 255 CRC > 239 frame > 68 interface resets > 2 carrier transitions > > My question is, at what point do these statistics indicate a > *problem*? A CRC error means that one or more bits got changed or dropped. A frame error means that the frame didn't end on an 8-bit boundary, probably because a bit got dropped. They are both caused by noise usually. The amount of acceptable CRC and frame errors depends on the amount of traffic. In the olden days we used to measure error rates on serial links with a Bit Error Rate Tester (BERT). Although we don't tend to do that anymore, the theory is still sound. Of course, bits are gathered into frames and all modern troubleshooting tools consider frames. Also, most troubleshooting tools show you the number of bytes transmitted rather than the number of bits, but that's OK. Anyway, one approximation you can use that is based on the theory and caveats above is that you shouln't have more than one CRC or Frame error per Megabyte of data received. That was what we used at Network General (now Network Associates, makers of the Sniffer) when we did our Network Health Checks. You'll see the same threshold in some Cisco documentation also, mainly because some Network General people migrated to Cisco. You'll see other numbers too, though. :-) Another threshold that I've seen is that no more than 1% of frames should be errored. In general, the concept is to measure CRC and Frame errors as a ratio to good frames/bytes/bits. Using bytes instead of frames lets you ignore the fact that you use variable-sized frames. > How many interface resets is too many? How many carrier > transitions are > normal and acceptable? At what point do I call the provider > and complain? Resets and transitions could be something you did, not the provider. Measure those over time based on what you know was happening. For example, if most of them happened while you were bringing up the link, you can probably ignore them and maybe clear the counters so they go away. If the rest were spread out over weeks, I would ignore them too. But you would want to correlate this with other error reports, trouble tickets, etc. Priscilla > > BJ > > > mail2web - Check your email from the web at > http://mail2web.com/ . > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=70272&t=70266 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Serial interface stats and troubleshooting [7:70266]
Here's a really dumb question which I should have an answer to, but I really don't: I'm looking at a serial interface, a 128k Frame Relay line. The last time the counters were reset was 4w4d ago. Here are some vital stats of note: txload and rxload: 3/255 502 input errors 255 CRC 239 frame 68 interface resets 2 carrier transitions My question is, at what point do these statistics indicate a *problem*? How many interface resets is too many? How many carrier transitions are normal and acceptable? At what point do I call the provider and complain? BJ mail2web - Check your email from the web at http://mail2web.com/ . Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=70266&t=70266 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
