7 Configuration, Verification, and Troubleshooting

Work safely in the CLI

Cisco IOS and IOS XE commands and output can vary by platform and release. Use command help with ? and consult device documentation when a command is unavailable.

The prompt indicates the current command mode: > is user EXEC, # is privileged EXEC, (config)# is global configuration, and prompts such as (config-if)# indicate a subconfiguration mode. Most show, ping, and traceroute commands run from EXEC mode. Enter privileged EXEC with enable, enter global configuration with configure terminal, and return to privileged EXEC with end or Ctrl-Z.

Configuration commands generally take effect in the running configuration as they are entered. The running configuration is active, while the startup configuration is saved for use at boot. Compare them when diagnosing a change that disappeared after a reboot. Before changing a live device, record relevant configuration and status, confirm the device and interface, and consider the change’s impact. Do not save an unverified or unintended change.

A typical workflow inspects configuration, makes a change, verifies the result, and only then saves it:

Use ? to discover commands and valid arguments, and use show to inspect state before changing it. show running-config interface <interface> is supported on some devices for inspecting an individual interface. show startup-config inspects saved configuration, and show version provides software, uptime, and device details. Use abbreviations only when unambiguous; full commands are easier to read in notes and troubleshooting records. Capture relevant output and note the time, affected hosts, destination, and exact symptom.

Verify interfaces, switching, and paths

Choose verification commands that test the suspected layer, then compare the results with the intended design. A single successful test does not prove that every service or traffic type works.

• Interfaces and addressing: Use show ip interface brief, show interfaces <interface>, and show ip interface <interface>. Check the address and status, errors and drops, speed or duplex mismatches, and whether the interface is administratively disabled. show ip interface brief gives a quick interface, address, and status overview; show interfaces adds detailed counters and link information.

• Switching: Use show vlan brief, show interfaces trunk, and show mac address-table. Check the access VLAN, trunk state, allowed and native VLANs, and whether MAC addresses are learned on expected ports.

• Neighbors and address resolution: Use show cdp neighbors detail, show lldp neighbors detail, and show ip arp. Check for the expected directly connected neighbor, next-hop MAC resolution, and correct local-to-neighbor mapping.

• Routing: Use show ip route or show ipv6 route. Check for a matching destination prefix and the expected next hop or exit interface. Check for a usable default route when needed.

• Logs and protocols: Use show logging and relevant protocol-specific show commands. Look for link transitions, authentication failures, adjacency state, and other events correlated with the failure.

• Reachability and path: Use ping <address> and traceroute <address> to test whether a target responds and where the observed path stops. Test the local gateway and successive routed hops.

For a host that cannot reach a remote subnet, investigate outward from the source: test its default gateway, check the router’s interface and ARP entry, inspect the route to the destination, and then test the next hop. A failed ping is evidence, not a diagnosis: ICMP may be filtered, and some devices do not answer it even when other traffic works.

Troubleshoot from the endpoint outward

Begin by describing the failure precisely: identify affected users or devices, failed destinations or applications, when the problem began, and whether anything changed. Determine whether it is local to one endpoint, one VLAN, one path, or broadly network-wide. Follow a consistent path through the network and test at each boundary. Depending on the symptom, it can be faster to start with an IP-level test and work backward toward the physical layer; not every incident needs the same starting point.

1. Physical (Layer 1): Check power, cabling, optics, link state, and interface errors. administratively down usually indicates a disabled interface; down/down suggests no physical link or a problem at the far end. Confirm that the intended interface is connected.

2. Data link (Layer 2): Verify VLAN membership, trunk operation, allowed VLANs, spanning-tree state, and MAC learning. A host in the wrong VLAN may have link but lack expected Layer 2 reachability. Check both ends of a link for consistent trunk and VLAN settings.

3. Network (Layer 3): Check the IP address, subnet mask or prefix length, gateway, interface status, ARP or neighbor resolution, and routing-table entries. An incorrect mask can make a host treat a remote destination as local, or a local destination as remote. Verify the return route as well as the forward route.

4. Transport and services (Layers 4–7): If IP reachability works but an application does not, investigate the relevant protocol and port, DNS, DHCP, ACLs, NAT, and service status. Test by IP and by name to distinguish name-resolution failures from reachability failures.

A useful method is to test from near to far: endpoint address and local gateway, first-hop device, each relevant routed hop, then destination. Compare a working path or host with the failing one. A traceroute that stops at a hop narrows the investigation but does not by itself prove that hop is faulty; later routers may simply not return trace responses.

Interpret common fault clues

Treat diagnostic clues as starting hypotheses, not automatic conclusions. An interface error counter is most useful when it increases during the incident; a historical nonzero counter alone may not identify the current cause.

• administratively down: Inspect interface configuration and use no shutdown only if the interface should be active.

• down/down: Check the cable or optic, remote-end status, port selection, and physical link.

• up/down: The physical link exists, but the line protocol is not operational. Check encapsulation, keepalives, and far-end configuration as appropriate to the link type.

• Link is up, but a host cannot reach peers in its VLAN: Check host addressing and mask, access-port VLAN, MAC learning, and spanning-tree forwarding state.

• Hosts work within a VLAN but not beyond it: Check the default gateway, routed interface or SVI state, routes in both directions, and filtering.

• A trunk carries some VLANs but not others: Check trunk mode and state, the allowed VLAN list, native VLAN consistency, VLAN existence, and spanning tree.

• A device reaches an IP address but not its hostname: Check DNS configuration and name resolution; compare a test by hostname with one by IP.

• Only some traffic fails: Check ACL direction and order, protocol and port matching, NAT behavior, and the return path.

• Connectivity is intermittent or performance is poor: Inspect interface error and drop counters, logs, link flaps, and congestion. Compare counters over time rather than relying on one snapshot.

• A configuration appears correct but did not survive a reboot: Compare show running-config with show startup-config, and save a verified intended configuration.

Use debugging cautiously

show commands are generally the first choice because they provide state and counters with less operational risk. Use debug only when a specific event must be observed and ordinary verification is insufficient. Debug output can be extensive and consume CPU, so check device load, select the narrowest relevant debug, collect output briefly, and stop debugging promptly with undebug all or no debug all.

Verify that debugging is off with show debug. On remote sessions, terminal monitor may be needed to display debug messages; it does not make debugging safer. Debugging can affect performance or make a device unusable.