ian williams wrote: > > This has come up in the ccie written. A question that asks whether you should use auto or manual is really on the CCIE written? Of course, you can't answer that under NDA ;-), but I agree with John that it would be a bad question. It's implementation dependent, with changes occuring with every new release of hardware! Now, a theory question on the CCIE would make sense, though. A theory question could determine if you know how CSMA/CD works, which is still surprisingly relevant on modern networks, partly because of the infamous duplex mismatch problems that refuse to go away.
> If I understand this subject correctly AUTO , sends out packets > to try and > match the 2 devices up with regards to speed and duplex. Autonegotiation doesn't send out packets. It actually uses link pulses. Remember it is used to make the link operational. It happens before packets (frames) could be sent. I'll copy and paste some info on this topic from my book at the end of this message. It's a little boring, so I'll put it at the end. :-) > If your getting connection problems this would be a speed > issue. If its some Yes, if there's a speed mismatch, you won't even get a link light and you have to fix that. > sort of packet loss/error then this could be a duplex problem. Yes, a duplex mismatch problem is hard to troubleshoot because you do get a link light and all seems fine, even though it's not. Problems occur as the load increases. So here's where CSMA/CD comes in. The half duplex side listens before sending and defers to the other sender. It also listens for collisions while sending. It assumes that the link requires a sender to Carrier Sense (CS); that the link is Multiple Access (MA); and that Collision Detection (CD) while sending is important. Now the full duplex side assumes that each link partner has its own dedicated send path and that the link is not MA. So there's no need to do CS. It sends whenever it wants to! So the full duplex side may send while the half duplex is already sending. The half duplex side dutifully adheres to the rules of Collision Detection. If it receives while sending, it backs off, waits a random amount of time, and retransmists. It also reports a collision. The fact that it backed off in the middle of sending means that it left behind an errored frame. It's also likely that the errored frame is shorter than a legal Ethernet frame (64 bytes) and constitute a runt, although the collision could have happened after 64 bytes, so the result could be a late collision. So the full duplex side receives this truncated packet from the half duplex side and reports a CRC error and either a runt or late collision. In summary, a duplex mismatch problem causes: CRC, runt, and late collisions at the Full Duplex station Collisions at the Half Duplex station, as well as Deferrals > I have always configured the CAT port manually so there isnt > any problems. The problem with manual is that the port might not participate in autonegotiation. The other side will assume that its partner is so old that it doesn't do autonegotiation and hence must be 10/Half. That's what the standard says it should do. So you could have one side set to 10/Full manually, and the other side deciding that it should be 10/Half. And here are some of the gory details from Troubleshooting Campus Networks, published by Wiley in 2002: "With autonegotiation, an interface advertises its abilities and detects the abilities of the device on the other end of the cable, called the link partner. The partners exchange their information in a reliable, acknowledged fashion. Autonegotiation compares the two sets of abilities and decides which technology to use, based on a standard priority for technologies. Once the highest-performance common mode is determined, autonegotiation relinquishes control to the appropriate technology and becomes transparent until the connection is broken or reset. The IEEE 802.3 autonegotiation standard specifies that an interface advertises its abilities in link pulses that encode a 16-bit word of information known as the Link Code Word (LCW). An interface sends a series of link pulses called a Fast Link Pulse (FLP) burst. An FLP burst is a sequence of 10BaseT Normal Link Pulses (NLPs). Each FLP is composed of 33 pulse positions, with the 17 odd-numbered positions corresponding to clock pulses and the 16 even-numbered positions corresponding to data pulses. All clock positions must contain a link pulse, although data positions do not need to contain a link pulse. The presence of a link pulse in a data position represents a logical 1 and the lack of a link pulse represents a logical 0. To ensure flexibility, the LCW has a Selector Field that allows 32 different definitions of the Technology Ability field. Currently, Selector Field values are defined for IEEE 802.3, 802.5 and 802.9. The Technology Ability Field is defined relative to the Selector Field. For 802.3, a device advertise its abilities as one of the following: A. 1000BaseT full-duplex B. 1000BaseT half-duplex C. 100BaseT2 full-duplex D. 100BaseTX full-duplex E. 100BaseT2 half-duplex F. 100BaseT4 half-duplex G. 100BaseTX half-duplex H. 10BaseT full-duplex I. 10BaseT half-duplex The technology abilities list also defines the priority hierarchy for resolving multiple common abilities. For example, if both devices support 10BaseT and 100BaseTX, autonegotiation causes the devices to use 100BaseTX instead of 10BaseT because 100BaseTX has a better priority. A disadvantage of not using autonegotiation is that you need to manually configure ports, which is time consuming and also risky. It is quite common for technicians to manually set the speed and duplex on one link partner and forget to configure the other partner, or to set the parameters differently on the partners, resulting in a mismatch. On the other hand, the disadvantage of using autonegotiation is that it may not work, causing annoying and often serious problems. Until recently, most engineers have recommended avoiding autonegotiation. Improvements in the interoperability of autonegotiation and the maturity of the technology may mean it is safe to start using autonegotiation again, but opinions vary. Autonegotiation problems can result from hardware incompatibilities and old or defective Ethernet software drivers. Some vendors� NICs or switches do not conform exactly to the IEEE 802.3u specification, which results in incompatibilities. Hardware incompatibility may also occur when vendors add advanced features, such as autopolarity, that are not in the IEEE 802.3u specification. (Autopolarity corrects reversed polarity on the transmit and receive twisted pairs.) Negotiating the speed of the connection usually proceeds correctly. If the speed doesn�t negotiate correctly, the interface does not work and the administrator hopefully notices and corrects the problem immediately. Duplex negotiation happens after the speed is set. Problems with duplex negotiation are harder to detect because any performance impact is dependent on the link partners transmitting at the same time. A workstation user who doesn�t send much traffic may not notice a problem, whereas a server could be severely impacted by a duplex mismatch. Sometimes problems with negotiation occur because configuration changes are made in software without any hardware change. For example, perhaps a switch is set for autonegotiation and the partner is a desktop manually configured for half-duplex 10BaseT. If the devices also support full-duplex 100BaseT, the user or network administrator might decide to upgrade to the faster capability. If the change is made in software, without pulling the cable or rebooting, negotiation link pulses may produce enough signal in the frequency band of the 10BaseT link pulses that the partners never see a loss of signal and don�t detect that there is a reason to renegotiate. The problem can also occur if a desktop OS changes the configuration while booting, but after the initial negotiation. The fix is to have the OS driver momentarily drop signal whenever speed or duplex is modified. If the OS doesn�t have that behavior, a workaround to the problem is to pull the cable momentarily or to reset the port, but network users don�t usually think to use such simple workarounds." _______________________________ Priscilla Oppenheimer www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=69703&t=69582 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
