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=66454&t=66402 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
