This chapter covers the three most common interface error types you will encounter on the CompTIA Network+ N10-009 exam: CRC errors, runts, and giants. Understanding these errors is critical for troubleshooting Layer 2 connectivity issues—a core skill tested under Objective 5.2 (Given a scenario, troubleshoot common network connectivity issues). While not a standalone topic, questions involving interface errors appear in roughly 5–10% of exam questions, often as part of a larger troubleshooting scenario. You will be expected to interpret interface counters, identify the root cause, and recommend corrective actions.
Jump to a section
Imagine a large parcel sorting office where packages arrive from all over the world. Each package has a label with a destination address. The sorting office has a rule: every package must be a standard size—no smaller than a shoebox and no larger than a suitcase. When a package arrives, the sorter checks its size. If it's too small (a runt), it's likely a torn-off piece of a larger package and is immediately thrown away because it can't be delivered. If it's too large (a giant), it might have been overstuffed and could jam the conveyor belt, so it's also discarded. Additionally, the sorter checks the label for a checksum—a small printed number that must match a calculation on the label. If the checksum doesn't match (a cyclic redundancy check or CRC error), the label might have been damaged in transit, and the package is discarded because the address can't be trusted. In a network, frames are like these packages. The switch or router is the sorter. Runts are frames smaller than 64 bytes (the minimum Ethernet frame size). Giants are frames larger than 1518 bytes (the maximum standard Ethernet frame size). CRC errors occur when the frame check sequence (FCS) at the end of the frame doesn't match the calculated checksum, indicating corruption. All three are discarded by the receiving device, and the sender must retransmit. The sorting office analogy helps you remember: size limits and label integrity are checked before forwarding.
What Are Interface Errors and Why Do They Exist?
Network interfaces (ports on switches, routers, NICs) maintain counters that track various events, including errors. These counters are invaluable for diagnosing physical and data-link layer problems. The three specific error types—CRC, runts, and giants—all indicate that a received frame is invalid and must be discarded. The receiving device does not forward the frame; it simply drops it and increments the appropriate counter. The sender (if it is using a reliable protocol like TCP) will eventually retransmit, but the error indicates a problem that needs to be resolved.
CRC Errors: The Frame Check Sequence Mismatch
A Cyclic Redundancy Check (CRC) error occurs when the frame check sequence (FCS) at the end of an Ethernet frame does not match the CRC value calculated by the receiving device. The CRC is a 4-byte (32-bit) field that is computed over the entire frame (excluding the preamble and SFD) using a polynomial division algorithm (specifically, CRC-32 as defined in IEEE 802.3). The sender calculates the CRC and appends it to the frame. The receiver recalculates the CRC upon reception and compares it to the received FCS. If they differ, the frame is considered corrupt and is discarded.
Common causes of CRC errors: - Faulty or damaged cabling (e.g., bad termination, excessive length, electromagnetic interference) - Mismatched duplex settings (one side half-duplex, the other full-duplex) – this causes collisions and frame corruption - Faulty NIC or switch port hardware - Bad splice or connector
Key values: - CRC field size: 32 bits (4 bytes) - The CRC is computed over the destination MAC, source MAC, EtherType/Length, payload, and padding (if any). - The FCS is the last 4 bytes of the Ethernet frame.
What the exam tests: - CRC errors are almost always due to physical layer issues (cabling, duplex mismatch). - A high number of CRC errors often accompanies runts and giants. - You should check the cable, replace it, and verify duplex settings.
Runts: Frames Smaller Than the Minimum Size
A runt is an Ethernet frame that is smaller than the minimum allowed size of 64 bytes (from the destination MAC address through the FCS, not including the preamble). According to the IEEE 802.3 standard, any frame shorter than 64 bytes is considered a runt and is discarded by the receiving device. The minimum size ensures that a transmitting station can detect collisions before it finishes sending the frame (the collision detection window).
Why runts occur: - Collisions (especially in half-duplex environments): when a collision occurs, the transmitting stations abort transmission, resulting in a partial (short) frame called a collision fragment. These fragments are typically less than 64 bytes. - Faulty NIC that generates short frames. - Buffer underrun on a switch (rare).
Key values: - Minimum Ethernet frame size: 64 bytes (including FCS). - The preamble (8 bytes) and interframe gap (12 bytes) are not counted. - For VLAN-tagged frames (802.1Q), the minimum size is still 64 bytes, but the tag adds 4 bytes, so the payload can be as small as 42 bytes (instead of 46) to keep the total at 64.
What the exam tests: - Runts are often associated with collisions in half-duplex links. - If you see runts on a full-duplex link, suspect a hardware issue (bad port or NIC). - Runts can also be caused by a duplex mismatch (one side half-duplex, the other full-duplex).
Giants: Frames Larger Than the Maximum Size
A giant is an Ethernet frame that exceeds the maximum allowed size of 1518 bytes (standard Ethernet) or 1522 bytes for 802.1Q-tagged frames. Some devices also support jumbo frames (up to 9000 bytes or more), but those are considered giants if the interface does not have jumbo frame support enabled. Giants are discarded because they can exceed buffer sizes and cause network problems.
Why giants occur: - Misconfigured jumbo frame support: one device sends jumbo frames, but the receiving device does not support them. - Faulty NIC that generates oversized frames. - Software or driver bugs. - Improperly configured MTU (Maximum Transmission Unit) on the sender.
Key values: - Standard maximum Ethernet frame size: 1518 bytes (including FCS). - With 802.1Q tag: 1522 bytes. - Jumbo frames: typically 9000 bytes, but can vary. - MTU at Layer 3 (IP) is usually 1500 bytes (excluding Layer 2 headers). The Ethernet payload (IP packet) can be up to 1500 bytes, plus 14 bytes of header (MAC addresses + EtherType) and 4 bytes of FCS = 1518 bytes total.
What the exam tests: - Giants are often due to MTU mismatch or jumbo frame misconfiguration. - If a device sends frames larger than the interface MTU, the sender may fragment (at Layer 3) or the frame may be dropped as a giant. - Check MTU settings end-to-end.
How Interface Counters Work
Most switch and router operating systems (Cisco IOS, Juniper JunOS, etc.) maintain a set of counters per interface. You can view them with commands like show interfaces (Cisco) or show interfaces extensive (Juniper). The counters include:
- runts
- giants
- CRC (sometimes listed as CRC errors or input errors)
- frame (framing errors, often related to CRC)
- overrun (buffer overflow)
- underrun (buffer underrun)
On Cisco devices, the show interfaces command output includes a line like:
5 minute input rate 1000 bits/sec, 2 packets/sec
12345 packets input, 987654 bytes, 0 no buffer
Received 10 broadcasts, 0 runts, 0 giants, 0 throttles
5 input errors, 5 CRC, 0 frame, 0 overrun, 0 ignoredThe input errors counter includes CRC, frame, overrun, and ignored. Runts and giants are listed separately.
Relationship Between Error Types
Collisions can cause runts (collision fragments) and CRC errors (because the frame is corrupted).
A duplex mismatch often leads to both runts and CRC errors on the full-duplex side (because the half-duplex side detects collisions and sends fragments, while the full-duplex side receives them as runts and also may have CRC errors).
Faulty cabling can cause CRC errors and may also cause runts if the signal degrades so much that the frame appears shorter.
Troubleshooting Approach
When you see interface errors, follow these steps: 1. Identify the error type – runts, giants, or CRC. 2. Check the cable – replace with known-good cable, check for damage, ensure proper length (max 100 meters for twisted pair). 3. Check duplex settings – both sides must match (auto-negotiation recommended). 4. Check for jumbo frame mismatch – if giants are present, verify MTU settings. 5. Check for collisions – if runts are present and the link is half-duplex, collisions are normal; if full-duplex, something is wrong. 6. Replace hardware – if errors persist, swap the NIC or switch port.
Verification Commands
Cisco IOS:
show interfaces [interface-id]
show interfaces counters errors
show interfaces statusWindows (NIC):
netstat -eLinux:
ip -s link show [interface]
ethtool -S [interface]Juniper JunOS:
show interfaces [interface] extensive
show interfaces diagnostics optics [interface]Summary of Key Numbers
| Parameter | Standard Value | |-----------|----------------| | Minimum frame size | 64 bytes | | Maximum frame size (standard) | 1518 bytes | | Maximum frame size (802.1Q) | 1522 bytes | | CRC field size | 4 bytes (32 bits) | | Typical jumbo frame MTU | 9000 bytes | | Standard Ethernet MTU (L3) | 1500 bytes |
How Errors Interact with Upper Layers
When a frame is discarded due to CRC, runt, or giant, the sender does not receive an explicit notification at Layer 2. Upper-layer protocols (TCP, for example) will eventually detect missing segments through timeouts and duplicate ACKs, triggering retransmission. This can cause performance degradation. UDP applications may lose data entirely. Therefore, even a small percentage of interface errors can have a significant impact on throughput.
Duplex Mismatch Scenario
Consider a switch port configured for full-duplex connected to a device set to half-duplex. The half-duplex device will detect collisions and back off, but the full-duplex switch never defers. The half-duplex device may send frames that collide with the switch's transmissions, resulting in collision fragments (runts) on the half-duplex side. The full-duplex switch will receive these fragments as runts and may also see CRC errors. The half-duplex device will see late collisions and CRC errors. This is a classic exam scenario.
Jumbo Frame Misconfiguration
If a server is configured to send jumbo frames (MTU 9000) but the switch port has an MTU of 1500, the switch will drop frames that exceed 1518 bytes as giants. The solution is to enable jumbo frame support on the switch port (e.g., mtu 9216 on Cisco switches) or reduce the server's MTU.
Identify the Error Type
Use the `show interfaces` command (Cisco) or equivalent to view interface counters. Look for non-zero values in the `runts`, `giants`, and `CRC` fields. Note that `input errors` includes CRC, frame, overrun, and ignored, but runts and giants are separate. If you see runts, check if the link is half-duplex or full-duplex. If CRC errors are present, suspect cabling or duplex mismatch. If giants are present, suspect MTU mismatch.
Check Duplex and Speed Settings
Verify that both ends of the link are set to the same duplex and speed. Use `show interfaces [interface]` to see the current settings. On Cisco switches, `show interfaces status` shows duplex and speed. If one side is half-duplex and the other full-duplex, you will see errors (runts and CRC) on the full-duplex side and late collisions on the half-duplex side. The fix is to set both sides to auto-negotiate or manually match the settings.
Inspect Physical Cabling
Check the cable for damage, loose connections, or excessive length (max 100 meters for twisted pair). Use a cable tester to verify pinouts and continuity. If the cable is near sources of interference (fluorescent lights, motors), replace it with shielded cable or reroute it. Bad cabling is the most common cause of CRC errors. Replace the cable with a known-good one and monitor the counters.
Check for Jumbo Frame Mismatch
If giants are present, determine the MTU configured on each device. Use `show interfaces [interface]` to see the MTU (Cisco). Compare with the expected MTU (usually 1500 for Ethernet). If one device is sending jumbo frames (e.g., MTU 9000) and the other is not, the receiving device will drop frames larger than 1518 bytes as giants. Enable jumbo frame support on the switch port (e.g., `mtu 9216` on Cisco switches) or reduce the sender's MTU.
Replace Hardware if Necessary
If errors persist after checking cabling and duplex, try replacing the NIC or switch port. A faulty port can generate CRC errors, runts, or giants. If possible, move the cable to a different switch port and see if errors continue. If they stop, the original port is bad. Similarly, replace the NIC in the end device. This step isolates hardware failure from cable issues.
Enterprise Scenario 1: Data Center ToR Switch Connectivity
A large data center uses top-of-rack (ToR) switches connected to servers via Cat6a cabling. After a cable replacement, the network team notices CRC errors increasing on the ToR switch port connected to a storage server. The counter shows 500 CRC errors in 10 minutes. The server is running a critical database application that uses TCP, so retransmissions cause latency spikes. The team checks the cable: it's a new Cat6a patch cable, but it is routed next to a power cable. They replace it with a shielded Cat6a cable and reroute it away from the power cable. The CRC errors stop immediately. The lesson: even new cables can be susceptible to EMI if not properly shielded or routed.
Enterprise Scenario 2: VoIP Phone Duplex Mismatch
An office deploys VoIP phones that daisy-chain to PCs. The switch ports are configured for auto-negotiation, but some phones are manually set to 100 Mbps half-duplex (a common misconfiguration). Users report intermittent call drops and poor voice quality. The network engineer checks the switch port counters and sees hundreds of runts and CRC errors on the ports connected to those phones. The fix is to configure the switch port for auto-negotiation (which is the default) and ensure the phone also uses auto-negotiation. After correcting the settings, errors drop to zero. The exam loves this scenario: runts + CRC = duplex mismatch.
Enterprise Scenario 3: Jumbo Frame Misconfiguration in a SAN
A storage area network (SAN) uses iSCSI over Ethernet with jumbo frames (MTU 9000) to maximize throughput. The SAN switches are configured with an MTU of 9216 bytes (to accommodate jumbo frames plus headers). However, a new switch was added with the default MTU of 1500. The iSCSI traffic to that switch experiences giants and performance drops. The engineer discovers the MTU mismatch and configures the new switch's interface with mtu 9216. Giants disappear. This scenario tests your understanding that giants are often due to MTU mismatch, not cabling.
What N10-009 Tests
Objective 5.2 (Troubleshoot common network connectivity issues) includes interface errors as a subset. You will be given a scenario with symptoms (e.g., users report slow performance, ping losses) and interface counter values. You must identify the error type and the most likely cause. The exam does not test deep CRC calculation but expects you to know:
CRC errors = physical layer or duplex mismatch
Runts = collisions or duplex mismatch
Giants = MTU mismatch or jumbo frame misconfiguration
Most Common Wrong Answers
Choosing 'broadcast storm' when seeing runts: Candidates see many small frames and think broadcast storm. But runts are undersized frames, not broadcasts. Broadcast storms cause high CPU but not necessarily runts.
Blame faulty switch for CRC errors: While possible, the most common cause is cabling or duplex mismatch. The exam expects you to check the cable first.
Confusing runts with giants: Candidates mix up the sizes. Remember: runts are too small (<64 bytes), giants are too large (>1518 bytes).
Thinking CRC errors are caused by software: CRC is a Layer 2 check; software errors at higher layers do not cause CRC mismatches.
Numbers and Terms That Appear Verbatim
64 bytes (minimum frame size)
1518 bytes (maximum standard frame size)
1522 bytes (with 802.1Q tag)
The phrase 'frame check sequence (FCS)' is used interchangeably with CRC.
'Collision fragment' is another term for a runt caused by a collision.
Edge Cases and Exceptions
Jumbo frames: Some exam questions may mention jumbo frames (up to 9000 bytes). If a device receives a jumbo frame but doesn't support it, it counts as a giant.
VLAN tagging: The minimum frame size remains 64 bytes even with a 4-byte tag; the payload is reduced to 42 bytes. The maximum becomes 1522 bytes.
Half-duplex vs full-duplex: In half-duplex, runts from collisions are normal to some degree. In full-duplex, any runt indicates a problem.
CRC errors on fiber: Fiber can also have CRC errors due to dirty connectors, bad splices, or excessive attenuation.
How to Eliminate Wrong Answers
If the question mentions 'undersized frames', eliminate any answer that mentions 'too large' or 'MTU'—that's for giants.
If CRC errors are present and the answer suggests rebooting the server, it's wrong—CRC is physical.
If runts are present and the answer says 'replace the cable', that may not fix runts caused by duplex mismatch. Check duplex first.
Always correlate error types: runts + CRC often point to duplex mismatch; giants alone point to MTU.
CRC errors indicate a frame check sequence mismatch, usually due to cabling or duplex mismatch.
Runts are frames smaller than 64 bytes; common causes: collisions (half-duplex) or faulty hardware (full-duplex).
Giants are frames larger than 1518 bytes (or 1522 with 802.1Q); common cause: MTU mismatch.
The minimum Ethernet frame size is 64 bytes (including FCS); the maximum is 1518 bytes (standard).
Duplex mismatch often produces both runts and CRC errors on the full-duplex side.
To troubleshoot, always check cabling first, then duplex settings, then MTU settings.
On Cisco devices, use 'show interfaces' to view error counters.
Jumbo frames can be up to 9000 bytes; if not supported, they are counted as giants.
CRC errors are hardware-level (Layer 1/2); software cannot cause them.
If runts appear on a full-duplex link, suspect a hardware fault (NIC or port).
These come up on the exam all the time. Here's how to tell them apart.
Runts
Frames smaller than 64 bytes
Commonly caused by collisions or duplex mismatch
Discarded by receiving device
Often seen alongside CRC errors in duplex mismatch
Can be normal in half-duplex if collisions are low
Giants
Frames larger than 1518 bytes (or 1522 with VLAN tag)
Commonly caused by MTU mismatch or jumbo frame misconfiguration
Discarded by receiving device
Not typically associated with CRC errors
Never normal; always indicates a problem
Mistake
CRC errors are caused by software bugs in the operating system.
Correct
CRC errors are a Layer 2 physical layer issue. The CRC is computed by hardware (NIC) and checked by hardware. Software bugs can cause other issues but not CRC mismatches. The root cause is almost always cabling, duplex mismatch, or faulty hardware.
Mistake
Runts are always caused by collisions.
Correct
While collisions are the most common cause of runts (collision fragments), runts can also be caused by faulty NICs that generate undersized frames or by buffer underruns. In full-duplex links, runts are never due to collisions and indicate a hardware problem.
Mistake
Giants are always due to jumbo frames.
Correct
Jumbo frames are a common cause, but giants can also be caused by faulty NICs that generate oversized frames or by software/driver bugs. Additionally, a device may send frames larger than the interface MTU if fragmentation is disabled at Layer 3.
Mistake
If you see CRC errors, you should immediately replace the switch.
Correct
CRC errors are most often caused by cabling or duplex mismatch. Replacing the switch should be a last resort after checking cables, duplex settings, and the NIC on the connected device. Always start with the simplest fix.
Mistake
The minimum Ethernet frame size is 64 bytes including the preamble.
Correct
The preamble (8 bytes) and start frame delimiter (SFD) are not counted. The minimum frame size of 64 bytes includes the destination MAC (6), source MAC (6), EtherType (2), payload (46), and FCS (4). The preamble is separate.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
CRC errors are a specific type of frame error where the frame check sequence (FCS) does not match the calculated CRC. 'Frame errors' is a broader term that can include CRC errors, alignment errors, and other framing issues. On Cisco devices, the 'input errors' counter includes CRC, frame, overrun, and ignored. Frame errors often refer to alignment errors (non-integer number of bytes). For the exam, treat CRC and frame errors similarly—they point to physical layer problems.
Indirectly, yes. A faulty cable can cause signal degradation that leads to collisions (in half-duplex) or frame corruption that results in a runt. However, the direct cause of a runt is a collision or a hardware fault. If the cable is bad, you will likely see CRC errors first. Runts from cabling are rare; they are more commonly due to duplex mismatch or collisions.
A late collision occurs when a collision happens after the first 64 bytes of a frame have been transmitted. This usually indicates a cable length exceeding the maximum (100 meters for twisted pair) or a duplex mismatch. Late collisions produce collision fragments that are runts. On Cisco interfaces, late collisions are counted separately (e.g., 'late collisions' in show interfaces). If you see late collisions and runts, suspect a duplex mismatch or cable length issue.
Use the 'show interfaces [interface]' command and look for the MTU value. The default MTU for Ethernet is 1500 bytes. If jumbo frames are enabled, the MTU will be higher, typically 9216 bytes. You can also check the system MTU with 'show system mtu'. To enable jumbo frames, use the 'system mtu jumbo [size]' command (global config) or 'mtu [size]' on a specific interface.
Yes. CRC errors on fiber can be caused by dirty connectors, bad splices, excessive attenuation, or faulty transceivers (SFPs). The troubleshooting steps are similar: clean the connectors, check the light levels, and replace the SFP or cable if needed. On Cisco, use 'show interfaces transceiver' to check optical power levels.
An overrun occurs when the switch or NIC receives frames faster than it can process them, causing the receive buffer to overflow. This is a performance issue, not a physical layer problem. Overruns can be caused by a high-speed link feeding a slower device or by a malfunctioning driver. CRC errors are due to corruption, not speed mismatch.
A small number of CRC errors (e.g., 10 per day) on a busy link may be acceptable, but any persistent increase should be investigated. The exam expects you to treat any non-zero error count as a symptom that needs troubleshooting. In production, a few errors might be due to transient noise, but a growing counter indicates a problem.
You've just covered Interface Error Types: CRC, Runts, Giants — now see how well it sticks with free N10-009 practice questions. Full explanations included, no account needed.
Done with this chapter?