Locate a device and prove its VLAN

applied · 50 min · Objective 5.5

Task

Answer two questions a technician is asked constantly — "which port is this device on?" and "is it in the right VLAN?" — using device commands rather than tracing a cable or guessing. You will plant a device in the wrong VLAN, find it by its MAC, and confirm the assignment, which is the exact workflow behind an incorrect-VLAN-assignment fault.

Steps

  1. Note the target's MAC address on the host you will hunt for (ip link show eth0). This is the identifier you will search the switch by, the way you would take a MAC from a DHCP lease or an ARP entry.
  2. On the switch VM, find where that MAC lives: bridge fdb show | grep <mac> names the port it was learned on. That answers "which port is this device on?" without touching a cable — the job show mac-address-table does on real gear.
  3. Check the port's VLAN: bridge vlan show lists each port's VLAN membership. Confirm the port is in the VLAN the device is supposed to be in.
  4. Now inject the fault: move that access port from VLAN 10 to VLAN 20. The device now sits in the wrong broadcast domain — it may get no DHCP response, or an address from an unexpected range, while the port shows up and error-free. That "up but wrong network" tell is the signature.
  5. Diagnose and fix using only the commands: bridge vlan show reveals the port in VLAN 20, you move it back to VLAN 10, and confirm the device recovers.

Verify

bridge fdb show | grep -i "$(cat /tmp/target-mac)" || bridge fdb show | head
bridge vlan show
ping -c 2 -W 2 192.168.10.20; echo "same-vlan reach exit $?"

The bridge fdb line locates the device by MAC — the answer to "which port" — and bridge vlan show proves which VLAN that port is in. With the port restored to the correct VLAN the same-VLAN ping succeeds; with it in the wrong VLAN the reachability changes while the link stays up. Those readings settle the fault from device state, not from a theory about the cable.

Notes

The lesson underneath is that a port being up and error-free does not mean the device is where it should be. Incorrect VLAN assignment is invisible to the physical-layer checks — link light on, no CRC errors — and only the VLAN table shows it. A port with no VLAN configured sits in VLAN 1 by default, which is why "the new device gets an address from the wrong range, or none" should send you to show vlan before anything else.

This is also where LLDP/CDP earns its keep on real equipment: those layer 2 discovery protocols tell you what is plugged into which port — device name, model, and the neighbour's port — without tracing anything, and they are how monitoring platforms build topology maps automatically. The caution is that they reveal infrastructure detail, so they are disabled on ports facing untrusted networks, and they only see directly connected neighbours.