Access Port Lands in Wrong VLAN After Move
A technician moves a workstation from patch panel port 14 to port 22 on an ArubaOS-Switch 2930F. The user reports no connectivity. Port 14 is configured with untagged vlan 30 and tagged vlan 99. Port 22 is still at factory defaults. The edge uplink to the core carries VLAN 30 untagged and VLAN 99 tagged. The technician insists the workstation worked fine before the move and wants to know why the switch 'lost' the configuration. The workstation is set for DHCP and previously received 10.30.4.51/24. No other changes were made to the switch that day.
1. Explain why the workstation has no connectivity after the move, and describe the exact configuration needed on port 22 to restore service.
Read the worked answer
The configuration did not get lost; it lives on port 14, not on the workstation. Port 22 is at factory defaults, so it belongs to VLAN 1 (the default untagged VLAN). Frames from the workstation arrive untagged, are placed in VLAN 1, and are forwarded toward the core on the uplink's untagged VLAN (30) only if the switch tags/untags consistently - but the access port itself is in the wrong broadcast domain, so DHCP for 10.30.4.0/24 never reaches it.
Fix on port 22:
interface 22
untagged vlan 30
tagged vlan 99
no shutdown
Key reasoning: an access port must be untagged in exactly one VLAN, and that VLAN must match the subnet the device expects. The tagged vlan 99 matters only if the workstation or a downstream device needs 802.1Q trunking; for a plain workstation it is optional but harmless. The real lesson: VLAN membership is per-port state, so moving a cable requires re-applying the port profile.
2. If the technician instead configured port 22 as `tagged vlan 30`, what symptom would appear and why?
Read the worked answer
The workstation sends untagged frames, but the port now expects 802.1Q-tagged frames for VLAN 30. Untagged frames received on a port that has no untagged VLAN membership are dropped (or placed in VLAN 1 depending on platform behavior), so the workstation still gets no DHCP lease. The symptom looks identical to the original problem - no link-layer connectivity - which is why the distinction between tagged and untagged matters. Tagging is for trunk links between switches or to tag-aware devices, not for a standard end host.