This post will cover some basics of the IEEE 802.3 Ethernet specification and its application in Cisco gear. My expectation is that you have read or will read the Cisco Press study guides to gain a deeper understanding of some of the underlying technologies that I will reference in this document.

Relevant CCNA Topics Covered: Interconnecting Cisco Networking Devices Part 1 (100-105) Section 2.0

     There are two modes of operation identified in the IEEE standard for Ethernet, Full-duplex and Half-duplex.  The MAC protocol CSMA/CD (Carrier Sense Multi-Access/Collision Detect) is what allows communication to work on a half-duplex link, and I use the term “work” loosely. Once a collision is detected on the shared medium, CSMA/CD regulates when a workstation can transmit in an effort to prevent future collisions. What is a collision? A collision is generated when two workstations send data over an Ethernet link at the same time, which is a common side effect realized with half-duplex communications. This collision is really a merging of voltage on the wire which is detected by the hardware in the workstation NIC. This is generally an issue associated with Hub technology, and is not so much an issue now that switches are the defacto standard for layer 2 communication on the LAN. A switch allows full-duplex (simultaneous transmission and reception) communication on all ports, allowing each port to serve as its own collision domain as opposed to a hub which puts all ports within the same collision domain (yikes!).

     The widely accepted Layer 1 medium for Ethernet networks (horizontal cabling) is Cat5/6 UTP. Generally when the term “Ethernet Cable” is used it’s referring to a straighthrough cable type using wires 1, 2, 3, & 6 for Tx and Rx traffic. I’m sure in your studying that you’ve read about “like” devices needing a crossover cable to facilitate communication. For instance if you connect two switches, or two routers together a crossover cable is needed. This assertion is correct in theory since the ports on these like devices will generally be transmitting and receiving traffic on the same cable pairs. In reality though this is often not the case when utilizing current cisco devices due to the “auto-mdix” feature. Automatic medium-dependent interface crossover allows the ethernet port to detect the needed cable orientation for the link and adjusts the Tx and Rx distribution appropriately.

     Once you connect together two ethernet capable devices with an ethernet cable, there needs to be an agreement on the speed and duplex of the link. The speed and duplex settings can be either hard-coded on both sides or set to auto-negotiate on both sides but not a mixture of the two configurations. Cisco ethernet ports use Fast Link Pulse technology to detect and negotiate these parameters and if there is no response due to a manual configuration on one side, there is an automatic switch to half-duplex on the side set to auto-negotiate. This behavior is an important one to look out for especially if you’re investigating complaints of slow speeds, application latency, or VoIP call quality issues. The first order of business in these types of investigations is to examine any interfaces within the transport path for half-duplex operation. If you can only see one side of a link then you need to examine the interface output for errors. See the fastethernet output below via the “sh interface fa0/0” command. *This interface is hardcoded to Full/100


FastEthernet0/0 is up, line protocol is up
***Some output omitted***
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 1000 bits/sec, 1 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
52225001 packets input, 3606634773 bytes
Received 654568 broadcasts, 0 runts, 0 giants, 0 throttles
21625 input errors, 21625 CRC, 10917 frame, 0 overrun, 0 ignored
0 watchdog
0 input packets with dribble condition detected
70708492 packets output, 1223321865 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier

     The presence of incrementing CRC errors on the link is a good indication of a half-duplex link. Based on the previous observation of auto-negotiation behavior it would be safe to assume the opposite interface on the link is set to auto-negotiate.

     The last subject we’ll touch is the interface line protocol. Depending on what layer 2 technology you’re using the line protocol status can be influenced by different things, however the underlying problem is the same. A component of the layer 2 protocol has failed causing the line protocol to be down. In the case of Ethernet a frame is produced with itself as the source and destination with a type code of 0x9000, and the keepalive frame is expected to be received on the same interface. This process determines whether the link is capable of transmitting Ethernet frames at any given time vs. verifying a neighbor is up. The first value in the interface status (FastEthernet0/0 is up, line protocol is up) signifies whether the layer 1 link to the connected device is detected. This is also signified by the “link light” on the port itself. If the interface status is Up/Up then this signifies that the layer 1 link is good and the Ethernet keepalives are being received. The caveat to this is that some older IOS software will put the interface in an Up/Down status even with no layer 1 connectivity (no cable plugged in). While this is a rare occurrence just be aware that it’s possible.

     Thank you for taking the time to read this post, feel free to leave a comment with any feedback or questions, and have a great day! If you find yourself in need of the ICND1 100-105 here’s may affiliate link to amazon where you can purchase: CCENT/CCNA ICND 100-105 Official Cert Guide by Wendell Odom (2016-05-17)

-Eric

1 Comment

Leave a comment

Your email address will not be published. Required fields are marked *