25 March 2010

Auto-Negotiation

When I get called to a client’s site to diagnose a network slowdown or a “slow” device, the first things I look at are the error statistics and the auto-negotiation settings on the switches and the devices connected to them. If I had to list the most common problems I’ve seen during my years in the field, auto-negotiation issues would be in the top five, if not number one. Why is auto-negotiation such a widespread problem?

The truth is, too many people don’t really understand what it does and how it works, so they make assumptions that lead to trouble.

What Is Auto-Negotiation?

Auto-negotiation is the feature that allows a port on a switch, router, server, or other device to communicate with the device on the other end of the link to determine the optimal duplex mode and speed for the connection. The driver then dynamically configures the interface to the values determined for the link. Let’s examine these parameters:

Speed
Speed is the rate of the interface, usually listed in megabits per second (Mbps). Common Ethernet speeds include 10 Mbps, 100 Mbps, and 1,000 Mbps. 1,000 Mbps Ethernet is also referred to as Gigabit Ethernet.

Duplex
Duplex refers to how data flows on the interface. On a half-duplex interface, data can only be transmitted or received at any given time. A conversation on a two-way radio is usually half-duplex each person must push a button to talk, and, while talking, that person cannot listen. A full-duplex interface, on the other hand, can send and receive data simultaneously. A conversation on a telephone is full duplex.

How Auto-Negotiation Works

First, let’s cover what auto-negotiation does not do: when auto-negotiation is enabled on a port, it does not automatically determine the configuration of the port on the other side of the Ethernet cable and then match it. This is a common misconception that often leads to problems. Auto-negotiation is a protocol, and as with any protocol, it only works if it’s running on both sides of the link. In other words, if one side of a link is running auto-negotiation, and the other side of the link is not, auto-negotiation cannot determine the speed and duplex configuration of the other side. If auto-negotiation is running on the other side of the link, the two devices decide together on the best speed and duplex mode. Each interface advertises the speeds and duplex modes at which it can operate, and the best match is selected (higher speeds and full duplex are preferred). The confusion exists primarily because auto-negotiation always seems to work. This is because of a feature called parallel detection, which kicks in when the auto-negotiation process fails to find auto-negotiation running on the other end of the link. Parallel detection works by sending the signal being received to the local 10Base-T, 100Base-TX, and 100Base-T4 drivers. If any one of these drivers detects the signal, the interface is set to that speed.

Parallel detection determines only the link speed, not the supported duplex modes. This is an important consideration because the common modes of Ethernet have differing levels of duplex support:

10Base-T
10Base-T was originally designed without full-duplex support. Some implementations of 10Base-T support full duplex, but most do not.

100Base-T
100Base-T has long supported full duplex, which has been the preferred method for connecting 100-Mbps links for as long as the technology has existed. However, the default behavior of 100Base-T is usually half duplex, and it must be set to full duplex, if so desired.

Because of the lack of widespread full-duplex support on 10Base-T, and the typical default behavior of 100Base-T, when auto-negotiation falls through to the parallel detection phase (which only detects speed), the safest thing for the driver to do is to choose half-duplex mode for the link.

When Auto-Negotiation Fails

When auto-negotiation fails on 10/100 links, the most likely cause is that one side of the link has been set to 100/full, and the other side has been set to auto-negotiation. This results in one side being 100/full, and the other side being 100/half.

Figure shows a half-duplex link. In a half-duplex environment, the receiving (RX) line is monitored. If a frame is present on the RX link, no frames are sent until the RX line is clear. If a frame is received on the RX line while a frame is being sent on the transmitting (TX) line, a collision occurs. Collisions cause the collision error counter to be incremented and the sending frame to be retransmitted after a random back-off delay.











Figure shows a full-duplex link. In full-duplex operation, the RX line is not monitored, and the TX line is always considered available. Collisions do not occur in full-duplex mode because the RX and TX lines are completely independent.











When one side of the link is full-duplex, and the other side is half-duplex, a large number of collisions will occur on the half-duplex side. Because the full-duplex side sends frames without checking the RX line, if it’s a busy device, chances are it will be sending frames constantly. The other end of the link, being half-duplex, will listen to the RX line, and will not transmit unless the RX line is available. It will have a hard time getting a chance to transmit, and will record a high number of collisions, resulting in the device appearing to be slow on the network. The issue may not be obvious because a half-duplex interface normally shows collisions. The problem should present itself as excessive collisions.

Figure shows a link where auto-negotiation has failed.












NOTE: In the real world, if you see that an interface that is set to auto-negotiation has negotiated to 100/half, chances are the other side is set to 100/full. 100-Mbps interfaces that do not support full duplex are rare, so properly configured auto-negotiation ports should almost never end up configured for half duplex.

Auto-Negotiation Best Practices

Using auto-negotiation to your advantage is as easy as remembering one simple rule:

Make sure that both sides of the link are configured the same way. If one side of the link is set to auto-negotiation, make sure the other side is also set to auto-negotiation. If one side is set to 100/full, make sure the other side is also set to 100/full.

NOTE: Be careful about using 10/full, as full duplex is not supported on all 10Base-T Ethernet devices.

Gigabit Ethernet uses a substantially more robust auto-negotiation mechanism than the one described in this chapter. Gigabit Ethernet should thus always be set to auto-negotiation, unless there is a compelling reason not to do so (such as an interface that will not properly negotiate). Even then, this should be considered a temporary workaround until the misbehaving part can be replaced.

Configuring Auto-Negotiation

For Cisco switches, auto-negotiation is enabled by default. You can configure the speed and duplex mode manually with the speed and duplex interface commands in IOS. You cannot set the duplex mode without first setting the speed. The switch will complain if you attempt to do so:

2950(config-if)# duplex half
Duplex can not be set until speed is set to non-auto value To set the speed of the interface, use the speed command. If the interface has previously been configured, you can return it to auto-negotiation with the auto keyword:

2950(config-if)# speed ?
10 Force 10 Mbps operation
100 Force 100 Mbps operation
auto Enable AUTO speed configuration

Once you’ve set the speed, you can set the duplex mode to auto, full, or half:

2950(config-if)# duplex ?
auto Enable AUTO duplex configuration
full Force full duplex operation
half Force half-duplex operation

Author: Gary A. Donahue




biOos

1 comment:

Unknown said...

As someone that is in the beginning stages of his CCENT/CCNA studies but have been in IT for over 10 years. Thank you for making such a clear post on what has probably been a major headache for many an engineer in the companies I've worked with. You'd think I'd have gone for my CCNA earlier, but such is life, this post has helped me immensely as 1. my simulation in GNS3 was giving me the same error with a Router and Switch and 2. It's added to my Knowledgebase Bank for what can be a long term troubleshooting technique.

Thank you once again!

Rene