- A virtual community of network engineers
 Home  BookStore  StudyNotes  Links  Archives  StudyRooms  HelpWanted  Discounts  Login
Re: Ethernet Interface Collisions Incresing rapidl [7:71176] posted 06/25/2003
[Chronological Index] [Thread Index] [Top] [Date Prev][Date Next] [Thread Prev][Thread Next]

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?


----- Original Message ----- 
From: "Priscilla Oppenheimer" 
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
> to a hardware buffer because the input rate exceeded the receiver's
> to handle the data.
> URL is:
> A hardware problem could cause that, though I still wonder if it might
> 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
> healthy way, then there would probably be some deferrals too. I didn't
> 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:
> Why would a network have lots of collisions but no cases where a packet
> to be deferred? This may be more evidence of a hardware problem, rather
> 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!
> a healthy shared Ethernet is not a good medium for voice due to its
> variable delay.
> Priscilla

Message Posted at:
FAQ, list archives, and subscription info:
Report misconduct and Nondisclosure violations to abuse@xxxxxxxxxxxxxx