By default, a switch puts every port in one big broadcast domain. Sales, Engineering, the printers, and the guest in the lobby all share the same Layer 2 network, hear each other’s broadcasts, and sit one misconfiguration away from each other. VLANs are how you carve that single switch into separate networks without buying more hardware, and on Cisco gear it takes only a handful of commands.
This guide shows how to configure VLANs on a Cisco switch: creating them, putting access ports into them, adding a voice VLAN for an IP phone, and verifying the result on two switches that share the same VLANs over a trunk. Every command and every screen of output below was captured on two Cisco IOS 15.2 switches in GNS3 in June 2026, so what you see is exactly what your switch prints back. The configuration maps to the Cisco CCNA 200-301 objective on VLANs, but the value is the same whether you are studying or building a real access layer.
What a VLAN actually is
A VLAN is a separate broadcast domain riding on a switch you already own. Put Gi0/1 in VLAN 10 and Gi0/2 in VLAN 20, and a broadcast that arrives on Gi0/1 is flooded only to other VLAN 10 ports. VLAN 20 never sees it. You have turned one switch into two logical switches that happen to share the same chassis.
The trade-off is the thing people miss. Isolation is the win: smaller broadcast domains, a clean boundary between departments, and a natural place to apply security policy. The cost is that devices in different VLANs can no longer talk to each other directly. Crossing from VLAN 10 to VLAN 20 needs a Layer 3 device, a router or a Layer 3 switch, which is a separate job covered later in this series. For now, treat each VLAN as an island. A switch builds a MAC address table per VLAN, so the same learning and flooding you already understand happens independently inside each one.
VLAN numbering and where VLANs are stored
VLAN IDs fall into two ranges. The normal range is 1 to 1005, and it is the one you use day to day and the one the CCNA cares about. IDs 1002 to 1005 are reserved for the legacy FDDI and Token Ring VLANs that every switch still lists, and VLAN 1, the default, cannot be deleted. The extended range, 1006 to 4094, exists for large environments. VLAN 1 is the default: every port belongs to it until you say otherwise, and good practice is to move user traffic off VLAN 1 rather than build on it.
Here is the detail that catches people. Normal-range VLANs are not stored in the running configuration. They live in a separate file, vlan.dat, in flash. That means erase startup-config followed by a reload does not wipe your VLANs, they survive. A genuine factory reset of the VLAN database needs delete vlan.dat and a reload. Keep that in mind the next time a “clean” switch still shows VLAN 10 from a previous life.
Create the VLANs
The lab is two switches, SW1 and SW2, joined by a single 802.1Q trunk on Gi0/0. SW1 has an access port in VLAN 10 (Sales) and SW2 has an access port in VLAN 20 (Engineering). The trunk is what lets both VLANs exist on both switches, which is the whole point of segmenting an access layer that spans more than one box.
Creating a VLAN takes two commands in global configuration mode: the VLAN id, then a name so the next engineer knows what it is for. Do this on SW1:
enable
configure terminal
vlan 10
name SALES
vlan 20
name ENGINEERING
endThe name is optional but worth the three seconds. Confirm both VLANs exist and are active with show vlan brief:
show vlan briefVLAN 10 and VLAN 20 now appear as active, alongside the default VLAN 1 and the reserved 1002 to 1005 entries that ship with every switch:
Notice that VLAN 10 already lists Gi0/1 in the Ports column. That is because the switch was configured with the access port first, which brings us to the next step.
Assign access ports
An access port carries exactly one data VLAN and connects a single end device, a PC, a printer, a camera. Two commands under the interface do the work: one sets the port to access mode, the other drops it into the VLAN. On SW1, put Gi0/1 in VLAN 10:
configure terminal
interface GigabitEthernet0/1
switchport mode access
switchport access vlan 10
endThe switchport mode access line does more than label the port. It hardcodes the port as access so the Dynamic Trunking Protocol cannot quietly negotiate it into a trunk, which is a small but real hardening step. Verify the result with show interfaces switchport for that port:
show interfaces gi0/1 switchportThe output confirms the port is in static access mode, sits in VLAN 10 (SALES), and has trunk negotiation switched off:
Operational Mode reads down here only because nothing is cabled to Gi0/1 in the lab. The configuration is correct; the port comes up the moment a device is plugged in. If you assign a port to a VLAN that does not exist yet, the switch creates that VLAN for you, but creating it explicitly with a name first keeps the configuration readable.
Add a voice VLAN for an IP phone
Desk phones complicate the one-VLAN-per-port rule. A Cisco IP phone has a small switch built in: the phone plugs into the access port, and the PC plugs into the phone. You want the phone’s voice traffic in its own VLAN for quality of service, and the PC’s data traffic in the normal access VLAN. The voice VLAN handles exactly this on a single cable:
configure terminal
interface GigabitEthernet0/3
switchport mode access
switchport access vlan 10
switchport voice vlan 20
endThe phone tags its voice frames into VLAN 20 while the PC behind it stays untagged in VLAN 10, all on one cable with no trunk. On a port with a phone attached, show interfaces gi0/3 switchport reports the Voice VLAN field as 20 instead of none. The two switches in this lab had no phone cabled, so this step is the configuration rather than a capture, but it is a neat exception that keeps a phone and a workstation cleanly separated over one wire.
Verify VLANs across both switches
VLANs only span more than one switch when two things are true: the same VLAN id exists on each switch, and the link between them is a trunk that carries it. SW1 and SW2 in this lab are joined by an 802.1Q trunk on Gi0/0, and both switches were given VLAN 10 and VLAN 20.
SW2 carries the same two VLANs, but here the Engineering access port lives on Gi0/2. Run show vlan brief on SW2 to confirm:
show vlan briefVLAN 20 (ENGINEERING) now shows Gi0/2 assigned, and VLAN 10 exists and is active even though SW2 has no Sales port of its own, because the trunk carries it across from SW1:
That is the verification habit worth keeping: create the VLAN on every switch it needs to reach, assign the access ports, then confirm with show vlan brief on each box that the VLAN is active and the right ports are in it. The trunk that ties the two together is its own topic, and the IOS CLI shortcuts make moving between these switches and modes much faster once they are second nature.
Delete or change a VLAN safely
Removing a VLAN is one command, but it has a side effect worth respecting. Deleting VLAN 10 leaves any access port that was in it stranded:
configure terminal
no vlan 10
endThe ports that were in VLAN 10 do not fall back to VLAN 1. They go inactive and stop forwarding until you move them to an existing VLAN. So the safe order is always reassign first, then delete: point the ports at their new VLAN, confirm with show vlan brief, and only then remove the old one. To make the whole configuration survive a reload, save it the usual way, remembering that the VLAN database in vlan.dat is already persistent on its own:
copy running-config startup-configIf you are configuring a switch from scratch, the base device configuration (hostname, passwords, SSH) comes first, and knowing the role each network device plays makes it clear why the access layer is where VLANs belong.
Practice the Cisco VLAN commands
Run through the quiz to check the facts that matter, then drill the flashcards until the commands come without thinking. The configs from the two-switch lab above are on GitHub if you want to load them into GNS3, Packet Tracer, or real gear and follow along.
Grab the lab config: the SW1 and SW2 files for this topology live in the c4geeks/ccna-labs repository, with a README that covers loading them and verifying the VLANs.
Where this VLAN design grows
VLANs give you isolation, but on their own they leave two gaps, and both are the next things to build. The first is the link between switches: the moment a VLAN needs to span more than one switch, you need an 802.1Q trunk to carry the tagged traffic, which is where the native VLAN and the allowed-VLAN list come in. The second is reachability between VLANs: Sales in VLAN 10 cannot reach Engineering in VLAN 20 until a router or a Layer 3 switch routes between them. Get the VLANs and access ports solid first, verify them with show vlan brief on every switch, and the trunking and inter-VLAN routing that follow have a clean foundation to sit on. When you are ready for the wider picture, the CCNA 200-301 study roadmap lays out where this fits in the rest of the Network Access topics.
