Troubleshooting Playbooks

How to use these playbooks

Do not paste every command you know into a switch and hope the bad line identifies itself. Start with the symptom, form one theory, and run a command that can support or reject that theory. Compare the actual result with the known-good result, then choose the next check.

1. Define the scope. Is one endpoint failing, one VLAN failing, or everything behind the switch failing?
2. Write the expected state. Record the expected IP, MAC address if known, switch, port, VLAN, and upstream path.
3. Test from the edge inward. Start with reachability, then locate the endpoint, inspect its port, and only inspect the uplink if the local evidence points upstream.
4. Make each result earn the next command. A successful check rules out part of the path. A failed check narrows the next place to look.
5. Separate diagnosis from repair. These are read-only workflows. Do not change a port just because its output looks unfamiliar.

Playbook 1: one printer is reported offline

Scenario: A user cannot print to PRINTER1. The ticket says its expected address is 192.168.20.50, its expected access port is SW2 Fa0/3, and printers belong in VLAN 20. “Offline” is only the reported symptom; it does not yet prove a switch problem.

Question 1: Can the printer answer from its gateway? Run the ping from R1#. This tests the router-to-printer path without depending on PC1's access port, IP settings, or local firewall.

ping 192.168.20.50

If it succeeds, Layer 3 reachability from R1 is working. The original problem may be on PC1 or the printer rather than on SW2. If it fails, continue; the failure only tells you that the path is broken somewhere.

Question 2: Did R1 learn a Layer 2 identity for that IP? Run this immediately after the ping so R1 has just attempted ARP.

show arp

An entry for 192.168.20.50gives you the printer's MAC address—the clue a switch can follow. No entry means R1 could not resolve the IP to a MAC address. In that case, verify the printer's power, cable, and IP settings while also checking whether VLAN 20 can reach SW2; do not invent a MAC address or search every MAC-table row.

Question 3: Which SW2 port learned that MAC? On SW2#, inspect the table and find the MAC copied from R1.

show mac address-table

The expected result is the printer MAC on VLAN 20 at Fa0/3. If it appears on Fa0/3, you have tied the IP to the expected physical port. If it appears on Fa0/1, SW2 learned it through the uplink, so the printer is not locally connected where the documentation says it is. If it is absent, SW2 has not recently seen traffic from that MAC.

Question 4: Is the expected port physically usable?

show interfaces status
show interfaces fastEthernet0/3

The status table quickly shows whether Fa0/3 is connected, disabled, or in the wrong VLAN. The detailed interface output adds line protocol, traffic counters, and errors. A down port with no traffic points toward power, cabling, or the endpoint. An up port with increasing errors points toward a physical problem. An up, clean port means you should keep following the logical path.

Question 5: Is Fa0/3 actually configured for the printer network?

show running-config
show vlan brief

In the running config, find the interface FastEthernet0/3 block. It tells you the intended switchport mode and access VLAN. The VLAN table confirms that VLAN 20 exists and Fa0/3 belongs to it.

Question 6: Did the port change state around the time of the ticket?

show logging

Search for Fa0/3 link up/down events. Logs provide timing and history; they do not override the current interface state. Repeated flaps plus interface errors support a cabling or hardware theory. No relevant log entry simply means the switch did not record a useful event.

Playbook 2: link is up, but the device is on the wrong network

Scenario:The endpoint's link light is on, but its IP address is in the wrong subnet or it cannot reach the gateway for its expected VLAN. Physical connectivity exists, so test VLAN placement before blaming the uplink.

Question 1: Which port is the endpoint using, and which VLAN does the switch report?

show interfaces status

Find the endpoint port by description, documentation, or the MAC table—not by guessing. The VLAN column should match the expected access VLAN. If it says trunk or a different VLAN number, capture that mismatch before proposing a change.

Question 2: Does the saved intent match the operational summary?

show running-config
show vlan brief

Find the interface FastEthernet0/3 block in the running config. It shows what the switch is instructed to do; the VLAN table confirms the VLAN exists and lists assigned access ports. If Fa0/3 is configured for VLAN 20 and appears under VLAN 20, the local access-port configuration is internally consistent. If the VLAN does not exist, assigning the port to that number alone will not create a working end-to-end path.

Question 3: If the access port is correct, can that VLAN leave SW2?

show interfaces trunk

In this lab, Fa0/1 should be trunking and VLANs 10 and 20 should be allowed and forwarding. If VLAN 20 is missing from the allowed or forwarding list, the local endpoint can have a perfect link while its traffic still dies at the uplink. Trunks are shared infrastructure: record the evidence and escalate rather than changing an allowed-VLAN list from a user ticket.

Playbook 3: several devices fail, so the issue may be upstream

Scenario: Multiple endpoints in VLAN 20 fail at the same time, or local ports look correct but none of those endpoints can reach their gateway. A shared failure makes the shared uplink or upstream device more likely than several simultaneous endpoint failures.

Question 1: Is the shared trunk operational and carrying the affected VLAN?

show interfaces trunk

Confirm Fa0/1 is trunking and VLAN 20 is allowed and forwarding. If the trunk is down, every VLAN using it can be affected. If only VLAN 20 is absent, the scope should be limited to that VLAN.

Question 2: Does Fa0/1 lead to the device you think it does?

show cdp neighbors detail

CDP should identify SW1 on SW2 Fa0/1. This validates the cable map and tells you which upstream device owns the next part of the path. A surprising neighbor is a documentation or cabling problem, not permission to reconfigure the port.

Question 3: Can the gateway reach the endpoint network?

ping 192.168.20.50
traceroute 192.168.20.50

Run these from R1. Ping tests reachability; traceroute may show where a routed path stops, but a missing response does not always identify the failed device because some devices do not answer traceroute probes. If SW2's local evidence is correct and R1 still cannot reach the subnet, the evidence has crossed your access-switch boundary and should be escalated with the outputs attached.

Quick command chooser

• One device is unreachable: start with ping, then use show arp and show mac address-table to trace IP → MAC → port.
• The link light is off: use show interfaces status for the summary, then the detailed show interfaces output for protocol state, counters, and physical errors.
• The link is up but the network is wrong:compare the interface's running config with show vlan brief before checking the trunk.
• Several devices or a whole VLAN fail: inspect show interfaces trunk, then confirm the upstream neighbor and test reachability from R1.
• The failure is intermittent: compare current interface counters with show logging for link flaps and timing.
• The next step touches shared infrastructure: stop and escalate with the symptom, expected state, command outputs, findings, and exact change you think is required.