This reminds me that recently we had a similar problem with output errors on a FastEthernet interface and the problem was IOS-related. Different situation, though. That was on a 3660 and it was an autonegotiation bug. Still, that's something to check into, as well.
What IOS image is on that router? John ----- Original Message ----- From: "Priscilla Oppenheimer" To: Sent: Tuesday, June 24, 2003 5:50 PM Subject: Re: Ethernet Interface Collisions Incresing rapidl [7:71176] > John Neiberger wrote: > > > > I'm concerned about the output errors. Collisions are not > > considered output > > errors; they're to be expected with half duplex ethernet. So, > > you do really > > have a problem of some variety that needs to be investigated. > > Thanks for that info, John. I wasn't sure if output errors counted > collisions or not. > > I'm thinking hardware problem on the router maybe? Hardware problem on the > wireless bridge's Ethernet interface? Bad cable, as you mentioned? > > Time to swap 'til you drop. > > I found this at Cisco's site: > > Output errors > Number of times that the receiver hardware was unable to hand received data > to a hardware buffer because the input rate exceeded the receiver's ability > to handle the data. > > URL is: > > ww.cisco.com/univercd/cc/td/doc/product/voice/ics/ics25/icstg25/tsether2.htm > > A hardware problem could cause that, though I still wonder if it might just > be too much load. High load could explain output errors (assuming that > explanation is right, which is a lot to assume :-) and collisions. Of > coures, a hardware problem could explain it too. > > > One thing that is suspicious, though, is that deferrals are zero, while > collisions aren't. If the network is really just busy with a high load in a > healthy way, then there would probably be some deferrals too. I didn't want > to mention this before because I hadn't found a good explanation for them, > but I found one. Cisco says this: > > The deferred counter counts the number of times the interface has tried to > send a frame, but found the carrier busy at the first attempt (Carrier > Sense). This does not constitute a problem, and is part of normal Ethernet > operation. > > > URL for that is: > > http://www.cisco.com/warp/public/63/eth_collisions.html > > Why would a network have lots of collisions but no cases where a packet had > to be deferred? This may be more evidence of a hardware problem, rather than > a loading problem. > > It could also be evidence of the other side actually using full duplex > despite its manual configuration. It sends whenever it wants, including > while the other side is sending. > > > Are you sure you can't just use full duplex? It would sure be cleaner! Even > a healthy shared Ethernet is not a good medium for voice due to its inherent > variable delay. > > Priscilla Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=71317&t=71176 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
