Core Cisco IOS Verification and Troubleshooting Commands for CCNA 200-301 v2.0

CCNA command output is easier to interpret when each command is tied to a job. Memorizing a long list of show commands is less useful than knowing which one exposes the state you need to verify.

A good habit is simple: observe first, narrow the problem, then change configuration. Cisco's published CCNA v2.0 blueprint repeatedly asks candidates to configure, troubleshoot, diagnose, interpret, validate, and use operational evidence, so being able to read state is as important as remembering syntax.

Platform note: Cisco IOS and IOS XE syntax and output can vary by device family and software release. Use context-sensitive help (?) and the documentation for the platform you are working on when a command differs from an example.

Troubleshooting workflow: ask one question at a time

When traffic fails, start at the lowest layer that could explain the symptom and move upward only when the evidence supports it.

Is the interface physically and logically up?
Is the port in the expected virtual local area network (VLAN) or trunk state?
Is the local IP addressing correct?
Does the routing table contain the expected path?
Are protocol neighbors established?
Are access control lists (ACLs), Network Address Translation (NAT), or another policy changing the traffic?
What do logs and path tests reveal?

This prevents a common troubleshooting mistake: changing routing because a host cannot communicate when the real problem is an access port in the wrong VLAN.

Command map: what are you trying to learn?

Question	Useful command	What to inspect
Is an IPv4 interface up and addressed?	`show ip interface brief`	Interface, IPv4 address, status, line protocol
Is an IPv6 interface up and addressed?	`show ipv6 interface brief`	Interface state, link-local address, global addresses
Are counters or errors pointing to a link problem?	`show interfaces`	Line state, speed, duplex, errors, drops, counters
How is a switchport operating?	`show interfaces switchport`	Administrative and operational mode, access VLAN, trunk details
Does the VLAN exist and which access ports belong to it?	`show vlan brief`	VLAN ID, name, status, listed ports
Which links are trunks and which VLANs can cross them?	`show interfaces trunk`	Trunk state, native VLAN, allowed and forwarding VLANs
Did an EtherChannel form correctly?	`show etherchannel summary`	Port-channel state, protocol, member flags
Which switch is root and what are the port roles?	`show spanning-tree`	Root bridge, root port, designated or alternate roles, forwarding state
What Cisco device is directly connected?	`show cdp neighbors`	Device ID, local interface, platform, remote port
What multivendor neighbor is directly connected?	`show lldp neighbors`	Device ID, local port, capabilities, remote port
What IPv4 route will be used?	`show ip route`	Prefix, source, administrative distance, metric, next hop, exit interface
What IPv6 route will be used?	`show ipv6 route`	Prefix, route source, next hop, exit interface
Did an Open Shortest Path First version 2 (OSPFv2) adjacency form?	`show ip ospf neighbor`	Neighbor ID, state, dead time, address, interface
Did an Open Shortest Path First version 3 (OSPFv3) adjacency form?	`show ospfv3 neighbor`	Neighbor ID, state, interface, process or address-family context
Does the Dynamic Host Configuration Protocol (DHCP) server have usable addresses?	`show ip dhcp pool`	Pool range, utilization, leased and excluded addresses
Which DHCP leases exist?	`show ip dhcp binding`	Assigned address, client identifier or hardware address, lease information
Which Hot Standby Router Protocol (HSRP) router is active?	`show standby brief`	Group, priority, state, active and standby peers, virtual IP
Which Virtual Router Redundancy Protocol (VRRP) router is master?	`show vrrp brief`	Group, priority, state, master, virtual address
What IP ACL entries exist?	`show ip access-lists`	Sequence, permit or deny, match criteria, counters when available
Is NAT translating traffic?	`show ip nat translations`	Inside local/global and outside local/global mappings
What is the current NAT state?	`show ip nat statistics`	Translation counts, interfaces, pool or mapping information
What did the device report?	`show logging`	Recent messages, severity, timestamps, interface or protocol events

Interfaces and addressing: prove the local link first

show ip interface brief is a fast IPv4 starting point. It summarizes interface addressing and separates interface status from line protocol state.

Those two columns matter. An interface can be administratively down, physically down, or physically up while the line protocol is down. Do not treat all three as the same failure.

For IPv6, show ipv6 interface brief provides a compact view of IPv6-enabled interfaces and their addresses.

Use show interfaces when the brief view is not enough. It can expose details such as:

Physical and line-protocol state
Speed and duplex
Input and output errors
Drops and queue behavior
Traffic counters

