Exam Objective 2.4: Troubleshoot basic Layer 2/Layer 3 connectivity and device operations using show commands (including show logs), ping, extended ping, trace route, and packet capture output.
This objective is less about a new concept and more about mastering the core diagnostic toolkit every network engineer reaches for first. By this point in the exam blueprint you already know what can go wrong at Layer 1 (cabling), Layer 2 (VLANs, trunks, EtherChannel), and Layer 3 (IP addressing). This objective tests whether you know exactly which command surfaces which piece of evidence, and how to read that output correctly under exam pressure.
show mac address-table — displays the switch's MAC address table, mapping learned MAC addresses to the VLAN and physical interface where each was learned. Useful for confirming whether a switch has actually learned a given host's MAC address on the port/VLAN you expect, or for spotting a MAC address showing up on an unexpected port (which can indicate a topology change, a loop, or a spoofing attempt).
show interfaces — the single most information-dense Layer 1/2 command, covered extensively in objective 1.1; confirms line/protocol status, duplex/speed, and error counters.
show interfaces trunk — displays only the interfaces currently operating as trunks, along with their native VLAN, allowed VLAN list, and the VLANs actually active/forwarding on each trunk — a faster way to audit trunk configuration than reading through full running-config.
show interfaces status — a condensed, one-line-per-port summary showing port status (connected/notconnect/disabled), VLAN assignment, duplex, and speed across every interface on the switch simultaneously, ideal for a fast at-a-glance health check.
show vlan brief — confirms which VLANs exist in the VLAN database and which ports are currently assigned as access ports in each VLAN; useful for catching a port accidentally left in the wrong VLAN, or a VLAN that doesn't exist yet (tying back to the SVI troubleshooting covered in objective 2.1).
show spanning-tree — displays the current STP topology from this switch's perspective, including root bridge identification, port roles (root, designated, blocking), and port states — essential for diagnosing unexpected blocking or a topology that doesn't match expectations (this ties forward to objective 2.5).
show etherchannel summary — covered under objective 2.1, confirms which physical ports are actually bundled into a port-channel and their individual bundling status flags.
show ip interface brief — the fastest way to get IP address and up/down status for every interface on a router or Layer 3 switch simultaneously; almost always the first command run when troubleshooting a Layer 3 problem.
show ip route — displays the routing table, confirming whether a route to a given destination network actually exists, which routing source installed it (connected, static, or a specific routing protocol code), and the next-hop address/exit interface that will actually be used.
show ip protocols — summarizes the routing protocol(s) configured on the device, including timers, networks being advertised, and administrative distance, useful for confirming a routing protocol is actually running and advertising the networks you expect.
show arp — displays the router's ARP cache, mapping IP addresses to MAC addresses for directly connected neighbors; a missing ARP entry for an expected neighbor often points to a Layer 2 problem preventing ARP resolution, even though the IP-layer configuration looks correct.
show ip nat translations — relevant when NAT is involved in the path (covered in more depth in Domain 4.0), confirming whether address translation is actually occurring as expected for a given flow.
The router or switch's local log buffer records system events — interface up/down transitions, configuration changes, STP topology changes, error conditions, security violations (like a BPDU Guard triggering) — timestamped and categorized by severity.
Command: show logging
Syslog severity levels (0 highest severity / most critical, to 7 lowest severity / most verbose):
0 Emergency — system is unusable
1 Alert — immediate action needed
2 Critical — critical condition
3 Error — error condition
4 Warning — warning condition
5 Notification — normal but significant condition
6 Informational — informational message only
7 Debugging — debug-level message
Why show logging matters for troubleshooting: Rather than only seeing the current state of the device (as most show commands do), the log buffer shows you the history of events leading up to a problem — exactly when an interface flapped, when a port was error-disabled and why, or when a configuration change was made — which is often the key to diagnosing an intermittent or already-resolved issue that no longer shows up in current-state output.
Related logging commands:
show logging | include [keyword] — filters log output to only lines containing a specific keyword (such as an interface name or "%LINK"), useful for quickly finding relevant entries in a large log buffer
logging buffered [size] — configures the size of the local log buffer stored in device memory
terminal monitor — when connected via Telnet/SSH (rather than the console port), this command must be enabled to see log messages generated in real time on that session, since log messages are sent to the console line by default and not automatically mirrored to VTY sessions
Exam Alert: Know that syslog severity level 0 is the most severe (Emergency) and level 7 is the least severe (Debugging) — this ascending-severity/descending-detail relationship is a frequently tested, easy-to-mix-up fact. Also remember that terminal monitor is required to see log messages on a remote (Telnet/SSH) session.
Standard ping sends a sequence of ICMP Echo Request messages to a destination and reports whether/how quickly ICMP Echo Reply messages come back, along with basic success-rate statistics.
Standard Cisco IOS ping output symbols:
! (exclamation point) — a successful reply was received
. (period) — the request timed out with no reply received
U — destination unreachable message received
N — network unreachable message received
M — could not fragment (relevant when packet size exceeds a device's MTU along the path and the "don't fragment" bit is set)
? — unknown packet type received
Interpreting mixed results: A pattern like !!!.! (four successes, one timeout) often indicates an ARP resolution delay on the very first packet rather than a persistent connectivity problem, since the first ping in a sequence sometimes times out simply waiting for ARP to resolve the destination's MAC address before the actual ICMP exchange can proceed. A pattern of all periods (.....) indicates complete unreachability, worth immediately checking against show ip route and show ip interface brief.
Standard ping (with default parameters) is often insufficient for real troubleshooting, since it always sources from the outgoing interface's own address and uses default packet size/count/timeout values. Extended ping, invoked by typing ping with no destination argument at the privileged EXEC prompt, walks through an interactive series of prompts allowing much finer control.
Extended ping options include:
Protocol — choose IP, or occasionally other supported protocols
Target IP address — the destination to test
Repeat count — how many ICMP echoes to send (default 5, can be increased for a more statistically meaningful test)
Datagram size — the size of each ping packet, useful for testing whether a specific MTU along the path is causing fragmentation/drop issues
Timeout — how long to wait for each reply before considering it a failure
Extended commands — answering yes here unlocks further options, most importantly:
Source address or interface — allows the ping to be sourced from a specific interface's IP address rather than the interface IOS would automatically choose, critical for accurately testing reachability exactly as a specific remote subnet would experience it (for example, sourcing a ping from a loopback or a specific VLAN interface rather than the nearest physical egress interface)
Set DF bit in IP header — sets the "Don't Fragment" bit, useful in combination with datagram size testing to identify the actual MTU of a path (a technique sometimes called "MTU path discovery via ping")
Exam Alert: The single most tested extended-ping capability is the ability to specify a source interface/address — this lets you accurately verify reachability from the perspective of a specific remote subnet (e.g., confirming that traffic sourced from a branch office's LAN, not just the router's nearest interface, can actually reach a destination), which a standard ping cannot replicate.
traceroute (tracert on Windows) reveals the hop-by-hop path a packet takes to a destination, and — critically — reveals exactly which hop along that path is failing or introducing significant delay, information a simple ping cannot provide since ping only reports success/failure to the final destination as a whole.
How traceroute works: It sends a series of probes with progressively increasing TTL (Time to Live) values, starting at 1. Each router along the path decrements the TTL by 1; when a router receives a packet with TTL reaching 0, it discards the packet and sends back an ICMP "Time Exceeded" message to the source, revealing that hop's identity. By incrementing the TTL by one with each round of probes, traceroute progressively reveals each hop in sequence until the final destination is reached.
Reading traceroute output:
Each line typically represents one hop, showing the hop's IP address (and hostname, if reverse DNS resolves) along with round-trip time measurements (Cisco IOS traceroute sends 3 probes per hop by default, showing three timing values)
Asterisks (*) in place of a hostname/timing value indicate no response was received for that probe — this can mean the specific hop is configured not to respond to traceroute probes (common security practice for some devices) even though traffic is still passing through it successfully, or it can genuinely indicate a routing/connectivity failure at that hop
The specific hop where responses stop entirely (all subsequent hops show only asterisks with the destination never reached) usually pinpoints where the actual path breaks down, rather than the last hop that did respond necessarily being the faulty device — the hop after the last successful reply is where an engineer should focus.
Exam Alert: Don't assume the last responding hop in a traceroute is the broken device — a hop can silently drop/ignore traceroute probes for policy reasons while still correctly forwarding all other traffic. The most reliable inference is simply the general region of the path where the failure begins, which then guides further investigation on those specific devices rather than being definitive proof of exactly which single device is at fault.
While Cisco IOS devices themselves have more limited native packet capture capability than a dedicated tool like Wireshark, the exam still expects you to be able to interpret packet capture output conceptually — recognizing what a capture reveals that ping/traceroute cannot.
What packet captures reveal that ping/traceroute cannot:
The actual contents and headers of real application traffic, not just ICMP test traffic — useful when the problem is specific to one protocol/application even though basic ICMP reachability tests pass fine
Retransmissions, duplicate ACKs, and other TCP-level symptoms indicating packet loss or out-of-order delivery along the path
Confirmation of whether traffic is actually leaving a device with the expected source address, VLAN tag, or other header field — useful for confirming whether a NAT, VLAN, or QoS marking is being applied correctly in practice, not just in configuration
One-way traffic problems — a capture taken simultaneously at both ends of a suspect path can reveal that traffic is successfully leaving the source but never arriving at the destination (or vice versa), pointing squarely at something in between silently dropping the traffic
Cisco embedded packet capture: Some Cisco IOS platforms support a built-in Embedded Packet Capture (EPC) feature, allowing a capture buffer to be configured directly on the device and later exported for analysis, without needing an external SPAN port and separate capture appliance in every scenario. Configuration and export of EPC captures is a more advanced, platform-specific process; for CCNA-level purposes, the expectation is primarily to interpret capture output conceptually and understand what evidence it provides versus what ping/traceroute alone can provide, rather than to memorize the full EPC configuration syntax.
Exam Alert: Expect conceptual questions about when a packet capture would reveal something that ping and traceroute cannot (application-layer/TCP-level symptoms, confirming actual header values in real traffic, or diagnosing a one-way traffic problem), rather than detailed EPC configuration syntax.
Confirming an interface's current status, addressing, or error counters → show interfaces / show ip interface brief
Confirming a switch has learned a MAC address on the expected port/VLAN → show mac address-table
Confirming a route to a destination exists and which path it takes → show ip route
Confirming basic end-to-end reachability → ping
Confirming reachability specifically from a particular source subnet/interface, or testing for MTU-related fragmentation issues → extended ping with source address and/or datagram size options
Identifying exactly which hop along a multi-router path is failing or introducing delay → traceroute
Reviewing the history of events (interface flaps, error-disable events, config changes) leading up to a problem, not just current state → show logging
Diagnosing an application-specific or one-way traffic problem that basic ICMP tests don't explain → packet capture
Start with show ip interface brief (Layer 3) and/or show interfaces status (Layer 2) for a fast overview of interface health across the device.
Check show logging for recent relevant events — interface flaps, error-disable triggers, configuration changes — that might explain when and why the problem started.
Confirm Layer 2 fundamentals with show mac address-table, show vlan brief, and show interfaces trunk if VLAN/trunk-related connectivity is in question.
Confirm Layer 3 fundamentals with show ip route to verify a path to the destination actually exists, and show arp to confirm the router has successfully resolved the next hop's MAC address.
Run a standard ping to the destination to establish a baseline; read the response pattern (all !, all ., or mixed) to gauge whether the problem is total or intermittent.
If standard ping results are ambiguous or you need to simulate traffic from a specific source subnet, use extended ping with the source address option (and datagram size/DF bit if MTU/fragmentation is suspected).
If the destination is unreachable or reachable only with high latency, run traceroute to identify the general region of the path where the failure or delay begins.
If ICMP-based tools all pass but the actual application still fails, or the problem appears to be one-directional, use packet capture (or Embedded Packet Capture) to inspect the real traffic directly.
Q1. An administrator runs a standard ping and sees the result !!!.! — four successful replies and one timeout, with no other pattern. What is the most likely explanation?
A. The destination is completely unreachable
B. A routing loop exists in the path
C. The single timeout is likely due to an ARP resolution delay on the first packet in the sequence
D. The destination's subnet mask is misconfigured
Answer: C. A single early timeout followed by consistent successful replies is a very common and usually benign pattern, typically caused by the first ping packet being delayed while ARP resolves the destination's MAC address before the actual ICMP exchange can proceed smoothly for the remaining packets. Complete unreachability or a routing loop would typically produce a much more consistent failure pattern rather than a single isolated timeout.
Q2. Which extended ping option allows an administrator to test reachability as it would actually be experienced from a specific remote subnet, rather than from the router's nearest outgoing interface?
A. Repeat count
B. Datagram size
C. Source address or interface
D. Set DF bit in IP header
Answer: C. The source address/interface option in extended ping allows the administrator to force the ping to be sourced from a specific interface's IP address (such as a remote VLAN interface or loopback) instead of the interface IOS would automatically select, making it possible to accurately verify reachability exactly as a specific subnet would experience it.
Q3. In Cisco IOS traceroute output, several consecutive hops show only asterisks (*) with no destination ever reached beyond that point. What is the most reasonable conclusion?
A. The last hop that successfully responded is definitely the broken device
B. The general region of the path where failures begin has been identified, though the exact device at fault requires further investigation
C. Traceroute results with asterisks always indicate a routing loop
D. The destination network does not exist
Answer: B. Asterisks indicate no response was received for a probe, which can mean either a genuine routing/connectivity failure at that hop or simply that a device is configured not to respond to traceroute probes for policy reasons while still forwarding other traffic normally. The most reliable conclusion is identifying the general region where the failure begins, which then directs further investigation, rather than assuming the last responding hop is definitively the faulty device.
Q4. Which syslog severity level represents the most critical condition?
A. Level 7 (Debugging)
B. Level 0 (Emergency)
C. Level 4 (Warning)
D. Level 6 (Informational)
Answer: B. Syslog severity levels run from 0 (Emergency, the most severe — system is unusable) to 7 (Debugging, the least severe, most verbose). Level 0 represents the most critical condition, while higher numbers represent progressively less severe, more routine or verbose messages.
Q5. An administrator connects to a router via SSH and enables debug output, but no log messages appear on the terminal session even though the console port shows them clearly. What command is needed to see log messages on the remote SSH session?
A. show logging
B. logging buffered
C. terminal monitor
D. show ip interface brief
Answer: C. By default, log and debug messages are sent to the console line only, not automatically mirrored to remote Telnet/SSH (VTY) sessions. The terminal monitor command must be entered on the remote session itself to redirect log message output to that session as well.
Q6. A network engineer suspects that a specific application is experiencing one-way traffic loss even though standard ping tests between the two endpoints succeed in both directions. What troubleshooting tool would provide the most direct evidence of this specific problem?
A. show ip route
B. show mac address-table
C. Packet capture taken simultaneously at both ends of the suspect path
D. show vlan brief
Answer: C. Since basic ICMP ping tests are already succeeding, the problem is specific to the application's traffic pattern rather than basic Layer 3 reachability. A packet capture taken simultaneously at both ends of the path can directly show whether the application's traffic is actually leaving the source but failing to arrive at the destination (or vice versa), providing direct evidence of a one-way traffic problem that ping and traceroute, being ICMP-based, cannot reveal.