Comments within and below.
> Auto-negotiation is infamous for not working as advertised! ;- ) It's not > just Cisco equipment. I totally agree. I have a rule of thumb about what to use on a port setting with respect to speed and duplex. If the device plugging into the port has a name of router, switch, hub, or server (file, print or otherwise), hard code the values to the optimal settings. The most optimal setting for a given port would be 100/full, but if the attaching device is a hub, you are looking at either 100/half, or 10/half, depending upon the capabilities of the device. There are a couple of reasons for doing this. For starters, it helps to reduce problems associated with failed auto-negotiation. Second, it speeds up the time that the port becomes available. Even if you have portfast turned on, you will still have delays associated from autonegotiation. So you might ask, when is it appropriate to plug in a device with a setting of auto? I would not even recommend it for fixed desktop client machines, due to the reasons specified above however, you may be safe if you stick with an enterprise desktop solution where your OSs are few (or one), and your NIC vendors are few (or one) and you have completely tested them all. What's left? The obvious unknown - the road warriors with their laptops. They are the obvious candidate for what autonegotiation is supposed to provide. What is the first thing to remember when troubleshooting these types of problems? AUTONEGOTIATION doesn't :-) Finally, if this isn't bad enough, you may still have problems. I am working with the same CAT 3548XL switches mentioned on another post, and we have had a recurring problem with a class of servers (Solaris over Intel) with a few different types of NICs that are just not cooperating, no matter how hard we try. Regardless of where the NICs are set, they seem to want to only run on either 100/half, or 10/half. They seem to have an aversion to 100/full or 10/full, even if we hard code the values. It gets so bad, NFS shares lose connection and havoc is wreaked on other underlying applications dependent upon the NFS shares. Our solution is to ultimately migrate over to Linux (which so far appears to be pretty stable. > There is definitely a problem when introducing older 10BaseT equipment > into > the equation, which it sounds like Ole did. Perhaps one of the more > hardware, physical-layer type engineers remembers more of the details > than > I do, but from what I understand the 100-Mbps fast link pulses used for > auto-negotiation produce enough signal in the frequency band of the > 10-Mbps > link pulses such that the 10-Mbps chip thinks it sees a signal and > doesn't > re-negotiate or drop or establish link integrity as it should. > > It's definitely strange that STP noticed a problem when other > applications > didn't. I'll have to ponder that one...... I actually have a theory on that one. It's incredibly hard to prove without putting a sniffer between the connected device and switch port(which may change the test parameters altogether). My theory is that if the port is set for portfast, spanning tree is going to want to see the port come up quickly. It will theoretically put the port in a forwarding state, save for the receipt of looped BPDUs (indicating a switch loop). If the device has not autonegotiated speed/duplex and it does not see the port as up/up, the other side may have sent **all** traffic back in an attempt to get autonegotiation working. I have actually seen autonegotiation go into a do loop, wherein each side fights the other side for authority on what link speed/duplex values will prevail (and they never quit until link is broken). This is an entirely different scenario from the situation where both sides agree to a misguided truce and one side says, "I'll do 100/half, and the other side says, I'll to 100/full" and both sides are happy and conclude to each other, "our job is done, the rest is left up to the upper layers to sort out". That's the classic scenario where one side will see excessive collisions and the other side is reporting input errors. Remember this one final thought on autonegotiation - just say no. HTH, Paul Werner ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=30996&t=30996 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
