Ethernet Layer 1 Wiring Speed and Duplex

Before making an Ethernet LAN functional, end-user devices, routers, and switches must be cabled correctly. To run with fewer transmission errors at higher speeds, and to support longer cable distances, variations of copper and optical cabling can be used. The different Ethernet specifications, cable types, and cable lengths per the various specifications are important for the exam, and are listed in the "Foundation Summary" section.

RJ-45 Pinouts and Category 5 Wiring

You should know the details of cross-over and straight-through Category 5 (Cat 5) or Cat 5e cabling for most any networking job. The EIA/TIA defines the cabling specifications for Ethernet LANs ( and, including the pinouts for the RJ-45 connects, as shown in Figure 1-1.

Figure 1-1 RJ-45 Pinouts with Four-Pair UTP Cabling f Key \ Topic

The most popular Ethernet standards (10BASE-T and 100BASE-TX) each use two twisted pairs (specifically pairs 2 and 3 shown in Figure 1-1), with one pair used for transmission in each direction. Depending on which pair a device uses to transmit and receive, either a straight-through or cross-over cable is required. Table 1-2 summarizes how the cabling and pinouts work.

Table 1-2 Ethernet Cabling Types

Table 1-2 Ethernet Cabling Types

Type of Cable


Key Pins Connected


T568A (both ends) or T568B (both ends)

1 - 1; 2 - 2; 3 - 3; 6 - 6


T568A on one end, T568B on the other

1 - 3; 2 - 6; 3 - 1; 6 - 2

Many Ethernet standards use two twisted pairs, with one pair being used for transmission in each direction. For instance, a PC network interface card (NIC) transmits on pair 1,2 and receives on pair 3,6; switch ports do the opposite. So, a straight-through cable works well, connecting pair 1,2 on the PC (PC transmit pair) to the switch port's pair 1,2, on which the switch receives. When the two devices on the ends of the cable both transmit using the same pins, a cross-over cable is required. For instance, if two connected switches send using the pair at pins 3,6 and receive on pins 1,2, then the cable needs to connect the pair at 3,6 on one end to pins 1,2 at the other end, and vice versa.

NOTE Cross-over cables can also be used between a pair of PCs, swapping the transmit pair on one end (1,2) with the receive pins at the other end (3,6).

Cisco also supports a switch feature that lets the switch figure out if the wrong cable is installed: Auto-MDIX (automatic medium-dependent interface crossover) detects the wrong cable and causes the switch to swap the pair it uses for transmitting and receiving, which solves the cabling problem. (As of publication, this feature is not supported on all Cisco switch models.)

Auto-negotiation, Speed, and Duplex

By default, each Cisco switch port uses Ethernet auto-negotiation to determine the speed and duplex setting (half or full). The switches can also set their duplex setting with the duplex interface subcommand, and their speed with—you guessed it—the speed interface subcommand.

Switches can dynamically detect the speed setting on a particular Ethernet segment by using a few different methods. Cisco switches (and many other devices) can sense the speed using the Fast Link Pulses (FLP) of the auto-negotiation process. However, if auto-negotiation is disabled on either end of the cable, the switch detects the speed anyway based on the incoming electrical signal. You can force a speed mismatch by statically configuring different speeds on either end of the cable, causing the link to no longer function.

Switches detect duplex settings through auto-negotiation only. If both ends have auto-negotiation enabled, the duplex is negotiated. However, if either device on the cable disables auto-negotiation, the devices without a configured duplex setting must assume a default. Cisco switches use a default duplex setting of half duplex (HDX) (for 10-Mbps and 100-Mbps interfaces) or full duplex (FDX) (for 1000-Mbps interfaces). To disable auto-negotiation on a Cisco switch port, you simply need to statically configure the speed and the duplex settings.

Ethernet devices can use FDX only when collisions cannot occur on the attached cable; a collision-free link can be guaranteed only when a shared hub is not in use. The next few topics review how Ethernet deals with collisions when they do occur, as well as what is different with Ethernet logic in cases where collisions cannot occur and FDX is allowed.

10 Chapter 1: Ethernet Basics CSMA/CD

The original Ethernet specifications expected collisions to occur on the LAN. The media was shared, creating a literal electrical bus. Any electrical signal induced onto the wire could collide with a signal induced by another device. When two or more Ethernet frames overlap on the transmission medium at the same instant in time, a collision occurs; the collision results in bit errors and lost frames.

The original Ethernet specifications defined the Carrier Sense Multiple Access with Collision Detection (CSMA/CD) algorithm to deal with the inevitable collisions. CSMA/CD minimizes the number of collisions, but when they occur, CSMA/CD defines how the sending stations can recognize the collisions and retransmit the frame. The following list outlines the steps in the CSMA/CD process:

1. A device with a frame to send listens until the Ethernet is not busy (in other words, the device cannot sense a carrier signal on the Ethernet segment).

2. When the Ethernet is not busy, the sender begins sending the frame.

3. The sender listens to make sure that no collision occurred.

4. If there was a collision, all stations that sent a frame send a jamming signal to ensure that all stations recognize the collision.

5. After the jamming is complete, each sender of one of the original collided frames randomizes a timer and waits that long before resending. (Other stations that did not create the collision do not have to wait to send.)

6. After all timers expire, the original senders can begin again with Step 1.

Collision Domains and Switch Buffering

A collision domain is a set of devices that can send frames that collide with frames sent by another device in that same set of devices. Before the advent of LAN switches, Ethernets were either physically shared (10BASE2 and 10BASE5) or shared by virtue of shared hubs and their Layer 1 "repeat out all other ports" logic. Ethernet switches greatly reduce the number of possible collisions, both through frame buffering and through their more complete Layer 2 logic.

By definition of the term, Ethernet hubs:

■ Operate solely at Ethernet Layer 1

■ Repeat (regenerate) electrical signals to improve cabling distances

■ Forward signals received on a port out all other ports (no buffering)

As a result of a hub's logic, a hub creates a single collision domain. Switches, however, create a different collision domain per switch port, as shown in Figure 1-2.

1 Collision Domain Multiple Collision Domain

10BASE-T, using Shared hub 10BASE-T, using Switch

1 Collision Domain Multiple Collision Domain

10BASE-T, using Shared hub 10BASE-T, using Switch

Switches have the same cabling and signal regeneration benefits as hubs, but switches do a lot more—including sometimes reducing or even eliminating collisions by buffering frames. When switches receive multiple frames on different switch ports, they store the frames in memory buffers to prevent collisions.

For instance, imagine that a switch receives three frames at the same time, entering three different ports, and they all must exit the same switch port. The switch simply stores two of the frames in memory, forwarding the frames sequentially. As a result, in Figure 1-2, the switch prevents any frame sent by Larry from colliding with a frame sent by Archie or Bob—which by definition puts each of the PCs attached to the switch in Figure 1-2 in different collision domains.

When a switch port connects via cable to a single other non-hub device—for instance, like the three PCs in Figure 1-2—no collisions can possibly occur. The only devices that could create a collision are the switch port and the one connected device—and they each have a separate twisted pair on which to transmit. Because collisions cannot occur, such segments can use full-duplex logic.

When a switch port connects to a hub, it needs to operate in HDX mode, because collisions might occur due to the logic used by the hub.

NOTE NICs operating in HDX mode use loopback circuitry when transmitting a frame. This circuitry loops the transmitted frame back to the receive side of the NIC, so that when the NIC receives a frame over the cable, the combined looped-back signal and received signal allows the NIC to notice that a collision has occurred.

Basic Switch Port Configuration

The three key configuration elements on a Cisco switch port are auto-negotiation, speed, and duplex. Cisco switches use auto-negotiation by default; it is then disabled if both the speed and duplex are manually configured. You can set the speed using the speed {auto I 10 I 100 I 1000} interface subcommand, assuming the interface supports multiple speeds. You configure the duplex setting using the duplex { auto I half I full} interface subcommand.

Example 1-1 shows the manual configuration of the speed and duplex on the link between Switchl and Switch4 from Figure 1-3, and the results of having mismatched duplex settings. (The book refers to specific switch commands used on IOS-based switches, referred to as "Catalyst IOS" by the Cisco CCIE blueprint.)

Figure 1-3 Simple Switched Network with Trunk

R3 P SW1 W


000f.2343.87cd 0/13

R4 P SW4 W




Example 1-1 Manual Setting for Duplex and Speed, with Mismatched Duplex switch1# show interface fa 0/13

FastEthernet0/13 is up, line protocol is up

Hardware is Fast Ethernet, address is 000a.b7dc.b78d (bia 000a.b7dc.b78d) MTU 1500 bytes, BW 100000 Kbit, DLY 100 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 100Mb/s ! remaining lines omitted for brevity

! Below, Switch1's interface connecting to Switch4 is configured for 100 Mbps, ! HDX. Note that IOS rejects the first duplex command; you cannot set duplex until ! the speed is manually configured. switch1# conf t

Enter configuration commands, one per line. End with CNTL/Z. switch1(config)# int fa 0/13 switch1(config-if)# duplex half

Duplex will not be set until speed is set to non-auto value switch1(config-if)# speed 100

05:08:41: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/13, changed state to down

05:08:46: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/13, changed state to up switch1(config-if)# duplex half !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

! NOT SHOWN: Configuration for 100/half on Switch4's int fa 0/13. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

! Now with both switches manually configured for speed and duplex, neither will be ! using Ethernet auto-negotiation. As a result, below the duplex setting on Switch1 ! can be changed to FDX with Switch4 remaining configured to use HDX. switch1# conf t

Enter configuration commands, one per line. End with CNTL/Z. switch1(config)# int fa 0/13 switch1(config-if)# duplex full

05:13:03: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/13, changed state to down

05:13:08: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/13, changed state to up switch1(config-if)#~Z switch1# sh int fa 0/13

FastEthernet0/13 is up, line protocol is up ! Lines omitted for brevity

Full-duplex, 100Mb/s ! remaining lines omitted for brevity ! Below, Switch4 is shown to be HDX. Note

! the collisions counters at the end of the show interface command. switch4# sh int fa 0/13

FastEthernet0/13 is up, line protocol is up (connected)

Hardware is Fast Ethernet, address is 000f.2343.87cd (bia 000f.2343.87cd) MTU 1500 bytes, BW 100000 Kbit, DLY 1000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Half-duplex, 100Mb/s ! Lines omitted for brevity 5 minute output rate 583000 bits/sec, 117 packets/sec 25654 packets input, 19935915 bytes, 0 no buffer Received 173 broadcasts (0 multicast) 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 173 multicast, 0 pause input 0 input packets with dribble condition detected 26151 packets output, 19608901 bytes, 0 underruns 54 output errors, 5 collisions, 0 interface resets 0 babbles, 54 late collision, 59 deferred 0 lost carrier, 0 no carrier, 0 PAUSE output 0 output buffer failures, 0 output buffers swapped out continues

...--------- 02:40:49: %CDP-4-DUPLEX MISMATCH: duplex mismatch discovered on FastEthernet0/13

'■Topic (not full duplex), with Switch1 FastEthernet0/13 (full duplex).

! Above, CDP messages have been exchanged over the link between switches. CDP ! exchanges information about Duplex on the link, and can notice (but not fix) ! the mismatch.

The statistics on switch4 near the end of the example show collisions (detected in the time during which the first 64 bytes were being transmitted) and late collisions (after the first 64 bytes were transmitted). In an Ethernet that follows cabling length restrictions, collisions should be detected while the first 64 bytes are being transmitted. In this case, Switch1 is using FDX logic, meaning it sends frames anytime—including when Switch4 is sending frames. As a result, Switch4 receives frames anytime, and if sending at the time, it believes a collision has occurred. Switch4 has deferred 59 frames, meaning that it chose to wait before sending frames because it was currently receiving a frame. Also, the retransmission of the frames that Switch4 thought were destroyed due to a collision, but may not have been, causes duplicate frames to be received, occasionally causing application connections to fail and routers to lose neighbor relationships.

Was this article helpful?

+1 0

Post a comment