show controllers
Displays detailed hardware and interface controller status information, used to diagnose physical layer issues such as cable faults, clocking problems, or interface errors.
Definition: show controllers is a Cisco IOS privileged exec command. Displays detailed hardware and interface controller status information, used to diagnose physical layer issues such as cable faults, clocking problems, or interface errors.
Overview
The 'show controllers' command is a powerful diagnostic tool in Cisco IOS that provides low-level hardware and controller status information for interfaces. Unlike higher-level commands such as 'show interfaces' or 'show ip interface brief', which focus on logical and operational status, 'show controllers' dives into the physical layer details: it reveals the state of the transceiver, clocking circuits, framing logic, and hardware error counters. This command is indispensable when troubleshooting physical layer issues like cable faults, clocking mismatches, or interface errors that persist despite seemingly correct configuration.
For example, if an interface shows 'up/up' but experiences excessive CRC errors or input errors, 'show controllers' can pinpoint whether the problem lies in the cable, the transceiver, or the interface hardware. It is also used to verify serial interface clocking (DTE/DCE), T1/E1 line coding, and the status of internal hardware components. The command outputs buffered data that can be extensive; on some platforms, it may require multiple iterations to capture all information.
It does not affect the running configuration, but it does require privileged EXEC mode (enable). In the broader troubleshooting workflow, 'show controllers' is typically used after initial checks with 'show interfaces' and 'show ip interface' to isolate physical layer anomalies. It is particularly valuable for serial, T1/E1, and fiber interfaces, where hardware-specific parameters like signal quality, clock recovery, and alarm conditions are critical.
Understanding the output requires familiarity with the specific interface type; for instance, on a serial interface, you look for 'DCE' or 'DTE' status and clock rate, while on a FastEthernet interface, you examine the PHY status and auto-negotiation state. The command also reveals the MAC address of the interface and the hardware revision. In modern IOS-XE platforms, the output may be more structured, but the core purpose remains: to expose the hardware state that higher-level commands abstract away.
For CCNA and CCNP candidates, mastering 'show controllers' is essential for diagnosing real-world network issues that cannot be resolved by configuration alone. It is the go-to command when you suspect a faulty cable, a mismatched transceiver, or a failing interface port. By correlating its output with other show commands, you can systematically eliminate hardware problems from your troubleshooting checklist.
show controllersWhen to Use This Command
- Troubleshooting a serial interface that is up but experiencing CRC errors or packet drops.
- Verifying DCE/DTE cable termination and clock rate settings on a serial link.
- Checking for buffer overruns or framing errors on a T1/E1 controller.
- Diagnosing why a FastEthernet interface is not coming up despite a good cable.
Parameters
| Parameter | Syntax | Description |
|---|---|---|
| interface-type interface-number | e.g., serial 0/0/0, gigabitethernet 0/0/1 | Specifies the interface to display controller information for. If omitted, the command shows a summary for all interfaces. Common mistake: using the wrong interface type or number, which results in no output or an error. Valid values depend on the platform and module. |
Command Examples
Serial Interface Controller Status
show controllers serial 0/0/0Interface Serial0/0/0 Hardware is PowerQUICC MPC860 DTE V.35 cable detected cable type : V.35 DTE cable, received clockrate 2000000 idb at 0x80A4B6C0, driver data structure at 0x80A4B7E0 icb at 0x80A4B8A0 HD unit 0, idb = 0x80A4B6C0, ds = 0x80A4B7E0, regs = 0x80A4B8A0 HD unit 0, idle = 0, rxbusy = 0, txbusy = 0 buffer size 1524 cpb = 0x20, eda = 0x4000, cda = 0x4000 RX ring entries: 0: 0x4000: status 0x0000, size 0, data 0x0 1: 0x4008: status 0x0000, size 0, data 0x0 2: 0x4010: status 0x0000, size 0, data 0x0 3: 0x4018: status 0x0000, size 0, data 0x0 4: 0x4020: status 0x0000, size 0, data 0x0 5: 0x4028: status 0x0000, size 0, data 0x0 6: 0x4030: status 0x0000, size 0, data 0x0 7: 0x4038: status 0x0000, size 0, data 0x0 TX ring entries: 0: 0x4040: status 0x0000, size 0, data 0x0 1: 0x4048: status 0x0000, size 0, data 0x0 2: 0x4050: status 0x0000, size 0, data 0x0 3: 0x4058: status 0x0000, size 0, data 0x0 4: 0x4060: status 0x0000, size 0, data 0x0 5: 0x4068: status 0x0000, size 0, data 0x0 6: 0x4070: status 0x0000, size 0, data 0x0 7: 0x4078: status 0x0000, size 0, data 0x0 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 0 packets output, 0 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions DCD=up DSR=up DTR=up RTS=up CTS=up
Line 1: Interface identifier. Line 2: Hardware type (PowerQUICC MPC860). Line 3: Cable type detected (DTE V.35). Line 4: Received clock rate from DCE. Lines 6-8: Internal data structures. Lines 10-12: HD unit status (idle, rxbusy, txbusy). Lines 14-23: RX ring entries show buffer descriptors; status 0x0000 means no errors. Lines 25-34: TX ring entries. Lines 36-40: Error counters – all zeros indicate no errors. Lines 42-46: Serial line signals (DCD, DSR, DTR, RTS, CTS) – all 'up' is good.
T1 Controller Status
show controllers t1 0/0/0T1 0/0/0 is up.
Hardware is DSX1
Receiver has no alarms.
Framing is ESF, Line Code is B8ZS, Clock Source is Line.
Data in current interval (0 seconds elapsed):
0 Line Code Violations, 0 Path Code Violations
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
Total Data (last 24 hours):
0 Line Code Violations, 0 Path Code Violations,
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins,
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail SecsLine 1: T1 controller status (up). Line 2: Hardware type. Line 3: Alarm status – 'no alarms' is good. Line 4: Framing (ESF), line code (B8ZS), clock source (Line). Lines 5-8: Current interval error counters – all zeros indicate clean link. Lines 9-12: Last 24-hour totals – zeros are ideal. Key metrics: Line Code Violations (LCV) indicate bipolar violations; Path Code Violations (PCV) indicate framing errors; Slip Secs indicate clock slips; Fr Loss Secs indicate loss of frame; Unavail Secs indicate link unavailable.
Understanding the Output
The 'show controllers' command provides low-level hardware diagnostics for physical interfaces. For serial interfaces, the output shows cable type (DTE/DCE), clock rate, ring buffer descriptors, and error counters. Key fields: 'cable type' indicates whether the interface is DTE (expects clock from DCE) or DCE (provides clock); 'received clockrate' shows the clock speed from the DCE; 'input errors' includes CRC, frame, overrun, ignored, and abort errors – any non-zero value indicates physical layer issues; 'carrier transitions' counts link flaps.
For T1 controllers, look for 'Receiver has no alarms' (good) or alarms like 'Loss of Signal' (LOS), 'Alarm Indication Signal' (AIS), or 'Yellow Alarm' (RAI). Error counters like Line Code Violations and Path Code Violations should be zero; increasing values indicate line impairments. The output also shows framing (ESF or SF) and line code (B8ZS or AMI) – mismatches cause errors.
In production, use this command to isolate cabling, clocking, or line card problems before escalating to the service provider.
Configuration Scenarios
Verify Serial Interface Clocking and DTE/DCE Status
A branch router is connected to an ISP via a serial link, but the interface is up/down. The engineer needs to verify that the clocking is correctly configured on the DCE side and that the DTE side is receiving clock.
Topology
R1(Serial0/0/0)---WAN---(Serial0/0/0)ISP_RouterSteps
- 1.Step 1: Enter privileged EXEC mode: enable
- 2.Step 2: On the ISP router (DCE), configure clock rate: configure terminal, interface serial 0/0/0, clock rate 64000, no shutdown
- 3.Step 3: On the branch router (DTE), no clock rate is needed; ensure the interface is not shutdown: interface serial 0/0/0, no shutdown
- 4.Step 4: Verify DCE/DTE status: show controllers serial 0/0/0
! ISP Router (DCE) interface Serial0/0/0 clock rate 64000 no shutdown ! Branch Router (DTE) interface Serial0/0/0 no shutdown
Verify: On the DCE router, 'show controllers serial 0/0/0' output should include 'DCE V.35' or similar, and 'clock rate 64000'. On the DTE router, output should show 'DTE V.35' and 'no clock rate'.
Watch out: Forgetting to set clock rate on the DCE side will cause the DTE interface to be up/down. Also, ensure the cable is properly connected and the correct cable type (DCE/DTE) is used.
Diagnose CRC Errors on a FastEthernet Interface
A FastEthernet interface is up/up but experiencing high CRC errors, causing packet loss. The engineer suspects a faulty cable or transceiver.
Topology
PC1---(Fa0/0)Switch1---(Fa0/1)Router1Steps
- 1.Step 1: Enter privileged EXEC mode: enable
- 2.Step 2: Check interface errors: show interfaces fastEthernet 0/1
- 3.Step 3: If CRC errors are high, examine controller details: show controllers fastEthernet 0/1
- 4.Step 4: Look for 'PHY status' and 'link status' fields; a healthy interface shows 'Link OK' and no alarms.
- 5.Step 5: Replace the cable or transceiver if the controller output indicates 'cable fault' or 'signal degrade'.
! No configuration change needed; this is a diagnostic scenario. ! Example output snippet: ! show controllers fastEthernet 0/1 ! PHY status: Link OK ! Transceiver: internal ! No alarms detected
Verify: After replacing the cable, run 'show controllers fastEthernet 0/1' again; the output should show 'Link OK' and no error counters incrementing. Also verify with 'show interfaces fastEthernet 0/1' that CRC errors stop increasing.
Watch out: CRC errors can also be caused by duplex mismatch. Always check duplex settings on both ends before assuming a hardware fault. 'show controllers' does not show duplex; use 'show interfaces' for that.
Troubleshooting with This Command
When troubleshooting physical layer issues, 'show controllers' is your window into the hardware. A healthy output typically shows no alarms, no errors, and proper clocking. For serial interfaces, look for 'DCE' or 'DTE' status and the configured clock rate.
For Ethernet interfaces, check the PHY status: 'Link OK' indicates a good physical connection, while 'Link Down' or 'Cable Fault' points to a cabling issue. Focus on fields like 'CRC errors', 'framing errors', 'aborts', and 'ignored packets' – these indicate layer 1 problems. For T1/E1 controllers, examine 'Line Code', 'Framing', and 'Alarm Indication Signal (AIS)' or 'Remote Alarm Indication (RAI)'.
A step-by-step diagnostic flow: 1) Identify the problematic interface using 'show interfaces' or 'show ip interface brief'. 2) Run 'show controllers <interface>' to get hardware details. 3) If the interface is down, check for 'cable fault' or 'no signal'. 4) If up but with errors, look at error counters and compare with baseline. 5) For serial interfaces, verify clocking: DCE must have 'clock rate' configured; DTE must show 'clock rate' as received. 6) Correlate with 'show logging' for hardware alerts. 7) Use 'debug serial interface' or 'debug ethernet-interface' for real-time analysis, but be cautious on production networks. Common symptoms: 'input errors' with high CRC often mean cable issues; 'output errors' may indicate duplex mismatch or faulty transceiver. 'show controllers' can also reveal the MAC address and hardware revision, useful for inventory.
In conjunction with 'show interface', you can differentiate between hardware and software issues. For example, if 'show interface' shows 'input errors' but 'show controllers' shows no PHY alarms, the problem might be at layer 2 (e.g., encapsulation mismatch). Always check the 'last input' and 'last output' fields in 'show interface' to see if the interface is actively processing traffic.
'show controllers' is particularly powerful for WAN interfaces like T1/E1, where you can see 'Loss of Signal (LOS)', 'Alarm Indication Signal (AIS)', and 'Yellow Alarm'. These alarms help isolate whether the problem is local, remote, or in the carrier network. Remember that 'show controllers' output can be verbose; use the interface-specific form to focus on a single interface.
On some platforms, you may need to use 'show controllers <interface> | begin <keyword>' to find relevant sections. In summary, 'show controllers' is a critical tool for any network engineer dealing with physical layer problems, and mastering its output is essential for efficient troubleshooting.
CCNA Exam Tips
CCNA exam tip 1: 'show controllers' is used to verify DTE/DCE cable type and clock rate on serial interfaces; remember that DCE provides clock, DTE receives it.
CCNA exam tip 2: For T1/E1 controllers, know that 'show controllers t1' displays framing (ESF/SF) and line code (B8ZS/AMI); mismatches cause errors.
CCNA exam tip 3: The exam may ask which command to use to check for CRC errors on a serial link – answer is 'show controllers serial'.
CCNA exam tip 4: 'show controllers' is a Layer 1 troubleshooting command; do not confuse with 'show interfaces' which shows Layer 2/3 status.
Common Mistakes
Mistake 1: Using 'show controllers' on Ethernet interfaces expecting detailed output – most Ethernet controllers show minimal info; use 'show interfaces' instead.
Mistake 2: Misinterpreting 'cable type : V.35 DTE cable' as the interface being DCE – DTE means it expects clock from the remote DCE.
Mistake 3: Ignoring 'carrier transitions' counter – a high number indicates frequent link flaps, often due to loose cables or faulty hardware.
show controllers vs show interfaces
The 'show controllers' and 'show interfaces' commands are both used for interface diagnostics, but they focus on different layers. 'show controllers' drills into physical hardware details (e.g., clocking, cable type, framing), while 'show interfaces' provides Layer 2 statistics and operational status. They are often confused because both display interface-related information, but their output and use cases differ significantly.
| Aspect | show controllers | show interfaces |
|---|---|---|
| Scope | Per-interface hardware controller | All interfaces or specific interface |
| Layer Focus | Primarily Layer 1 (physical) | Layers 1 and 2 (statistics + protocol) |
| Error Details | Hardware-specific: framing, clock, cable type | Counters: CRC, runts, giants, input/output errors |
| Output Verbosity | Verbose, often per-interface detail dump | Structured, with line protocol and packet stats |
| Interface Support | Serial, T1/E1, sometimes Ethernet (platform-dependent) | All interface types universally |
| Typical Use | Physical-layer troubleshooting (e.g., clock mismatch) | General interface health and error monitoring |
Use show controllers when diagnosing physical layer issues like cable faults, clocking problems, or framing errors on serial or T1/E1 interfaces.
Use show interfaces when checking interface operational status, protocol state, and Layer 2 error counters for routine monitoring or troubleshooting.
Platform Notes
In IOS-XE (e.g., Catalyst 9000 switches), the 'show controllers' command syntax is similar but the output format may differ. For example, on a Cisco Catalyst 9300, 'show controllers gigabitethernet 1/0/1' provides detailed PHY information, including transceiver details and error counters. The command is also available in IOS-XR, but the syntax is 'show controllers <interface>' and the output is more structured, often in XML-like format.
In NX-OS, the equivalent command is 'show interface <interface> transceiver' for optical interfaces, or 'show hardware internal interface <interface>' for deeper diagnostics. For ASA firewalls, 'show controllers' is not typically used; instead, use 'show interface' or 'show inventory' for hardware details. Differences between IOS versions: In older IOS 12.x, 'show controllers serial' output includes detailed DTE/DCE status and clocking; in 15.x and 16.x, the output is similar but may include additional fields like 'Data Terminal Ready' status.
On some platforms, 'show controllers' may require the 'service internal' command to be enabled for full output. For Ethernet interfaces, newer IOS versions provide 'show controllers ethernet-controller' which gives even more granular PHY statistics. Always check the specific platform documentation, as the exact fields and formatting can vary.
For CCNA/CCNP studies, focus on the common fields across platforms: clocking, DTE/DCE, PHY status, and error counters. In lab environments, use the command frequently to become familiar with the output patterns.
Related Commands
Practice for the CCNA 200-301
Test your knowledge with practice questions covering all CCNA 200-301 exam domains.
Practice CCNA 200-301 Questions