Lab ts-na-01 - Troubleshooting Switching and VLAN Tickets

Layer 2 faults are the ones that make engineers doubt their own eyes. Two devices on the same subnet, both interfaces up, both correctly addressed, and yet they cannot reach each other. The IP configuration is flawless. The problem is one layer down, in how the switch decides which port belongs to which broadcast domain. This lab gives you three switching tickets on the five-node base topology. It is part of the PingLabz CCNA Troubleshooting Labs, fits Cisco Modeling Labs Free, and every output was captured on a Cisco IOS XE managed switch.

The topology and healthy state

SW1 is the managed switch in the middle of the LAN. Its ports: Et0/0 to R1, Et0/1 to R2, Et0/2 to HOST1. In the healthy state all three are access ports in VLAN 10, the single user LAN, and R1 (10.20.0.1) pings R2 (10.20.0.2) cleanly across 10.20.0.0/24:

R1# ping 10.20.0.2
!!!!!
Success rate is 100 percent (5/5)

One note before you start. On this IOL switch platform the VLANs show up with their default names (VLAN0010, VLAN0020) rather than friendly names, so do not lean on the name to tell you anything. Diagnose by VLAN ID and which port sits in which VLAN, which is the more reliable habit anyway.

Lab setup: this topology boots with all three faults already in place, one per ticket, each one a single access port assigned to the wrong VLAN or the wrong mode. Faults can mask each other: until both R1's port and R2's port are correct, an end-to-end ping between them stays down, so verify each port's assignment as you go and save the final ping for last.

What you will learn

• Why same-subnet hosts that cannot ping each other is almost always a VLAN problem, not an IP problem.
• How to read show interfaces status, show vlan brief, and show mac address-table together to place each device in its broadcast domain.
• The silent trap of a mistyped VLAN ID that IOS "helpfully" auto-creates, and the two real tells that give it away.
• What happens when an access port to a router gets set to trunk mode, and the native-VLAN behavior that explains it.

Ticket 1: "Two devices on the same subnet can't ping each other"

Reported symptom: "R1 and R2 are both 10.20.0.x/24, both interfaces are up, but they can't ping. I've checked the IPs four times."
Success criterion: R2's port is back in VLAN 10 with the rest of the LAN.

R1# ping 10.20.0.2
.....
Success rate is 0 percent (0/5)

The IPs really are correct, so stop checking them. When same-subnet hosts cannot reach each other, drop to Layer 2 and ask the switch where each device lives. The fastest single view is the port-to-VLAN map:

SW1# show interfaces status
Port         Name               Status       Vlan       Duplex  Speed Type
Et0/0        Access to R1 (targ connected    trunk        full   auto 10/100/1000BaseTX
Et0/1        Access to R2 (targ connected    20           full   auto 10/100/1000BaseTX
Et0/2        Access to HOST1 (t connected    30           full   auto 10/100/1000BaseTX
Et0/3        Spare access port  connected    1            full   auto 10/100/1000BaseTX

That one command exposes the whole mess. Nothing is in VLAN 10. R1's port is a trunk, R2 (Et0/1) is in VLAN 20, and HOST1 (Et0/2) is in VLAN 30. Three separate faults, one per ticket. Start with R2, which is the device in this ticket. The MAC table confirms where each device's traffic is landing:

SW1# show mac address-table dynamic
Vlan    Mac Address       Type        Ports
   1    aabb.cc00.2900    DYNAMIC     Et0/0     (R1, untagged into the trunk's native VLAN 1)
  20    aabb.cc00.2700    DYNAMIC     Et0/1     (R2)
  30    5254.000d.03a6    DYNAMIC     Et0/2     (HOST1)

Your MAC addresses will not match these. CML assigns the IOL interface MACs dynamically every time the lab is imported, so read the VLAN and port columns, not the specific addresses. The story they tell is the point: the three devices are scattered across three different VLANs and none of them is VLAN 10.