An interface that is up/up is only the beginning. It proves the link has reached a useful operational state, not that the VLAN, IP address, route, or policy is correct.

On a Layer 2 switchport, show interfaces switchport helps answer a different question: how is this port operating as a switchport? Check the operational mode, access VLAN, trunking state, and related switchport characteristics instead of assuming the configuration intent matches the live state.

Virtual local area networks (VLANs) and trunks: separate membership from transport

Use show vlan brief to confirm that a VLAN exists and to see the access ports associated with VLANs in the brief table.

Use show interfaces trunk for trunk questions. A useful read order is:

Is the interface actually trunking?
What is the native VLAN?
Which VLANs are allowed?
Which allowed VLANs are active and forwarding?

That sequence matters because a VLAN can exist locally and still fail to cross a trunk. If VLAN 30 works on one switch but not across the uplink, checking the VLAN database alone is incomplete.

show interfaces switchport is useful when one specific port is suspicious. It helps distinguish configured mode from operational mode and can expose the VLAN information tied to that port.

Symptom clue: If several VLANs cross a trunk successfully and only one VLAN fails, investigate that VLAN's existence, allowed list, and spanning-tree state before blaming the physical link.

Link Aggregation Control Protocol (LACP) EtherChannel: check the bundle and the members

show etherchannel summary gives a compact view of port channels, negotiation protocol, and member-port state.

Read the legend before interpreting the flags. The goal is to determine whether the logical port channel is usable and whether the expected physical interfaces are actually bundled.

If one member is suspended or acting as a stand-alone link, compare the member configurations. Common causes include mismatched Layer 2 mode, VLAN or trunk settings, channel-group settings, speed, or other parameters that prevent the interfaces from joining the same logical bundle.

Do not stop after confirming that the physical members are up. EtherChannel troubleshooting is about whether they formed one logical link as intended.

Spanning Tree Protocol (STP): root, role, and state

show spanning-tree helps answer three exam-level questions:

Which switch is the root bridge for the VLAN or instance?
Which local port is the best path toward the root?
Which redundant ports are forwarding or intentionally not forwarding?

A non-forwarding redundant port is not automatically broken. It may be doing exactly what spanning tree requires to prevent a Layer 2 loop.

For Rapid Per-VLAN Spanning Tree Plus (Rapid PVST+) troubleshooting, connect the output to the topology. If the wrong switch became root, traffic may take an inefficient path. If an access port is unexpectedly participating in topology changes, examine whether edge-port features and protections match the design.

The important skill is not merely recognizing show spanning-tree. It is reading the output against the expected topology.

Cisco Discovery Protocol (CDP) and Link Layer Discovery Protocol (LLDP): verify what is actually connected

show cdp neighbors discovers directly connected Cisco devices when Cisco Discovery Protocol (CDP) is enabled. It can quickly reveal:

The neighboring device
Your local interface
The neighbor's platform or capabilities
The remote port

show lldp neighbors serves a similar purpose with Link Layer Discovery Protocol (LLDP), which is useful in multivendor environments.

These commands are excellent for catching a topology assumption that is simply wrong. If a cable was moved, documentation is stale, or you are looking at the wrong switchport, neighbor discovery can save a long detour through higher-layer troubleshooting.

Use the detailed form when you need more neighbor information, such as management addressing or additional advertised attributes:

show cdp neighbors detail
show lldp neighbors detail

IPv4 and IPv6 routing: follow the most specific path

show ip route displays the IPv4 routing table. For a destination problem, do not just scan for a familiar network. Identify the route that actually wins for the destination address.

Check:

Prefix and mask
Route source
Administrative distance and metric when shown
Next hop
Exit interface
Default route when no more-specific route exists

show ipv6 route performs the same core job for the IPv6 routing table.

For both IPv4 and IPv6, remember that forwarding follows the longest matching prefix. A default route can exist and still lose to a more-specific route. Likewise, the presence of a route does not prove the next hop is reachable or the return path is correct.

When a static route is suspected, compare the configured next hop or exit interface with the live topology. When dynamic routing is involved, verify the neighbor relationship as well as the learned route.

Open Shortest Path First (OSPF) neighbors: adjacency before learned routes

For OSPFv2, show ip ospf neighbor shows neighbor information such as the neighbor ID, state, dead time, address, and interface.

A healthy adjacency often reaches FULL, but the expected state depends on the network type and the relationship being examined. For example, broadcast networks use designated router (DR) and backup designated router (BDR) behavior, so the state text carries topology information as well as health information.

If the expected neighbor is missing entirely, investigate the local interface and basic OSPF compatibility before troubleshooting route selection. If the neighbor is stuck in an intermediate state, the state itself becomes evidence.

