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]