[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]
