Tim Champion wrote:
> 
> I would suggest that "input errors" is a general counter for
> all input
> errors and that these are then split down in to more sepcific
> error types,
> in this case CRC. Can anyone confirm this?

Yes, that's right.

Input errors is a general category. On an Ethernet interface, input errors
include runts, giants, no buffer, CRC, frame, overrun, and ignored counts.
Usually the amount of these specific errors will add up to the numer of
input errors, although sometimes the number of input errors doesn't equal
the sum of the other errors because frames may have more than one error.
Also, frames may have errors that do not fall into any of the specific
categories and just get counted in the input errors category, according to
Cisco documentation. So, in true Cisco style, it's not an exact science.

But, in this case, all the errors are CRC errors. This doesn't seem like a
duplex mismatch problem, then. If it were, we would expect to see runts and
collisions too, depending on the exact misconfiguration.

Just seeing CRC errors indicates noise or a hardware problem. Are all these
ports physically near each other? What else are they near? A motor of some
sort? Are all the connected PCs near each other, or does their cabling
travel together through an area where there could be noise?

Could you move cables to different ports and see if the problem follows?

On the other hand....... Have you also troubleshooted above the physical and
data-link layers. Of course, it makes sense to start at the lower layers,
but..... Notice that your reliability is 255/255 (100%). Cisco's
calculations are trying to tell you that there isn't really a problem, at
least there hasn't been a problem recently. The reliability is an
exponential average over 5 minutes.

The port has only seen 152 CRC errors in about 6 days. (See Last clearing of
"show interface" counters 5d21h.) That's pretty insignificant. In that same
time, the port received about 3 million packets. That's really a pretty low
error rate.

I would clear the counters, to start with, and see if the errors creep up
regularly, are bunched together all at once, etc.

Also, put a sniffer on the network and troubleshoot the disconnection
problem. My gut feeling is that it's an upper-layer problem, but I don't
have quite enough data to say this for sure.

_______________________________

Priscilla Oppenheimer
www.troubleshootingnetworks.com
www.priscilla.com





> ""Larry Letterman""  wrote in message
> [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > Packet Errors
> > If you have a large amount of alignment errors, FCS errors,
> or late
> > collisions, this may indicate:
> >
> >
> > Duplex mismatch
> >
> > Bad NICs
> >
> > Cable problems (causing mangled packets, flapping ports, and
> so on)
> >
> > For more information on duplex mismatch errors, see
> Configuring and
> > Troubleshooting Ethernet 10/100Mb Half/Full Duplex
> Auto-Negotiation. The
> > most common issue with speed/duplex is that customers
> manually set the
> > speed/duplex on the switch, but not on the
> workstation/server. Auto
> > speed/duplex on one side and 100/Full-duplex on the other
> side is a
> > misconfiguration and will result in a duplex mismtach.
> >
> > Larry Letterman
> > Cisco Systems
> >
> >
> > Sim, CT (Chee Tong) wrote:
> >
> > >Hi..  Some users complaint to me that their application
> getting
> > >disconnection.  I have fixed the speed and duplex of their
> switch port at
> > >both sides and changed the cable but still the same. And the
> strange
> thing
> > >is that all the problem ports are all having the same error
> pattern-same
> > >number of input errors and CRC. The rest of errors are all
> zero-as shown
> > >below.    Those other ports that have different number input
> errors and
> CRC
> > >are not having disconnection problem.   Any idea what can I
> do on those
> > >ports that having disconnection problem?
> > >
> > >
> > >
> > >
> > >
> > >SW4>sh int fas0/21
> > >
> > >FastEthernet0/21 is up, line protocol is up
> > >
> > >  Hardware is Fast Ethernet, address is 00d0.790c.d315 (bia
> 00d0.790c.d315)
> > >
> > >  MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec,
> > >
> > >     reliability 255/255, txload 1/255, rxload 1/255
> > >
> > >  Encapsulation ARPA, loopback not set
> > >
> > >  Keepalive not set
> > >
> > >  Full-duplex, 100Mb/s, 100BaseTX/FX
> > >
> > >  ARP type: ARPA, ARP Timeout 04:00:00
> > >
> > >  Last input never, output 00:00:00, output hang never
> > >
> > >  Last clearing of "show interface" counters 5d21h
> > >
> > >  Queueing strategy: fifo
> > >
> > >  Output queue 0/40, 0 drops; input queue 0/75, 0 drops
> > >
> > >  5 minute input rate 2000 bits/sec, 5 packets/sec
> > >
> > >  5 minute output rate 52000 bits/sec, 23 packets/sec
> > >
> > >     2859951 packets input, 283856132 bytes
> > >
> > >     Received 213447 broadcasts, 0 runts, 0 giants, 0
> throttles
> > >
> > >     152 input errors, 152 CRC, 0 frame, 0 overrun, 0 ignored
> > >
> > >     0 watchdog, 0 multicast
> > >
> > >     0 input packets with dribble condition detected
> > >
> > >     8585472 packets output, 2364752071 bytes, 0 underruns
> > >
> > >     0 output errors, 0 collisions, 0 interface resets
> > >
> > >     0 babbles, 0 late collision, 0 deferred
> > >
> > >     0 lost carrier, 0 no carrier
> > >
> > >     0 output buffer failures, 0 output buffers swapped out
> > >
> > >Cat29-L7-4>
> > >
> > >
> >
> >==================================================================
> > >De informatie opgenomen in dit bericht kan vertrouwelijk
> zijn en
> > >is uitsluitend bestemd voor de geadresseerde. Indien u dit
> bericht
> > >onterecht ontvangt wordt u verzocht de inhoud niet te
> gebruiken en
> > >de afzender direct te informeren door het bericht te
> retourneren.
> >
> >==================================================================
> > >The information contained in this message may be confidential
> > >and is intended to be exclusively for the addressee. Should
> you
> > >receive this message unintentionally, please do not use the
> contents
> > >herein and notify the sender immediately by return e-mail.
> > >
> > >
> >
> >==================================================================
> > --
> >
> > Larry Letterman
> > Network Engineer
> > Cisco Systems Inc.
> 
> 




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=54554&t=54516
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to