Recently I have experiences problems with auto neg. So now before deploying any piece (including switches) I set all the ports/ints to 100FULL. I found the following that mey be of interest. I wonder if Cisco will ever just ship with 100FULL as default! 802.3u auto-negotiation and why it's sometimes bad. Inherently Ethernet had only one kind of Link Pulse. This was the Normal Link Pulse used to establish link after an interface had been reset. To insure compatibility with the least work the 802.3u committee added another pulse to the Link process. This was the Fast Link Pulse (FLP) it can consist of 17 to 33 pulses that should take no longer than 2ms to transmit. Those 17 to 33 pulses will consist of 17 timing pulses and up to 16 data pulses. IF there are data pulses the Link Code Word (LCW) status of the link is set to 1 if no data pulses are present the LCW is set to 0. Three identical LCW's must be received before they are accepted as valid. In the Base Link Code Word ( the one that handles the link negotiation) you can determine link speed and duplex the choices are, in reverse order according to preference: A0 10BASE-T A1 10BASE-T FD A2 100BASE-TX A3 100BASE-TX FD A4 100BASE-T4 A5 PAUSE A6 Reserved A7 Reserved If any FD type is chosen FD with the PAUSE feature will be preferred as this is a physical media flow control function. This assumes that the device in question is capable of all states within the auto-negotiation standard. If not, the device will send idle pulses that can be used to determine the link state and both devices will therefore bypass the NLP/FLP link detection process. The problem with the standard is that implementation of the pulses however minutely detailed does not dictate manufacturing processes to the retailer. So faulty implementation are a concern, if not a common concern. This is especially well displayed in the typical SUN/CISCO auto-neg process. It almost never works. If the auto process does not work then one device will be expecting a certain status of the line and the other will have no idea. Usually this results in degraded operation not complete failure. However, this will usually become known when large file transfers and/or bursty traffic patterns are common on the segment in question. In my experience this can result in a link that is err-disabled when a large number of collisions are detected the link will then either be disabled for a time-out period or will remain disabled until the NA clears the interface. This will contribute to inconsistent network behavior. When coupled with the max time that the link pulses can take 10 ms (Three 2ms bursts plus 2ms interval between) and the time that Spanning Tree Protocol can disable a port after a status change (30-55s) a non manually configured port can caused considerable heartache. (this of course does not take into account PAgP). If you configure your switch interfaces to 100/fd you will force the clients into Parallel Detection mode. This forces the client to listen to the idle time pulses and determine link status from there. If the machine is mission critical and/or hosts any backup or multimedia applications I would absolutely set the interface to match the switching device. ===== _____________________________________________ Moe __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/ _________________________________ FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
