VLAN & Switch Troubleshooting: Tracing a Connectivity Issue Over SSH
Using standard Dell OS10 show commands over SSH to trace a VLAN/interface/switch-level issue.
Tools required: SSH client, switch CLI access
Overview
Infrastructure-level issues need a different toolkit entirely - direct switch access. This guide walks the same discovery sequence an automated tool would run, using the switch's own show commands.
Prerequisites
- SSH access to the switch
- Read-only or higher CLI privilege
Step-by-Step Manual Check
Check the physical interface and port status
Confirms the port is actually up, and whether it's err-disabled - the single most common cause of "this jack suddenly stopped working".
show interface statusHealthy result
Port Description Status Speed Duplex Vlan ethernet1/1/1 up 1000Mb full 100
Problem result
Port Description Status Speed Duplex Vlan ethernet1/1/1 err-disabled -- -- 100
What it means
err-disabled usually means the switch automatically shut the port down after detecting a problem - a BPDU guard violation (a loop or an unauthorized switch plugged in), a port-security violation (unexpected MAC address), or repeated link flapping. The specific reason is shown in the switch's logs (show logging), not in this command's output alone.
If unresolved, escalate to: Level 3 — Expert / Critical
Confirm the VLAN assignment and trunk configuration
A device with a perfectly working physical link will still have no connectivity if it's on the wrong VLAN, or if a trunk port isn't carrying the VLAN it needs to.
show vlan
show interface ethernet1/1/1 switchportHealthy result
VLAN 100 shown as Active, with the expected ports listed as members (tagged for trunks, untagged for access ports).
Problem result
The expected VLAN is missing from the port's member list entirely, or the port is configured as access VLAN 1 (the default) instead of the intended VLAN.
What it means
A device plugged into a port still on default VLAN 1 will have link lights and looks physically fine, but sits on the wrong logical network - explaining "the cable is plugged in but nothing works" reports.
If unresolved, escalate to: Level 3 — Expert / Critical
Confirm the device's MAC address is being learned where expected
Shows exactly which physical port the switch has learned a specific device's MAC address on, which confirms (or disproves) where a device is actually physically connected.
show mac address-table address 00:1a:2b:3c:4d:5eHealthy result
VlanId Mac Address Type Interface 100 00:1a:2b:3c:4d:5e dynamic ethernet1/1/1
Problem result
No entry found for the MAC address anywhere in the table.
What it means
If a device's MAC address doesn't appear in the table at all, the switch has never seen a frame from it - the problem is upstream of the switch itself (bad cable, disabled NIC, wrong port), not a switch configuration issue.
If unresolved, escalate to: Level 3 — Expert / Critical
Check neighboring device discovery
LLDP shows what's actually connected to each port according to the devices themselves, catching cabling mistakes (patched into the wrong port) that VLAN/MAC checks alone would miss.
show lldp neighborsHealthy result
Local Port Device ID Port ID System Name ethernet1/1/1 aa:bb:cc:dd:ee:ff Gi0/1 access-switch-2
Problem result
The expected neighbor is missing, or a different, unexpected device/switch appears on that port.
What it means
An unexpected neighbor on a port is strong evidence of a cabling mix-up - a patch cable landed in the wrong physical port during rack work. This is often the fastest way to catch a mistake that would otherwise take much longer to trace through VLAN and MAC tables alone.
If unresolved, escalate to: Level 3 — Expert / Critical
Check port-channel (LAG) and VLT status if applicable
If the link in question is part of a bonded port-channel or a VLT (Virtual Link Trunking) pair between two switches, an individual member link failing can silently reduce capacity without a full outage - worth ruling out on core/uplink connections.
show port-channel summary
show vltHealthy result
All expected member ports shown as (P) - up and participating in the port-channel. VLT status shows ICL (inter-chassis link) up and both peers in sync.
Problem result
One or more member ports shown as (D) - down/not participating, or VLT status shows the peers out of sync.
What it means
A degraded port-channel (some members down) reduces total bandwidth but rarely causes a full outage - this explains reports of intermittent congestion on links that 'should' have plenty of capacity. A VLT out-of-sync condition is more serious and should be escalated immediately, since it can affect failover behavior between the two switches.
If unresolved, escalate to: Level 3 — Expert / Critical
Interpreting the Results
Work bottom-up through the OSI layers: physical port status first (Step 1), then VLAN/logical config (Step 2), then confirm what the switch has actually learned (Steps 3-4), and only check port-channel/VLT health (Step 5) if the affected link is a bonded uplink rather than a single access port.
Common Causes
| Symptom | Likely Cause | Fix |
|---|---|---|
| Port suddenly stopped working, shows err-disabled | A protection mechanism (BPDU guard, port security) automatically shut the port down after detecting a problem | Check show logging for the specific trigger, resolve the root cause, then re-enable with shutdown / no shutdown. |
| Device connected but has no network access, no errors reported | Port is on the wrong VLAN (often still on default VLAN 1) | Reassign the port to the correct VLAN with the switch's configuration commands. |
| Intermittent congestion on a link expected to have high capacity | One or more members of a bonded port-channel are down, silently reducing total bandwidth | Investigate the down member link's physical layer (Step 1) rather than assuming a bandwidth/config problem. |
Automated by
Diagnostic Suite - VLAN Automation (Option 5)
Automates this exact SSH show-command discovery sequence across multiple switches and summarizes findings.