Thanks!!!  This is why I LOVE this list.  You can ask a question that only a
few hundred people in the whole world could answer really well, and one of
them will answer.

Tom Larus

""Priscilla Oppenheimer""  wrote in message
news:[EMAIL PROTECTED]
> Thomas Larus wrote:
> >
> > I don't think we can stress enough how important the
> > speed/duplex mismatch
> > and autonegotiation problems are.  If you are having a LAN
> > problem, this is
> > one of the first things you should consider.  The interesting
> > thing thing
> > about duplex mismatch errors is that things can seem like they
> > are working
> > okay, but you notice problems once in a while.
> >
> > Every day, probably hundreds of thousands of users and servers
> > are
> > experiencing less-than-optimal performance because of this kind
> > of problem.
> > Are some or all of your IP phones rebooting every once in a
> > while?  Even
> > this could have something to do with a duplex mismatch problem
> > somewhere
> > between your IP phones and your Call Manager.
> >
> > One question I have for folks is whether duplex mismatch
> > errors between a
> > switch and one device on a segment (network printer, PC,
> > server, etc.) could
> > substantially degrade performance on the switch so that other
> > links would be
> > impacted in a noticeable way.
>
> Hmmm. That's an interesting question: does a duplex mismatch on one port
> degrade performance on the switch in general? I'm thinking out loud here,
> but I think it's unlikely.
>
> It would depend on the the duplex mode that the switch port ended up in,
> though, and the architecture of the switch. If the switch port ended up in
> half duplex, and the port has a lot of frames to send, the port could end
up
> doing lots of retransmissions. It would retransmit every time it received
> while sending. (That would be true for any half-duplex environment, even
> without a mismatch, actually.)
>
> If the switch isn't a non-blocking switch, the port that is busy
> retransmitting could cause problems for other ports that have something to
> send out that port. With head-of-the-line blocking, a frame at the front
of
> an input queue on some other port could be holding up every frame behind
it
> because the half-duplex output port is busy retransmitting and can't
accept
> another frame.
>
> Cisco high-end switches don't have this problem. Switches based on the
5000
> architecture have shared buffers where they can ship frames to get them
out
> of the way of frames behind them.
>
> Now, let's say that the switch port decided it was full duplex but the
other
> side deciced it was half. That wouldn't cause a serious performance
problem
> at the switch. The switch port would see lots of runts and CRCs and have
to
> report them to management, but that shouldn't cause a significant
> performance problem.
>
> Priscilla
>
>
> >
> > Tom Larus
> >
> >
> > ""John Neiberger""  wrote in
> > message
> > news:[EMAIL PROTECTED]
> > > Orlando Palomar Jr  CCIE#11206 wrote:
> > > >
> > > > Well said, John. I guess we'll still be seeing a lot of
> > these
> > > > until they standardize auto-negotiation accross all vendors.
> > >
> > > And that's the funny thing.  Autonegotiation *is* the
> > standard!  ;-)  It's
> > > when you don't use auto that you've strayed from the
> > standard.  However, I
> > > still find about  I just cannot
> > > get auto to work right.  Most of those I suspect bad cabling
> > but it would
> > > have been too difficult to fix at the time.
> > >
> > > Here's a tip that I've found helpful, even if things seem to
> > be running
> > > fairly well after you upgrade to a newer switch.  From time
> > to time, clear
> > > the counters and wait a while, then check for alignment
> > errors, late
> > > collisions, and CRC errors.  Any of those are a good sign
> > that you might
> > > have a speed and/or duplex mismatch.
> > >
> > > I've been using this technique to slowly fix the connections
> > to some of
> > our
> > > servers.  Quite often the servers will appear to be working
> > just fine but
> > > they still need to be fixed.  Other times, our LAN group
> > spends weeks of
> > > intermittent troubleshooting trying to solve a problem and it
> > never occurs
> > > to them that it might be a speed/duplex issue.  They're
> > always looking for
> > > application or OS problems and they sometimes don't think to
> > ask me about
> > it
> > > until they've run out of ideas.




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=66496&t=66402
--------------------------------------------------
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