4.1 Diagnose network problems using such as debugs, conditional debugs, traceroute, ping, SNMP, and syslog

Good troubleshooting is not running every command you know. Good troubleshooting is proving or eliminating one layer at a time.

For ENCOR, know the classic tools: ping, traceroute, debugs, conditional debugs, SNMP, and syslog. Each tool answers a different question.

1. ping / traceroute — Is there reachability and where does path stop?
2. show ip route / arp / interface — Is L3/L2 state sane on this hop?
3. debug / conditional debug — What is the control protocol doing now?
4. syslog + SNMP history — What changed over time on this device?

Start with reachability

Use ping to test whether packets can leave and return. Use the correct source address. A router may reach a destination from one interface but not from the interface used by the broken application.

R1# ping 10.10.20.2 source 10.10.10.1 -> Type escape sequence to abort. -> Sending 5, 100-byte ICMP Echos to 10.10.20.2, timeout is 2 seconds: -> Packet sent with a source address of 10.10.10.1 -> !!!!! -> Success rate is 100 percent (5/5), round-trip min/avg/max = 2/3/5 ms

If ping fails, do not jump straight to routing protocols. Check the basic path:

show ip interface brief
show ip route 10.10.20.2
show ip cef 10.10.20.2
show arp | include 10.10.20.2
show interfaces GigabitEthernet0/0 counters errors
show access-lists

Use traceroute to find the break point

Traceroute shows the hop-by-hop path, or at least the devices willing to reply to TTL-expired probes.

R1# traceroute 10.10.20.2 source 10.10.10.1
Type escape sequence to abort.
Tracing the route to 10.10.20.2
1 10.10.12.2 4 msec 4 msec 5 msec
2 10.10.23.3 8 msec 7 msec 8 msec
3 10.10.20.2 10 msec 9 msec 9 msec

If traceroute stops at hop 2, that does not automatically mean hop 2 is broken. It may mean hop 3 has no return route, a firewall is filtering replies, or Control Plane Policing is limiting responses. Treat traceroute as a clue, not a verdict.

Use debug carefully

Debugs show live device behavior. That makes them useful and dangerous. Broad packet debugs on a busy production router can hurt the box.

Safe habits:

terminal monitor
show debugging
no debug all

Prefer filters. If your platform supports conditional debugging, constrain the scope.

R1# debug condition interface GigabitEthernet0/0
Condition 1 set
R1# debug ip packet 101 detail
R1# show debug condition
Condition 1: interface Gi0/0 (Enabled)
R1# clear debug condition all
R1# no debug all

An ACL filter is also common for short tests:

ip access-list extended DEBUG-PC1-PC2 -> permit ip host 10.10.10.10 host 10.10.30.10 -> permit ip host 10.10.30.10 host 10.10.10.10 -> ! -> debug ip packet DEBUG-PC1-PC2 detail

Run one test, capture the evidence, then stop the debug.

debug ip packet is not a complete packet-capture tool. On some platforms it may not show all CEF-forwarded or hardware-switched traffic, and a broad packet debug can still hurt the control plane. If you need packet contents, use SPAN, RSPAN, ERSPAN, an embedded capture feature, or a platform-supported packet trace. If you need counters or trends, use interface counters, SNMP, flow telemetry, or logs instead of forcing everything through debug.

Choose evidence based on the question:

Make syslog useful before you need it

Syslog is your event timeline. A timeline without good timestamps and source information is weak evidence.

conf t
service timestamps log datetime msec localtime show-timezone
logging source-interface Loopback0
logging host 10.10.10.50
logging trap informational
logging buffered 100000 warnings
end

Verify:

show logging
show running-config | section logging

Remember the severity levels:

Use SNMP for monitored state

SNMP is how a monitoring system polls device state and counters. It is not a one-time packet inspection tool.

SNMPv2c is simple but weak because the community string is a shared secret. For real networks, prefer SNMPv3.

conf t
snmp-server group NMS v3 priv
snmp-server user nms-user NMS v3 auth sha AUTH_PASSWORD priv aes 128 PRIV_PASSWORD
snmp-server location CCNP-LAB
snmp-server contact [email protected]
snmp-server host 10.10.10.50 version 3 priv nms-user
end

Verify:

show snmp user
show snmp group
show snmp host

SNMP is good for interface counters, CPU, memory, device status, and inventory. It is not good for short-lived events that happen between polling intervals.

Lab: Find the broken hop

Topology

PC1 · 10.10.10.10/24 -> R1 · 10.10.12.0/30 link -> R2 · 10.10.23.0/30 link -> R3 -> PC2 · 10.10.30.10/24

Goal

PC1 cannot reach PC2. Prove where the failure is and what kind of evidence each tool gives you.

Steps

1. From R1, ping PC2 using the PC1-facing source.

R1# ping 10.10.30.10 source 10.10.10.1

1. Trace the path from the same source.

R1# traceroute 10.10.30.10 source 10.10.10.1

1. At the last successful hop, check forwarding and interface health.

show ip route 10.10.30.10
show ip cef 10.10.30.10
show interfaces counters errors
show logging | include LINEPROTO|LINK|OSPF|EIGRP|BGP|ACL|DROP

1. If the route exists but traffic still fails, run a narrow debug during a short test window.

ip access-list extended DEBUG-PC1-PC2 -> permit ip host 10.10.10.10 host 10.10.30.10 -> permit ip host 10.10.30.10 host 10.10.10.10 -> ! -> debug ip packet DEBUG-PC1-PC2 detail -> ! run one ping -> no debug all

Expected lesson

• Ping tells you whether a path works.
• Traceroute gives you the likely location of the problem.
• Syslog tells you what changed.
• SNMP shows monitored state and counters over time.
• Debug shows live behavior, but must be filtered.

Exam takeaways

• Always source ping and traceroute from the relevant interface.
• Debugs are live and can be disruptive. Filter them.
• Conditional debugs reduce blast radius.
• Syslog is event history; SNMP is polled state and counters.
• A failed traceroute hop is not always the broken hop. Return path and filtering matter.