CCNA Troubleshooting Scenarios: Eight Real Faults, the Commands to Find Them and the Fixes
Explore detailed CCNA troubleshooting scenarios to enhance your network problem-solving skills. Our guide covers a range of common issues, including connectivity problems, VLAN misconfigurations, DHCP server issues, and more. Gain insights into effective diagnostic techniques and solutions to prepare for your CCNA exam and tackle real-world network challenges with confidence.
Quick answer: Troubleshoot CCNA scenarios by defining the problem, working through layers, changing one thing at a time and documenting. Typical faults are a native VLAN mismatch, a VLAN missing from a trunk, OSPF timer or area mismatch, DHCP without a helper address, err-disabled ports, duplex mismatch and a missing default route.
Key takeaways
- Use one method: define, work by layers, change one thing at a time, document.
- Learn the show commands that reveal each fault, such as show interfaces trunk and show ip ospf neighbor.
- OSPF neighbours fail on timers, area, mask, passive interfaces, authentication and MTU.
- Practise by breaking a simulated lab on purpose.
What is a method that works for every scenario?
Pick one method and use it every time. For CCNA, a layered approach is easiest to explain and to apply.
- Define the problem. Who is affected, what exactly fails, and what changed recently?
- Work by layers. Bottom-up (physical, data link, network, transport) is safest when you do not know where the fault is. Top-down starts from the application when the issue looks software-related. Divide and conquer starts in the middle, for example with ping, and moves up or down depending on the result.
- Change one thing at a time and test after each change.
- Document the cause and the fix.
The CCNA 200-301 exam expects you to read show command output and find the fault, so practise with output as well as configuration. The exam blueprint is on the Cisco certifications pages.
Scenario 1: native VLAN mismatch on a trunk
Symptom: two switches are connected, most traffic works, but the console of one switch keeps printing a CDP warning and some untagged traffic ends up in the wrong VLAN.
%CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on GigabitEthernet0/1 (1), with SW2 GigabitEthernet0/1 (99).
What it means: one end of the trunk uses native VLAN 1 and the other uses 99. Untagged frames are placed in different VLANs on each side.
Check:
SW1# show interfaces trunk
SW2# show interfaces trunk! compare the "Native vlan" column
Fix: set the same native VLAN on both ends, on the trunk interface: switchport trunk native vlan 99. Best practice is to use an unused VLAN as native, not VLAN 1.
Scenario 2: VLAN missing from the trunk's allowed list
Symptom: hosts in VLAN 20 on SW1 cannot reach hosts in VLAN 20 on SW2, while VLAN 10 works across the same link.
SW1# show interfaces trunk
Port Mode Encapsulation Status Native vlan
Gi0/1 on 802.1q trunking 99
Port Vlans allowed on trunk
Gi0/1 1,10
Port Vlans allowed and active in management domain
Gi0/1 1,10
This sample output is illustrative. The "allowed" list lacks VLAN 20. Fix with switchport trunk allowed vlan add 20. Remember to use add. Without it, the command replaces the whole list and can cut other VLANs off. Also confirm VLAN 20 exists on both switches with show vlan brief.
Scenario 3: users cannot reach other VLANs (router on a stick)
Symptom: hosts can ping their own gateway but not hosts in another VLAN.
- Check the host: correct IP, mask and default gateway (
ipconfig). A gateway in the wrong subnet is a common cause. - On the router:
show ip interface brief. The physical interface must be up, and each subinterface needsencapsulation dot1Q <vlan>and an IP address. - On the switch: the port to the router must be a trunk allowing those VLANs.
show ip routeon the router should show connected routes for each VLAN subnet.
Scenario 4: OSPF neighbours will not form
Symptom: two directly connected routers show no OSPF neighbour, or the neighbour is stuck in a state such as INIT, 2-WAY or EXSTART.
R1# show ip ospf neighbor
R1# show ip ospf interface gigabitEthernet0/0
R1# show ip protocols
Common causes:
| Cause | How to see it |
|---|---|
| Hello or dead timers differ | Compare timers in show ip ospf interface on both routers |
| Different area IDs on the link | Compare the area in the same output |
| Mismatched subnet or mask | show ip interface brief, check addresses |
| Interface set passive | Listed under passive interfaces in show ip protocols |
| Authentication mismatch | Check interface and area authentication on both ends |
| MTU mismatch (often stuck in EXSTART or EXCHANGE) | Compare show interfaces MTU on both sides |
| ACL blocking OSPF (IP protocol 89) | Check ACLs on the interface |
Scenario 5: clients get 169.254.x.x addresses
Symptom: Windows clients show an address starting 169.254, which means they could not get a lease from DHCP.
- Is the DHCP server reachable? If the server is on a different subnet, the router interface facing the clients needs
ip helper-address <server-ip>. - Is the pool exhausted? Check
show ip dhcp poolandshow ip dhcp bindingon a Cisco DHCP server. - Are excluded addresses and the pool defined correctly?
- Is the client port in the right VLAN and not blocked by STP or port security?
Scenario 6: a switch port is err-disabled
Symptom: a user's port is down after plugging in a new device.
SW1# show interfaces status err-disabled
Port Name Status Reason Err-disabled Vlans
Fa0/5 err-disabled psecure-violation
Illustrative output. The cause here is a port security violation. Find out why (new MAC address, an unauthorised hub or switch), fix the cause, then recover the port with shutdown followed by no shutdown. Resetting it and walking away is not enough.
Scenario 7: slow link and a duplex mismatch
Symptom: a link comes up but throughput is very poor, and counters rise.
SW1# show interfaces fastEthernet0/3
...
120 late collision,... CRC errors
Late collisions and CRC errors on one side are classic signs of a duplex mismatch, often when one end is hard-coded and the other auto-negotiates. Set both ends the same way. With modern equipment, leaving both on auto is usually best.
Scenario 8: the default route is missing
Symptom: internal users reach each other but not the internet.
R1# show ip route
Gateway of last resort is not set
Add a default route to the ISP: ip route 0.0.0.0 0.0.0.0 <next-hop>. If you use NAT, also check show ip nat translations and that the inside and outside interfaces are marked correctly.
Commands to know by heart
show ip interface brief,show interfaces,show interfaces statusshow vlan brief,show interfaces trunk,show mac address-tableshow spanning-tree,show cdp neighbors detailshow ip route,show ip ospf neighbor,show ip protocolsshow running-config,show access-listsping,traceroute, and on Windowsipconfig /all
How to practise
Build each topology in Cisco Packet Tracer or a similar simulator, break it on purpose, then write down the symptom, the command that revealed it and the fix. Ask a friend to break it for you. That is the closest thing to the exam.
Next steps
For guided lab practice, see the CCNA 200-301 course. More interview-style practice: CCNA troubleshooting interview questions and CCNA interview questions on VLANs.
Related reading
Frequently Asked Questions
What's Your Reaction?
Like
0
Dislike
0
Love
0
Funny
0
Wow
0
Sad
0
Angry
0