Ethernet
The written exam can test you as much or as little as it wants in this area, however there's not much to do with hands-on for this topic. The lab itself will already be set up. You will not need to worry about the pinout of a cable or the distance limitations with prestaged devices.
Although the devices in the lab are already racked and cabled, they do not necessarily start with a fresh (out-of-the-box-default) configuration. That would probably be too easy. Although the lab environment is a 'modeling' of systems, it still tries to aim for 'real-world' relevance. You probably already work as a Network Engineer if you're attempting the CCIE R/S. How much of your job is new install and how much is break/fix? Even the newly installed equipment gets slid into an existing infrastructure. Not many of us get to set up Data Centers from scratch. However, I found this interesting in my reading: [from the Practical Studies Vol I]
Unlike 10-Mbps Ethernet and 100-Mbps Ethernet, the GMII is an electrical specification and does not include a physical connector. Cisco's physical Gigabit interfaces are called GBICs . The type of GBIC determines the physical gigabit connection. There are currently multimode fiber (MMF), single-mode fiber (SMF), and UTP GBICs, as well as a Cisco proprietary GBIC called a Gigastack.
One of the things I've learned from dealing with legacy equipment is that it is often hard-coded to 100 Full. Many times this is hard-coded only on one side. This will cause a duplex mismatch. This is something that you might see in the lab. One of the biggest mistakes you can make is to assume that anything 'configured' has been configured correctly.
From my readings, that's about all I can say that's "lab-related" regarding speed and duplex. However, I did run across something that may be useful in a lab situation. During a recent power outage, we had some server-switch port issues. The switch port showed up/up but we could not ping the end device - even from the switch. If you looked in the arp table on the switch, the MAC corresponding to the IP address showed INCOMPLETE. From our end of the switch, we couldn't see anything wrong - because our side was hard-coded to 100 Full. You would think that the reason it was hard-coded was because the other side was 100 Full, but it was, in fact, set to autonegotiate. For whatever reason, setting the server side to 100 Full did not resolve the issue (still could not ping the end device). To resolve this, we had to leave the server set to auto -- and set the switchport to auto. This resulted in the port showing a-100 a-half (as expected). Once it negotiated at half duplex, we hard-coded the switch side to 100 Full. For whatever reason, the NIC and the switch were finally happy at 100 Full on both sides and the end device responded to ping. I am not sure what speed and duplex have to do with arp, but I do know it worked. Perhaps that particular implementation of the standard says that if you've already determined that you can't negotiate with the other side, quit talking? Then, maybe, the sudden negotiation process nudges the NIC into finally responding to arp? I don't know. I would like to duplicate this in a lab situation and find out what actually causes this to happen - or find some documentation regarding a definitive answer.
Along the lines of 'work-related,' I also found the following information:
Configuring and Troubleshooting Ethernet 10/100/1000Mb Half/Full Duplex Auto-Negotiation
The status is connected on both ports, which means that a link pulse is detected from the other port. The status can be connected even if duplex is incorrectly negotiated or incorrectly configured. ... This step shows that it is possible for a link partner to detect the speed at which the other link partner operates, even though the other link partner is not configured for auto-negotiation. In order to detect the speed, the link partner senses the type of electrical signal that arrives and sees if it is 10 Mb or 100 Mb. This is how switch B determines that port 1/1 operates at 10 Mb.It is not possible to detect the correct duplex mode in the same method that the correct speed can be detected. In this case, where the 1/1 port of switch B is configured for auto-negotiation and the 1/1 port of switch A is not, the 1/1 port of switch B is forced to select the default duplex mode. On Catalyst Ethernet ports, the default mode is auto-negotiate. If auto-negotiation fails, the default mode is half-duplex.
This example also shows that a link can be successfully connected when there is a mismatch in the duplex modes. Port 1/1 on switch A is configured for full-duplex while port 1/1 on switch B is defaulted to half-duplex. Configure both link partners to avoid this.
...
The "a-" prefix on the Duplex and Speed status fields does not always mean that the current behavior is negotiated. Sometimes it can mean that the port is not configured for a speed or duplex mode.
...
The previous output from switch B shows duplex as a-half and speed as a-10. This indicates that the port operates at 10 Mb in half-duplex mode. In this example, however, the link partner on this port (port 1/1 on switch A) is configured for full and 10 Mb. Therefore, it is not possible for port 1/1 on switch B to auto-negotiate current behavior. This proves that the "a-" prefix only indicates a willingness to perform auto-negotiation, and not that auto-negotiation actually took place.
...
It is important to note that this message [Duplex mismatch] is created by the Cisco Discovery Protocol (CDP), not the 802.3 auto-negotiation protocol.
...
If you want to hard code the speed and duplex on a switch that runs Cisco IOS Software (turn off auto-negotiation), issue the speed and duplex commands underneath the specific interface. Duplex is subservient to speed in the sense that if speed is set to auto, then the duplex cannot be manually set. You might see cyclic redundancy check (CRC) error messages when both the speed and duplex settings are hardcoded on the two devices. This might be because any one of the devices runs an earlier version of Cisco IOS. You can upgrade the Cisco IOS or set the speed and duplex to auto on both devices in order to resolve this.
Troubleshooting Cisco Catalyst Switches to NIC Compatibility Issues
Teaming of Network Interface Cards, or NIC Teaming, can cause instability in the networks. Such setups can introduce disruptions to the Spanning tree and can make it undergo frequent recomputations. If intermittent loss of connectivity to NIC teamed servers occurs for devices or hosts in the same VLAN, try to disable NIC teaming. If the connectivity stabilizes, refer to the NIC vendor documentation in order to tune the NIC teaming configuration.Use one of these methods in order to implement NIC teaming:
Server Virtual Address (SVA): The SVA is used when you want other devices in the network to see the teamed NICs as one physical device with one MAC address. When you use this setup, you must have one of the NICs in a standby state, and the other in active state. Otherwise, you would experience duplicate MAC addresses sent around the network from the SVA.
Separate NIC MAC Addresses: In this setup, you can use both of your NIC cards that run separate MAC addresses. In this mode, both NICs appear from a network perspective to be two separate physical devices. You can configure the Fault Tolerant Mode with Load Balancing option in order to avoid the problem of duplicate MAC addresses on the network.
...
NIC Compatibility and Operation Issues [chart]Sun Microsystems QFE Card
Unable to manually set speed and duplex correctly.
Manually setting speed and duplex only affects the first of four ports.
Contact vendor technical support to obtain the latest driver to resolve the issue.
Sun Microsystems v1.1 Gigabit Cards
Unable to establish link.
V1.1 can potentially not establish link to switch.
Contact vendor technical support or v2.0 Gigabit Card.
...
Based on IEEE 802.3u, it is not possible to manually configure one link partner for 100 Mbps, full-duplex and still autonegotiate to full-duplex with the other link partner. If you attempt to configure one link partner for 100 Mbps, full-duplex and the other link partner for autonegotiation, it results in a duplex mismatch. This is because one link partner autonegotiates and does not see any autonegotiation parameters from the other link partner and defaults to half-duplex.
...
As described in Appendix B: Understanding How Autonegotiation Works, pulses within the FLP are used to derive code words that exchange link partner capabilities. The first code word exchanged is referred to as the base page. It informs each link partner of the message type, IEEE 802.3 or IEEE 802.9a, and a technology ability field. This technology ability field is encoded to exchange the maximum operational speed and duplex of each link partner.
Gigabit Interface Converter Installation Note
When you troubleshoot link issues on Gigabit Ethernet, it is also important to verify the use of the correct Gigabit Interface Converter (GBIC) adapter with the correct cable distance. Refer to Gigabit Interface Converter Installation Note for information on distances and cable specifications required for different versions of GBIC adapters.
The charts on the link above may someday save your job or reputation.