What happens when a NIC with a faster line speed, say 1000Mbps, communicates with something on the same link running a different speed, say 100Mbps? What happens when a NIC on one side can operate in full-duplex (sending and receiving on different pairs and thus simultaneously) while its link partner (such as a repeating hub) can only do half-duplex? Obviously, link partners need some mechanism to help them advertise their capabilities to each other so the highest common denominator can be used; this is what is called Autonegotiation.
Autonegotiation was introduced into the 802.3 family in 802.3u, which introduced 100Base-TX; therefore anything that doesn’t offer autonegotiation on twisted pair is assumed to be 10Base-T. Occassionally, autonegotiation may fail on some older (implemented according to 802.3 prior to 1998 and thus prior to Gigabit Ethernet) products, so you can also set the capabilities manually, forgoing autonegotiation. However, autonegotiation is mandatory for Gigabit Ethernet running over copper.
Autonegotiation is implemented using something called the “Medium Independent Interface”, or MII for short. On Linux, we can inspect and configure the status of the MII using a tool such as mii-tool, although not all device drivers will expose this functionality. To give you an idea, here is what you would see on Client1. You can see from the “link ok” that a link has been established.
sudo mii-tool --verboseeth0: no autonegotiation, 1000baseT-FD flow-control, link ok product info: Yukon 88E1011 rev 4 basic mode: autonegotiation enabled basic status: autonegotiation complete, link ok capabilities: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD advertising: 1000baseT-HD 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD ↩ 10baseT-HD flow-control link partner: 1000baseT-FD 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
On Windows, you can inspect and modify these settings by Configuring the adaptors Properties, as shown in Figure 4, “Inspecting MII Properties in Windows”.
But autonegotiation by itself is not entirely sufficient; what happens when one station is sending at the full capability of a 1000Base-T but another station in the segment (not its link partner, perhaps connected to another port on a switch) is only 100Base-TX? Typically, we would expect a higher layer protocol, such as TCP, to handle this flow-control. 802.3x is a standard that specifies Ethernet flow control using a special type of frame called a PAUSE frame. However, this can prove problematic as it can end up slowing down a significant portion of a network when one station is receiving too much data. Flow control is generally not used in the core of a network, and it can interfere with other performance measures such as Quality of Service (QoS). It is useful to know the position of various vendors on the issue of flow control.
For someone beginning network administration, it is enough to realise that it exists, that it can be problematic, and that if you see a lot of PAUSE frames on a segment, you should probably redesign some part of your network.