Cisco Switch Commands
Step 6 of 875%

Health, Logs & Connectivity

After you inspect VLANs, trunks, and neighbors, check whether the devices look healthy and whether traffic can actually move. This page teaches how to read health output as evidence, not just how to run another list of commands.

After this page, you should be able to:

  • Spot physical-layer clues in detailed interface output
  • Use logs to separate recent events from current interface state
  • Use version output to find uptime and basic device identity
  • Test reachability from R1 and PC1 and understand what each test proves
  • Record expected failures as useful evidence instead of treating them as dead ends

show interfaces fastEthernet0/3: health of the printer port

Open SW2, go to the CLI tab, and get to SW2#. This command asks a focused question: does the PRINTER1 switchport look physically healthy?

show interfaces fastEthernet0/3

Packet Tracer's 2960 switch does not support show interfaces counters errors. Use the detailed interface command show interfaces fastEthernet0/3 instead, then look for link state and error counters.

FastEthernet0/3 is up, line protocol is up (connected)
  Hardware is Lance, address is 0001.42c8.0002
  Full-duplex, 100Mb/s
     0 input errors, 0 CRC, 0 frame, 0 overrun
     0 output errors, 0 collisions, 0 interface resets

Expected result for this lab: Fa0/3 should be up if PRINTER1 is connected. Seeing zero errors is normal and useful: it says the printer problem probably is not a bad cable or noisy port. If you see many CRC errors, input errors, collisions, or resets, then the physical link deserves attention before you blame VLANs or routing.

This command does not prove PRINTER1 is in the correct VLAN. It only helps answer whether the local port looks physically stable. You still need show interfaces status, show vlan brief, and trunk checks for the VLAN side of the problem.

show logging: what changed recently

Stay on SW2#. Interface status shows what is true right now. Logs show what happened recently. That matters because a port can look fine now but still have flapped, been blocked, or been changed a few minutes ago.

show logging

Manually scan for Fa0/3, Fa0/1, link up/down messages, spanning tree messages, native VLAN mismatch messages, and configuration messages.

%LINK-5-CHANGED: Interface FastEthernet0/3, changed state to up
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/3, changed state to up
%SYS-5-CONFIG_I: Configured from console by console

Expected result for this lab: it is okay if you mostly see config messages and link up/down messages from your own testing. Native VLAN mismatch or PVID errors are not expected in the known-good lab. If you see them, verify the cable map and trunk config before continuing.

Logs do not always tell you the root cause by themselves. They are timeline evidence. Pair them with the current state from show interfaces status and the config from show running-config.

show version: device identity and uptime

Stay on SW2#. This command is not a printer-specific command. It tells you what device you are on and how long it has been running.

show version

Look near the top for hostname and uptime, and farther down for model and IOS information.

Cisco IOS Software, C2960 Software
SW2 uptime is 2 hours, 14 minutes
cisco WS-C2960-24TT-L

Expected result for this lab: you should see a Cisco 2960-style switch and an uptime value. The exact uptime does not need to match this example. In real tickets, a recent reboot can explain why users saw an outage even if the port looks healthy now.

This command is also a safety check. If the hostname or model is not what you expected, stop and confirm you opened the correct device before making changes.

ping and traceroute: prove where reachability stops

Switch devices: open R1, go to the CLI tab, and get to R1#. Use the router for gateway-side reachability because this starter lab does not configure a management IP on SW2.

Start from R1 because R1 is the default gateway for both lab VLANs. A ping from R1 to PRINTER1 asks, "Can the router reach the printer subnet endpoint?" A ping from R1 to PC1 asks the same question for the user subnet endpoint.

ping 192.168.20.50
ping 192.168.10.10
traceroute 192.168.20.50

Expected result in the known-good lab: the R1 pings to PRINTER1 and PC1 should succeed. If a ping fails, use the failure as a clue: check the endpoint IP settings, the SW2 access port VLAN, and the SW1/SW2 trunk path.

Success rate is 0 percent (0/5)
OR
Success rate is 100 percent (5/5)

If the ping fails, do not jump straight to "the printer is down." Use the earlier evidence: is Fa0/3 in VLAN 20, does the upstream port trunk VLAN 20, and does R1 have the VLAN 20 gateway 192.168.20.1?

Then switch devices: open PC1, go to Desktop > Command Prompt, and run a PC ping so you can compare endpoint reachability against router reachability.

ping 192.168.20.50

Testing from R1 and testing from PC1 answer different questions. Always ask: from where, to where, and through which gateway?

Expected result in the known-good lab: PC1 should be able to reach PRINTER1 if endpoint IP settings, access VLANs, and the trunk path match the supplied configs.

Checkpoint

  • You can inspect detailed interface output for physical-layer clues.
  • You can use logs to validate timing instead of guessing.
  • You can test reachability from PC1 and R1.

Hands-On Practice

Use health signals to decide whether the printer issue looks physical, recent, or not obvious from switch data.

Your checklist and answers are saved locally in this browser.

Check Interface Health

Check Logs And Reachability