3.7 Troubleshooting IP Connectivity

Troubleshooting is a heavily weighted CCNA 200-301 skill — expect simulation and scenario items that hand you symptoms and command output and ask for the root cause. A disciplined, layered method beats random guessing.

Structured Troubleshooting (Bottom-Up)

Work up the OSI stack so you never chase a Layer 3 problem caused by a Layer 1 fault.

Layer 1 (Physical)

• Cable seated? Link lights on?
• Interface up/up? (show ip interface brief)
• Speed/duplex mismatch or input/CRC errors? (show interfaces)

Layer 2 (Data Link)

• MAC learned in the switch table? (show mac address-table)
• Port in the right VLAN? (show vlan brief)
• Trunk passing the VLAN? (show interfaces trunk)
• STP not blocking the port? (show spanning-tree)
• ARP resolving? (show ip arp)

Layer 3 (Network)

• Correct IP and mask? (show ip interface brief)
• Route to the destination present? (show ip route)
• Default gateway reachable? (ping)
• ACL blocking traffic? (show access-lists)
• NAT translating? (show ip nat translations)

Essential Troubleshooting Commands

Interface Status Combinations

The two-word Status / Protocol output is a direct diagnostic clue.

Reading Ping and Traceroute Output

ping returns characters that tell you what happened:

A result like ..!!! means the first packets failed while ARP/route resolution completed, then succeeded — usually normal. All dots with U mixed in points to a missing route. traceroute shows each hop by sending packets with incrementing TTL; the hop where replies stop is where the path breaks.

Common Connectivity Problems and Fixes

Extended Ping and the Return Path

The extended ping lets you set source, size, and count — essential for testing realistic flows:

Router# ping
Protocol [ip]:
Target IP address: 10.1.1.1
Repeat count [5]: 100
Datagram size [100]: 1500
Extended commands [n]: y
Source address or interface: 192.168.10.1   ! Force a specific source

Setting the source matters because the return traffic must have a route back to that source address. A ping using the egress interface IP can succeed while a ping sourced from a LAN subnet fails — proving the remote side lacks a return route.

On the Exam: Always reason about both directions. If Router A reaches Router B but B has no return route to A's source subnet, the ping fails. Missing return routes are one of the single most common troubleshooting scenarios tested.

Duplex Mismatch: The Silent Performance Killer

A duplex mismatch happens when one side of a link is set to full duplex and the other to half (often from one end hard-coded and the other left on autonegotiation). The link comes up — show ip interface brief reads up/up — so it is easy to overlook, yet throughput collapses under load. The half-duplex side sees the full-duplex side transmitting while it is transmitting and registers collisions and late collisions, while the full-duplex side logs FCS/CRC errors and runts. The tell-tale signature in show interfaces is rising late collisions on one end and CRC errors on the other.

The fix is to make both ends match — ideally both on autonegotiation, or both hard-set identically.

ARP Failures Even When Routing Is Correct

Layer 3 reachability can be perfect and a host still cannot communicate if ARP fails to resolve the next hop's MAC. Check show ip arp: an entry showing Incomplete means the router sent ARP requests but got no reply, usually because the neighbor is down, on a different VLAN, or behind a port-security violation. Because the router cannot build the Layer 2 frame without the destination MAC, packets are dropped despite a valid route. This is why troubleshooting must descend through Layer 2 — a clean routing table is necessary but not sufficient.

Reading traceroute Carefully

traceroute increments TTL by one for each round of probes, so the device that drops a TTL-expired packet reveals each hop. Three asterisks (* * *) at a hop usually mean that router is configured not to send ICMP Time Exceeded (common on firewalls), not necessarily that the path is broken — later hops may still respond. A trace that stops responding entirely at a given hop and never recovers points to the real break just beyond that device. Combine traceroute with show ip route on the last responding hop to confirm whether that router lacks a forward route.