4.1Diagnostic tools (debug, ping, traceroute, SNMP, syslog)

Network assurance is not the art of investigating after a break; it is the art of continuously measuring the normal state so that, when something goes wrong, you can pin down the layer and location fastest. What this ENCOR area really tests is not the names of tools but the order in which you reach for them. Firing debug ip packet on a production core router can saturate the CPU and create a second outage. Start with zero-cost show commands and the syslog you are already collecting, then isolate reachability with ping/traceroute, and only then move to a tightly scoped debug. That order is the backbone of the right answer both in the field and on the exam.

4.1.1debug and conditional debug

• debug prints a process's internal handling in real time, which forces process switching and spikes CPU utilization. Broad debugs such as debug ip packet are effectively forbidden on production devices; the standard practice is to narrow the hypothesis first with zero-load show commands such as show ip ospf neighbor, show interfaces, and show logging. Check what is enabled with show debugging and stop it definitively with undebug all (= no debug all).
• Conditional debug: setting a condition first--for example debug condition interface GigabitEthernet0/1--and then enabling debug restricts output to what matches that interface (or filters such as debug condition ip), which dramatically reduces both CPU load and output volume. Review conditions with show debug condition and clear them with no debug condition all rather than undebug all (a leftover condition silently narrows the next debug).
• By default debug output goes only to the console. Viewing it over an SSH/Telnet vty requires terminal monitor, and if you want to re-read it later it is safer to send it to the buffer with something like logging buffered 8192 debugging and collect it with show logging (console output can slow the whole device when the console is slow). To correlate timestamps, first set service timestamps debug datetime msec and ensure NTP synchronization.

4.1.2Isolating reachability with ping and traceroute

• A plain ping sources from the outgoing interface address, so it cannot reproduce the case where "it works from the router but not from users." An extended ping such as ping 10.20.0.10 source Loopback0 uses the same source as real traffic, exposing asymmetry in the return route or in ACLs. Combining size and df-bit--ping 10.20.0.10 size 1500 df-bit--is effective for path MTU discovery: the smallest failing size reveals the bottleneck MTU.
• traceroute sends probes with TTL incremented by one and maps the path from the ICMP time-exceeded messages each hop returns (IOS uses UDP probes by default; the Windows tracert uses ICMP echo). The point of the isolation is from which hop onward the responses change, and you should align the source as well: traceroute 10.20.0.10 source Loopback0.
• A * * * at an intermediate hop does not necessarily mean a broken path. Many devices rate-limit ICMP or suppress time-exceeded by policy, so even with silent middle hops, if the final hop replies then forwarding itself is succeeding. Conversely, if the trace never reaches the final line and everything past a given hop is silent, suspect beyond that hop. Codes such as !H (host unreachable) and !A (administratively prohibited, i.e. an ACL drop) are strong hints that name the cause directly.

4.1.3SNMP and syslog (designing severity)

• SNMP has the management station (NMS) poll values per OID (get/getnext/getbulk over UDP 161), while the device notifies with a trap (fire and forget) or an inform (acknowledged and retransmitted) over UDP 162. v2c carries the community string in clear text, so operational deployments choose v3 (authPriv, i.e. authentication plus encryption). The judgment point: when a notification must not be lost, choose an inform rather than a trap.
• For syslog, severity 0 is the most severe: 0 emergencies / 1 alerts / 2 critical / 3 errors / 4 warnings / 5 notifications / 6 informational / 7 debugging. logging trap 4 sends only messages at level 4 or below (numerically equal or smaller, i.e. more severe) to the server, so %LINK-3-UPDOWN (level 3) is sent but debug output (level 7) is not. That asymmetry is a classic pitfall both in the field and on the exam.
• Design destinations and granularity independently: logging host 10.50.0.9 (destination), logging trap <level> (to the server), logging buffered <size> <level> (local buffer), and logging console <level> (console). Leaving logging console debugging in place lets console writes choke the device, so production practice is to restrict it to about logging console critical and take the detail through the buffer and the server. show logging shows the current destinations and levels.

On a head-office distribution switch, the OSPF adjacency with a branch WAN router flaps just a few times a day, each time causing tens of seconds of outage. CPU utilization sits at 55-65% even when healthy, so enabling debug ip ospf adj unconditionally would stream output for all twelve adjacencies and push the CPU higher--running it as-is is not an option. Starting with show logging, you see sporadic %OSPF-5-ADJCHG and, just before each one, not %LINK-3-UPDOWN but %OSPF-4-ERRRCV, which points to an OSPF packet reception problem rather than a physical failure. The correct move here is to restrict the scope to the single interface carrying the troubled adjacency: configure debug condition interface GigabitEthernet0/1, then enable debug ip ospf adj, and send the output to logging buffered 16384 debugging rather than the console so you can collect it with show logging. In parallel, if ping 10.10.0.2 source Vlan10 size 1500 df-bit fails while size 1476 succeeds, you have confirmed a tunnel segment with MTU 1476 along the path, and the hypothesis that OSPF DBD exchange stalls on large packets and flaps the adjacency becomes strongly favored. By contrast, concluding "the path is broken" because intermediate traceroute hops showed * * * would be wrong: since the final hop replies, forwarding is working, and you are merely observing ICMP rate limiting on transit devices. It is also risky to finish the investigation with undebug all alone--without no debug condition all the condition persists, and the next time you enable a debug for a different fault you get the secondary confusion of "nothing is printing." More than the tools themselves, the order in which you eliminate hypotheses without raising load determines the quality of the diagnosis.

4.1.4Section summary

• Work from the lowest load upward: show/show logging -> ping/traceroute -> a scoped debug. An unconditional debug on a production device saturates the CPU and creates a second outage
• Conditional debug sets the condition first with debug condition interface ... and is cleared with no debug condition all. Extended ping reproduces real traffic with source, and size plus df-bit pinpoints path MTU
• Syslog severity runs from 0 (emergencies, most severe) to 7 (debugging, least), and logging trap N forwards only level N or below (more severe). In SNMP, a trap is unacknowledged while an inform is acknowledged, and since v2c is clear text you choose v3 (authPriv)