At 08:44 AM 9/12/00, Rossetti, Stan wrote:
>Could you point to a book or web site that mentions the information that
>you have stated below.
My book, Top-Down Network Design, and Designing Cisco Networks, edited by
Diane Teare both use the one bad frame per Megabyte of data threshold. It
was also in earlier versions of the CIT class, but in the latest version of
that class, the course developer took out a lot of the good serial
interface troubleshooting stuff and replaced it with info specific to Frame
Relay and ISDN.
The concept comes from Network Associates LANGuru Sniffer training. The
concept is that since you probably don't know actual frame sizes, use bytes
in your calculation instead. The goal is to emulate a Bit Error Rate (BER)
despite the fact that you are dealing with CRC errors in frames and
probably don't have a BER tester (BERT) handy.
You say that your MTU is 4500 bytes, but I doubt that any of your
applications are really using a frame size of 4500 bytes. You would have to
study the traffic to determine the actual size. If you found that you had a
lot of Telnet traffic, for example, with 64-byte frames and you had a high
CRC value, this would be a higher BER than if you found that you had a lot
of 1500-byte FTP frames with CRC errors. By using errors per Megabyte of
traffic over a time frame long enough to include frames of lots of
different sizes, you eliminate the variable frame-size issue.
Unfortunately, there's no way to know if the 1500-byte frame might have had
more than one bit error, since the CRC would be bad if one or more bits
were changed. That's the part of this methodology that is a bit
questionable. But it's still better than simply basing your calculation on
number of bad frames.
The concept is a little strange, and it's probably too subtle for basic
books like the Internetworking Troubleshooting Handbook and maybe even for
TAC. &;-) I guarantee you that the 1 percent number is just made up,
though. The 1 CRC error per Megabyte of data, on the other hand, is based
on actual BERs that one should expect on the types of cabling used for most
WANs.
Priscilla
>Specifically the information concerning calculating
>the crc errors percentage using bytes instead of packets. Our interface mtu
>sizes are 4500 on both ends.
>
>Isn't it also true that you don't know how big your frames are. In other
>words there could be more than one byte per frame and since the crc is
>calculated per frame (using the fcs field in the frame header as a running
>total I guess) you still wouldn't have an accurate percentage using bytes.
>I am thoroughly confused because I have talked to Cisco tac and they say to
>use packets instead of bytes, but I don't really agree with that. I have
>also looked in my Internetworking Troubleshooting Handbook and it says "Any
>input error value for crc errors, framing errors, or aborts above 1 percent
>of the total interface traffic suggests some kind of link problem..." Clue
>me in because I am lost.
>
>-----Original Message-----
>From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]]
>Sent: Thursday, August 31, 2000 5:24 PM
>To: Rossetti, Stan; '[EMAIL PROTECTED]'
>Subject: Re: Serial Line CRC or Input Errors!!
>
>
>Since we have been quoting Cisco statistics lately, here's one that is
>actually quite helpful. Cisco says you should not have more than one CRC
>error per megabyte of data on a serial link. The reason they use megabytes
>instead of packets is because it's hard to know how big your packets are.
>(The thinking is that one error per packet when using 64-byte packets would
>be a much higher rate than one error per packet when using 4500-byte
>packets, for example.)
>
>The reason they use bytes instead of bits is simply because this statistic
>really comes from the protocol analyzer vendors, not Cisco, and those
>vendors report statistics in bytes. If you're looking at Cisco output and
>it shows bits, be sure to divide by 8 to get bytes.
>
>You should compare the CRCs to the input data, rather than the output data,
>I would think, since there's no way to really know if your outputted
>packets are encountering problems in transit.
>
>Hope this helps.
>
>Priscilla
>
>
>At 01:40 PM 8/31/00, Rossetti, Stan wrote:
> >Does anybody know what is considered to be high CRC errors on a serial
>line.
> >I have seen 26 crc errors over last 70 hours (8,980,742 input packets)
>appr.
> >= 2.895 x 10 -6 error rate (26/8,980,742).
> >
> >Is the error rate formula (crc error total)/(input error packets). Or is
>it
> >(crc error total)/(output error packets) or (crc error total)/(input +
> >output error packets). Do you use the number of packets or is it bits or
>is
> >bytes. I would assume that you use packets.
> >
> >Thanks,
> >
> >Stan Rossetti
> >
> >
> >Russia Services Group
> >Email: [EMAIL PROTECTED]
> >Phone: (256) 544-5031
> >Beeper: 544-1183 pin # 0112
> >
> > <<...>>
> >
> >
> >
> >___________________________________
> >UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
> >FAQ, list archives, and subscription info: http://www.groupstudy.com
> >Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>
>
>________________________
>
>Priscilla Oppenheimer
>http://www.priscilla.com
________________________
Priscilla Oppenheimer
http://www.priscilla.com
**NOTE: New CCNA/CCDA List has been formed. For more information go to
http://www.groupstudy.com/list/Associates.html
_________________________________
UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
FAQ, list archives, and subscription info: http://www.groupstudy.com
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
