Okay, I'm responding to my own post. I found a very similar bug that occurs on 1700 series routers running 12.0(7). Would that happen to be what you're running?
John ----- Original Message ----- From: "John Neiberger" To: Sent: Tuesday, June 24, 2003 8:22 PM Subject: Re: Ethernet Interface Collisions Incresing rapidl [7:71176] > 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=71324&t=71176 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
