GroupStudy.com GroupStudy.com - 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?

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 abuse@xxxxxxxxxxxxxx