For OSPFv3 on current IOS XE, show ospfv3 neighbor is a useful verification command. Some Cisco IOS material and older syntax also use show ipv6 ospf neighbor. Know that both forms exist so a syntax difference does not become a conceptual problem.

Useful questions include:

Is the expected neighbor present?
What state is the adjacency in?
Which interface formed the adjacency?
Does that interface belong to the expected area or process?
If the adjacency is healthy, did the expected route enter the routing table?

Dynamic Host Configuration Protocol (DHCP) and first-hop redundancy: verify service state

For an IOS DHCP server, show ip dhcp pool tells you whether the configured pool has addresses available and how the pool is being used. show ip dhcp binding shows addresses that have already been leased. If clients are failing to obtain addresses, these two views help distinguish pool exhaustion or missing bindings from a problem elsewhere in the DHCP exchange.

show ip dhcp conflict is also useful when IOS has detected addresses that should not be handed out. For relay problems, combine DHCP state with interface addressing, routing, and the relay configuration rather than assuming the server is the only possible fault.

The v2.0 blueprint also expects you to interpret First Hop Redundancy Protocol (FHRP) status. For Hot Standby Router Protocol (HSRP), show standby brief summarizes the group, priority, state, active router, standby router, and virtual IP. For Virtual Router Redundancy Protocol (VRRP), show vrrp brief provides the corresponding operational view.

When the wrong device owns the virtual gateway role, compare priority and preemption behavior with the intended design. When neither peer appears healthy, verify the participating interfaces and Layer 3 reachability before treating the redundancy protocol itself as the root cause.

Access control lists (ACLs) and Network Address Translation (NAT): inspect policy after connectivity

An Access Control List (ACL) can make a healthy path look broken. show ip access-lists displays current IP ACL entries so you can inspect sequence, matching criteria, and permit or deny logic.

Remember that ACL order matters. The first matching entry determines the result, and an implicit deny follows the configured entries. Also verify where the ACL is applied and in which direction. A correct ACL attached to the wrong interface or direction still produces the wrong behavior.

For Network Address Translation (NAT) and Port Address Translation (PAT):

show ip nat translations displays active translation mappings.
show ip nat statistics displays NAT state and statistics.

When troubleshooting, compare the inside local address with the inside global address and make sure the observed translation matches the traffic you are testing. If no expected translation appears, the problem may be traffic matching, interface roles, the NAT rule, or a path problem that prevents traffic from reaching the translation point.

Logs, ping, traceroute, and packet evidence

show logging exposes system logging status and buffered messages. Logs can reveal interface transitions, protocol events, configuration changes, security actions, and other clues that are easy to miss in a static configuration.

Do not read logs as isolated error strings. Match the timestamp and event to what the user or network was doing.

Use ping to test reachability, but interpret the result carefully. A failed ping does not identify the failing layer by itself. A successful ping to one target can still help narrow the fault domain.

Cisco IOS also supports extended ping options that let you control parameters such as the source. That is valuable when a router has several interfaces and you need to test from the same source address that production traffic should use.

Use traceroute when the path matters. It can show how far traffic travels before replies stop, but missing responses do not always prove that the forwarding path itself failed because intermediate devices may filter or deprioritize the control messages used by the test.

The v2.0 blueprint also calls for interpreting packet-capture output. A capture can answer questions that device state alone cannot, such as whether Address Resolution Protocol (ARP), Neighbor Discovery, DHCP, Domain Name System (DNS), Transmission Control Protocol (TCP) handshakes, or other exchanges are actually occurring on the wire.

A practical verification sequence

Suppose a user in VLAN 20 cannot reach a server in another subnet. A disciplined sequence could look like this:

Check the user's switchport state and VLAN with show interfaces switchport and show vlan brief.
If traffic must cross a trunk, verify VLAN 20 with show interfaces trunk.
Check the gateway interface or switch virtual interface state with the appropriate interface command.
Confirm the destination route with show ip route or show ipv6 route.
If OSPF should provide the route, verify the neighbor before assuming a routing-table problem.
Inspect ACLs if the route and interfaces are correct.
Inspect NAT only if the traffic path actually crosses a translation boundary.
Use ping, traceroute, logs, or packet evidence to narrow what remains.

Notice what is missing: random configuration changes. Each step should either confirm the current theory or tell you where to look next.

Memory rule: interface, Layer 2, address, route, neighbor, policy, path. You do not have to use every step every time, but the order keeps troubleshooting grounded in evidence.