LUNAROPS · OPERATIONAL UPLINK 100% UPTIME 1,247d POSTS 893 JEFF.MOON@LUNAROPS.DEV UTC --:--:--

CCNA: VLANs and Trunking — Complete Guide

47 min read Networking Deep Dives
ccnanetworkingvlanstrunkingciscoswitchinginter-vlan-routingsecurity
Contents

VLANs are one of those topics where the CCNA curriculum gives you just enough to pass an exam but not quite enough to reason clearly about production networks. The concepts layer on top of each other — access ports lead to trunks, trunks lead to DTP, DTP leads to VLAN hopping, and suddenly you are in a security conversation before you have finished the switching chapter. This guide works through all of it in sequence, with real IOS command output, honest notes on gotchas, and enough depth to make the knowledge stick.

1. Why VLANs Exist: The Problem with Flat Layer 2 Networks

To understand what VLANs solve, you need to understand what life looked like before them.

The Flat Network Problem

In a purely flat Layer 2 network, every device on the same physical switch infrastructure shares a single broadcast domain. When any device sends an ARP request, a DHCP discovery, or any other broadcast, every device on every switch in the network receives and must process that frame. On a 10-device network this is inconsequential. On a 1,000-device network, broadcasts from every device become a meaningful fraction of available bandwidth. On a 5,000-device network you begin to see broadcast storms capable of causing real outages.

Beyond raw broadcast volume, a flat network has no logical boundary between departments. A workstation in Finance and a workstation in Engineering share the same broadcast domain, the same subnet, and — unless you add an external firewall for every East-West traffic flow — the same access to each other. A compromised machine in one part of the organization can ARP-scan and probe machines in every other part with no Layer 3 hop in the way. Network management becomes equally painful: if you want to apply a QoS policy or a different IP addressing scheme to one group of devices, you have no boundary at which to apply it.

The pre-VLAN solution was physical segmentation: put different departments on physically separate switches, run separate cables, buy separate routers. This is expensive, inflexible, and requires physical access every time the business reorganizes. Moving an employee from Engineering to Finance means re-cabling their port or physically moving them to a different switch.

How VLANs Solve This

A VLAN (Virtual Local Area Network) creates a logically independent broadcast domain on a shared physical infrastructure. A single physical switch can simultaneously support dozens of VLANs, and frames in VLAN 10 never reach devices in VLAN 20 at Layer 2 — not because there is a physical wall between them, but because the switch’s MAC address table is VLAN-aware and frames are only forwarded to ports that belong to the same VLAN.

The critical concept is that a VLAN is a broadcast domain boundary. An ARP request sent by a device in VLAN 10 goes only to other devices in VLAN 10. It does not bleed into VLAN 20, regardless of whether those VLANs share the same physical switch hardware. This gives you the isolation benefits of physical segmentation without the cost and inflexibility.

Physical segmentation vs. logical segmentation:

Physical Segmentation                    Logical Segmentation (VLANs)
------------------------------           --------------------------------
Switch A  (Engineering)                  Single Physical Switch
  [PC1] [PC2] [PC3]                        Port 1  -> VLAN 10 (Engineering)
                                            Port 2  -> VLAN 10 (Engineering)
Switch B  (Finance)                         Port 3  -> VLAN 20 (Finance)
  [PC4] [PC5] [PC6]                         Port 4  -> VLAN 20 (Finance)
                                            Port 5  -> VLAN 30 (Management)
2 switches, fixed assignments              One switch, flexible, reconfigurable

To communicate between VLANs you need Layer 3 routing — a router, a multilayer switch, or a firewall. This is intentional. It gives you a chokepoint at which to apply security policy.

Common VLAN Use Cases

Most enterprise networks use a handful of VLANs with specific purposes:

VLAN Typical ID Purpose
Data VLAN 10-99 User workstation traffic
Voice VLAN 100-199 IP phone traffic, requires QoS
Management VLAN 999 Switch/router SSH management, should be isolated
Native VLAN 999 (or unused) Untagged traffic on trunks, should be unused
Server VLAN 200-299 Data center servers, restricted access
DMZ VLAN 300-399 Internet-facing services

The voice VLAN gets a separate entry because it has a unique property: an IP phone and a PC share the same physical switchport, but their traffic is separated into different VLANs at Layer 2. This is covered in detail in Section 10.

2. VLAN Fundamentals: IDs, Ranges, and the VLAN Database

VLAN ID Ranges

VLAN IDs are 12-bit values, giving a theoretical range of 0 to 4095. In practice:

Range IDs Notes
Reserved 0, 4095 Used by the protocol internally, not configurable
Default 1 Factory default, all ports assigned here
Normal range 2-1001 Usable for user VLANs; stored in vlan.dat
Reserved legacy 1002-1005 Reserved for Token Ring (1003-1005) and FDDI (1002). Cannot be deleted.
Extended range 1006-4094 Available on IOS-based switches; requires VTP transparent or VTP off mode in VTPv1/v2; stored in running-config on most platforms

The extended range (1006-4094) is commonly used in data centers and service provider environments where you need more than 1,000 logical segments. On most Catalyst platforms running VTPv1 or VTPv2, you must be in VTP transparent mode to configure extended-range VLANs.

VLAN 1: The Default and Why You Should Not Use It for Data

VLAN 1 is the factory default. Every switch port is assigned to VLAN 1 out of the box. Spanning Tree Protocol sends its BPDUs on VLAN 1. CDP, VTP, and PAgP run on VLAN 1. On a trunk port, VLAN 1 is also the default native VLAN, meaning VLAN 1 traffic travels untagged.

The combination of “every port starts here,” “control plane protocols run here,” and “trunk traffic is untagged here” makes VLAN 1 a significant attack surface. VLAN hopping attacks (covered in Section 7) exploit the native VLAN, and if your native VLAN is also your user data VLAN, a successful attack reaches user traffic directly. Best practice is to move all data traffic to named VLANs, dedicate a different unused VLAN as the native VLAN on trunks, and leave VLAN 1 depopulated.

You cannot delete VLAN 1. You can move traffic away from it and shut down any remaining ports assigned to it, but the VLAN itself persists.

Where VLAN Configuration Is Stored: vlan.dat vs. running-config

Cisco IOS stores VLAN definitions separately from the rest of the running configuration. On IOS-based Catalyst switches, VLANs in the normal range (1-1005) are written to a file called vlan.dat in flash memory. This has a practical consequence: if you do copy running-config startup-config and then reload the switch, the VLAN definitions persist from vlan.dat independently. Conversely, if you do erase startup-config to factory-reset a switch but forget to delete flash:vlan.dat, the switch comes back up with its VLAN database intact. This surprises people regularly.

Extended-range VLANs (1006-4094) on IOS-based switches in VTP transparent mode are stored in the running-config (and therefore in startup-config when you save).

! Verify where your VLANs are stored
Switch# show flash:
-#- --length-- -----date/time------ path
  1    1840     Mar  1 2026 12:00:00 +00:00  vlan.dat
  2  60036864   Mar  1 2026 11:58:00 +00:00  c2960x-universalk9-mz.152-7.E2.bin
  ...

! Delete the VLAN database (use with caution)
Switch# delete flash:vlan.dat
Delete filename [vlan.dat]?
Delete flash:/vlan.dat? [confirm]

Configuring VLANs: Global Config Mode vs. VLAN Database Mode

The old way to configure VLANs was the vlan database command, an interactive sub-mode with its own syntax. Cisco deprecated this years ago and the command is absent from most modern IOS releases. Do not use it. Everything should be done in global configuration mode:

! Modern approach: global config mode
Switch(config)# vlan 10
Switch(config-vlan)# name Engineering
Switch(config-vlan)# exit
Switch(config)# vlan 20
Switch(config-vlan)# name Finance
Switch(config-vlan)# exit
Switch(config)# vlan 99
Switch(config-vlan)# name Management
Switch(config-vlan)# exit
Switch(config)# vlan 999
Switch(config-vlan)# name NativeVLAN_Unused
Switch(config-vlan)# exit

! You can also create a VLAN implicitly by assigning a port to it,
! but the VLAN will have no name and you might not notice it was
! created — always create VLANs explicitly.

Verification:

Switch# show vlan brief

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Gi0/1, Gi0/2, Gi0/3, Gi0/4
                                                Gi0/5, Gi0/6, Gi0/7, Gi0/8
10   Engineering                      active    Fa0/1, Fa0/2, Fa0/3
20   Finance                          active    Fa0/4, Fa0/5
99   Management                       active    Fa0/24
999  NativeVLAN_Unused                active
1002 fddi-default                     act/unsup
1003 token-ring-default               act/unsup
1004 fddinet-default                  act/unsup
1005 trnet-default                    act/unsup

Note that trunk ports do NOT appear in the show vlan brief port column. A port configured as a trunk carries multiple VLANs and is therefore not listed under any individual VLAN in this output. That trips up a lot of people during troubleshooting.

3. Access Ports

An access port is a switchport that belongs to exactly one VLAN and carries untagged frames. The connected device — a PC, a printer, a server — has no knowledge that VLANs exist. The switch is the only entity that understands the VLAN membership. When a frame arrives from the PC on an access port, the switch tags it internally with the port’s assigned VLAN for its own forwarding decisions, but the frame never has an 802.1Q tag applied when sent to the end device.

Configuring Access Ports

Switch(config)# interface FastEthernet0/1
Switch(config-if)# description Engineering PC - Workstation-A
Switch(config-if)# switchport mode access
Switch(config-if)# switchport access vlan 10
Switch(config-if)# switchport nonegotiate
Switch(config-if)# spanning-tree portfast
Switch(config-if)# spanning-tree bpduguard enable
Switch(config-if)# no shutdown

Command by command:

  • switchport mode access — Hardcodes the port as an access port. Disables DTP trunk negotiation. The port will not become a trunk under any circumstances.
  • switchport access vlan 10 — Assigns the port to VLAN 10. If VLAN 10 does not exist in the VLAN database, IOS creates it automatically and logs a message. This can be a gotcha if you mistype the VLAN ID.
  • switchport nonegotiate — Prevents the port from sending DTP frames. On an access port this is somewhat redundant since switchport mode access already disables DTP negotiation, but it is good hygiene and makes your intent explicit.
  • spanning-tree portfast — Tells STP to skip the Listening and Learning states and go directly to Forwarding. This is appropriate for access ports connected to end devices. Never apply it to a port that could be connected to another switch.
  • spanning-tree bpduguard enable — If the port receives a BPDU (which it should not, if it is truly an access port connected to a PC), it shuts down the port with err-disable. This prevents unauthorized switches from being connected and disrupting STP.

Disabling Layer 3 on Access Ports (Routed Ports on L3 Switches)

On a Layer 3 switch, if you want a port to be a routed port (pure Layer 3, no VLAN membership, no switchport behavior), use:

Switch(config)# interface GigabitEthernet0/1
Switch(config-if)# no switchport
Switch(config-if)# ip address 10.0.0.1 255.255.255.252
Switch(config-if)# no shutdown

The no switchport command converts the port from a Layer 2 interface to a Layer 3 routed interface. This is typically used for uplinks between Layer 3 switches or between a switch and a router when you want pure routed connectivity rather than a trunk.

Verifying Access Port Configuration

Switch# show interfaces FastEthernet0/1 switchport

Name: Fa0/1
Switchport: Enabled
Administrative Mode: static access           ! What you configured
Operational Mode: static access              ! What is actually running
Administrative Trunking Encapsulation: dot1q
Operational Trunking Encapsulation: native
Negotiation of Trunking: Off                 ! DTP disabled
Access Mode VLAN: 10 (Engineering)           ! Assigned VLAN with name
Trunking Native Mode VLAN: 1 (default)
Administrative Native VLAN tagging: disabled
Voice VLAN: none
Administrative private-vlan host-association: none
Administrative private-vlan mapping: none
Administrative private-vlan trunk native VLAN: none
Operational private-vlan: none
Trunking VLANs Enabled: ALL
Pruning VLANs Enabled: 2-1001
Capture Mode Disabled
Capture VLANs Allowed: ALL

Protected: false
Unknown unicast blocked: disabled
Unknown multicast blocked: disabled
Appliance trust: none

The key fields: Administrative Mode and Operational Mode should both read static access. If Operational Mode shows trunk when Administrative Mode shows static access, something is wrong and you have a DTP negotiation issue. Negotiation of Trunking should read Off if switchport nonegotiate is applied.

4. 802.1Q Trunking: Frame Structure and Mechanics

A trunk port carries traffic from multiple VLANs simultaneously across a single physical link. To distinguish which VLAN a frame belongs to, the switch inserts a 4-byte tag into the Ethernet frame. This is the IEEE 802.1Q standard.

The 802.1Q Tag Structure

Standard Ethernet frame (untagged):

+-----------+-----------+----------+---------------------+-----+
| Dest MAC  | Src MAC   | EtherType| Payload (46-1500 B) | FCS |
| 6 bytes   | 6 bytes   | 2 bytes  |                     | 4 B |
+-----------+-----------+----------+---------------------+-----+
                         Total max: 1518 bytes

802.1Q tagged frame:

+-----------+-----------+------+------+----------+---------------------+-----+
| Dest MAC  | Src MAC   | TPID | TCI  | EtherType| Payload             | FCS |
| 6 bytes   | 6 bytes   | 2 B  | 2 B  | 2 bytes  | 46-1500 bytes       | 4 B |
+-----------+-----------+------+------+----------+---------------------+-----+
                         \--4B tag--/
                         Total max: 1522 bytes

The 4-byte tag inserts between the source MAC address and the original EtherType field. The FCS is recomputed. Maximum frame size increases from 1518 to 1522 bytes.

The tag breaks down as follows:

TPID (2 bytes)          TCI (2 bytes)
+----------------+      +--------+---------+-----------------+
| 0x8100         |      |  PCP   |   DEI   |      VID        |
| Tag Protocol   |      | 3 bits |  1 bit  |    12 bits      |
| Identifier     |      +--------+---------+-----------------+
+----------------+
Field Size Value / Purpose
TPID 16 bits Always 0x8100. Tells the receiving device this is an 802.1Q-tagged frame.
PCP 3 bits Priority Code Point. Maps to IEEE 802.1p Class of Service (CoS). Values 0-7, where 7 is highest priority. Used for QoS — voice typically uses CoS 5.
DEI 1 bit Drop Eligible Indicator (formerly CFI). Set to 1 means the frame can be dropped during congestion.
VID 12 bits VLAN Identifier. 0 and 4095 are reserved; usable range is 1-4094. 12 bits gives 4096 possible values.

How the Switch Inserts and Strips Tags

When a frame arrives on an access port from an end device, it arrives untagged. The switch internally associates the frame with the port’s VLAN but does not modify the frame for forwarding to other access ports in the same VLAN. When that frame needs to cross a trunk link, the switch inserts the 802.1Q tag before transmitting.

On the receiving end of a trunk, the switch reads the VID, strips the tag, and forwards the frame out the correct access ports for that VLAN — again without a tag visible to the end device.

The native VLAN is the exception: traffic in the native VLAN crosses the trunk untagged. Both sides must agree on which VLAN is the native VLAN or chaos ensues (covered below).

Native VLAN: Concept and Consequences of Mismatch

The native VLAN is the single VLAN whose traffic crosses a trunk link without an 802.1Q tag. Its historical purpose was backward compatibility with older devices that did not understand 802.1Q tagging. By default it is VLAN 1.

Native VLAN behavior:

  • Outbound: Frames belonging to the native VLAN are transmitted untagged across the trunk.
  • Inbound: Untagged frames received on a trunk port are placed into the native VLAN.

This becomes a problem when the two ends of a trunk have different native VLAN configurations. Consider:

Switch-A (native VLAN = 1)  <----trunk---->  Switch-B (native VLAN = 10)

Switch-A sends an untagged frame from VLAN 1.
Switch-B receives an untagged frame and places it in VLAN 10.
VLAN 1 traffic on Switch-A silently arrives in VLAN 10 on Switch-B.

This is a silent misconfiguration: traffic crosses a VLAN boundary without any 802.1Q tag indicating it should. CDP detects this and logs a warning:

%CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on
GigabitEthernet0/1 (10), with SW1 GigabitEthernet0/1 (1).

The CDP warning only fires if CDP is enabled on both sides and both devices are Cisco. In a mixed-vendor environment, or if CDP is disabled for security reasons, you will not get this warning — you will just have a broken network and mysterious traffic appearing in the wrong VLAN. Always verify native VLAN consistency manually when trunks are not behaving.

5. Trunk Port Configuration on Cisco IOS

Basic Trunk Configuration

Switch(config)# interface GigabitEthernet0/1
Switch(config-if)# description Trunk to Core-SW1
Switch(config-if)# switchport trunk encapsulation dot1q
Switch(config-if)# switchport mode trunk
Switch(config-if)# switchport trunk native vlan 999
Switch(config-if)# switchport trunk allowed vlan 10,20,99,999
Switch(config-if)# switchport nonegotiate
Switch(config-if)# no shutdown

Command by command:

  • switchport trunk encapsulation dot1q — Required on older Catalyst switches (3550, 3560, some 3750) that support both ISL and 802.1Q. On these switches you must specify the encapsulation before setting mode to trunk; otherwise the command may be rejected or ISL may be negotiated. On newer switches that support only 802.1Q (most modern Catalyst 2960, 9000 series), this command is not available — 802.1Q is the only option.
  • switchport mode trunk — Hardcodes the port as a trunk. The port will be a trunk regardless of what the neighbor does. Note that this alone does NOT disable DTP — the switch still sends DTP frames advertising itself as a trunk.
  • switchport trunk native vlan 999 — Changes the native VLAN from the default VLAN 1 to VLAN 999. Best practice is to use a dedicated, unused VLAN as the native VLAN to prevent VLAN hopping and isolate untagged traffic.
  • switchport trunk allowed vlan 10,20,99,999 — Restricts which VLANs can traverse this trunk to an explicit list. The default allows all VLANs (1-4094). Restricting this list is a security best practice: if VLAN 30 (Finance) should never reach the access layer switch on the other end, do not allow it on the trunk.
  • switchport nonegotiate — Disables DTP entirely. The port will not send or respond to DTP frames. This should always be set on trunk ports.

Managing the Allowed VLAN List

! Start fresh: allow only specific VLANs
Switch(config-if)# switchport trunk allowed vlan 10,20,30,99,999

! Add a VLAN without rebuilding the entire list
Switch(config-if)# switchport trunk allowed vlan add 40

! Remove a specific VLAN from the trunk
Switch(config-if)# switchport trunk allowed vlan remove 20

! Restore the default (all VLANs allowed) — use with caution
Switch(config-if)# switchport trunk allowed vlan all

! Allow a range
Switch(config-if)# switchport trunk allowed vlan 10-30,99,999

Gotcha: switchport trunk allowed vlan 10,20,30 does not add to the existing list — it replaces the entire list with exactly VLANs 10, 20, and 30. If the trunk was previously allowing VLAN 99 (your management VLAN), running that command will silently drop management VLAN off the trunk and you will lose SSH connectivity. Always use add when extending an existing allowed list, and always include your management VLAN.

Full Annotated show interfaces trunk Output

Core-SW1# show interfaces trunk

Port        Mode         Encapsulation  Status        Native vlan
Gi1/0/23    on           802.1q         trunking      999
Gi1/0/24    on           802.1q         trunking      999

Fields in section 1:

  • Port — The interface identifier.
  • Mode — The administrative mode. on means statically set to trunk (switchport mode trunk). auto or desirable means DTP is active. on is what you want in production.
  • Encapsulation — The trunking protocol. 802.1q is correct for all modern networks. If you ever see isl here, you are looking at a very old switch or a misconfiguration.
  • Status — The operational state. trunking means the trunk is up and forwarding. not-trunking means a mode mismatch (e.g., one side is static access).
  • Native vlan — The configured native VLAN for this trunk. Verify this matches the neighbor.
Port        Vlans allowed on trunk
Gi1/0/23    10,20,99,999
Gi1/0/24    10,20,30,40,99,999

Section 2: Vlans allowed on trunk — The list of VLANs permitted by the switchport trunk allowed vlan configuration. This is what you explicitly configured. It does not mean these VLANs exist in the VLAN database; it just means they are allowed to traverse if they do exist.

Port        Vlans allowed and active in management domain
Gi1/0/23    10,20,99,999
Gi1/0/24    10,20,30,40,99,999

Section 3: Vlans allowed and active in management domain — The intersection of (VLANs allowed on trunk) AND (VLANs that exist in the local VLAN database). If VLAN 40 is allowed on Gi1/0/24 but does not appear in show vlan brief, it will be absent from this section. This is the most diagnostically useful section: if a VLAN disappears from here, it either is not in the VLAN database on this switch or it is not in the allowed list.

Port        Vlans in spanning-tree forwarding state and not pruned
Gi1/0/23    10,20,99,999
Gi1/0/24    10,20,30,40,99,999

Section 4: Vlans in spanning-tree forwarding state and not pruned — The VLANs from section 3 that STP has placed in the Forwarding state and that have not been pruned by VTP. If a VLAN appears in section 3 but not section 4, STP has blocked it on this port (possible in redundant topologies) or VTP pruning has removed it. In a simple non-redundant topology, sections 3 and 4 should be identical.

To check a single interface rather than all trunks:

Core-SW1# show interfaces GigabitEthernet1/0/23 trunk

Port        Mode         Encapsulation  Status        Native vlan
Gi1/0/23    on           802.1q         trunking      999

Port        Vlans allowed on trunk
Gi1/0/23    10,20,99,999

Port        Vlans allowed and active in management domain
Gi1/0/23    10,20,99,999

Port        Vlans in spanning-tree forwarding state and not pruned
Gi1/0/23    10,20,99,999

6. DTP: Dynamic Trunking Protocol

DTP is a Cisco proprietary Layer 2 protocol that negotiates trunking between adjacent Cisco switches. It was designed to simplify configuration: connect two switches and they automatically figure out whether to form a trunk. In practice, it creates more problems than it solves and should be disabled on all ports in production.

The Five DTP Port Modes

Mode IOS Command Behavior
Access switchport mode access Permanently access. Will not trunk regardless of neighbor. Sends DTP frames saying it is an access port.
Trunk switchport mode trunk Permanently trunk. Sends DTP frames advertising trunk. Responds to DTP from neighbor.
Dynamic Auto switchport mode dynamic auto Passively waits. Does not initiate DTP negotiation but responds to DTP from neighbor. Default on many Cisco switches.
Dynamic Desirable switchport mode dynamic desirable Actively initiates DTP negotiation. Sends DTP frames trying to become a trunk.
Nonegotiate switchport nonegotiate Disables DTP entirely. Does not send or respond to DTP frames. Used with switchport mode trunk or switchport mode access.

DTP Negotiation Matrix

The outcome when two switches connect depends on both sides’ modes:

Trunk Dynamic Desirable Dynamic Auto Access
Trunk Trunk Trunk Trunk Misconfig (access side may not pass tagged frames correctly)
Dynamic Desirable Trunk Trunk Trunk Access
Dynamic Auto Trunk Trunk Access Access
Access Misconfig Access Access Access

The default mode on many Cisco switches is dynamic auto. Two switches both in dynamic auto mode connected together will NOT form a trunk — both are passively waiting and neither initiates. They end up as access ports. This surprises people who assume two switches automatically trunk. You need at least one side to be dynamic desirable or one side to be hardcoded trunk for DTP to negotiate a trunk.

Why DTP Is a Security Risk

DTP’s automatic negotiation is a liability. An attacker who connects a device to a switch port in dynamic auto or dynamic desirable mode and sends correctly crafted DTP frames can negotiate a trunk, at which point the attacker’s interface receives traffic from every VLAN on that trunk. This is the switch spoofing attack (covered in Section 7).

Best practice:

! On all access ports: hardcode access and disable DTP
Switch(config-if)# switchport mode access
Switch(config-if)# switchport nonegotiate

! On all trunk ports: hardcode trunk and disable DTP
Switch(config-if)# switchport mode trunk
Switch(config-if)# switchport nonegotiate

Never rely on DTP to negotiate trunks in production. Hard-code everything.

7. VLAN Hopping Attacks

VLAN hopping is a category of attacks that allow an attacker to send traffic into a VLAN they are not a member of. There are two primary techniques.

Attack 1: Switch Spoofing

The attacker connects a device to a switch port that has DTP enabled (mode dynamic auto or dynamic desirable). The attacker’s device sends DTP frames impersonating a switch and negotiates a trunk link with the victim switch. Once the trunk is established, the attacker receives frames from all VLANs on that trunk.

Legitimate topology:
[Switch A] --trunk-- [Switch B]
                        |
                    [Access Port]
                        |
                      [PC]

Attack topology:
[Switch A] --trunk-- [Switch B]
                        |
                  [Port: dynamic auto]
                        |
                  [Attacker device]
                  sends DTP frames -->
                  negotiates trunk
                  <-- now receives all VLANs

Mitigation: Disable DTP on every port. Use switchport mode access + switchport nonegotiate on access ports. Use switchport mode trunk + switchport nonegotiate on trunk ports. Shut down all unused ports and put them in an unused VLAN.

Attack 2: Double Tagging

The double-tagging attack exploits the native VLAN behavior and is more subtle. It works even on ports correctly configured as access ports, provided the attacker is on the native VLAN.

The attack mechanism:

  1. The attacker connects to an access port whose VLAN matches the native VLAN of the upstream trunk (typically VLAN 1 in a default config).
  2. The attacker crafts a frame with two 802.1Q tags. The outer tag is VLAN 1 (the native VLAN). The inner tag is VLAN 20 (the target VLAN).
  3. When Switch-A receives this frame on the access port, it is processed as a normal untagged frame in VLAN 1, but the frame already has two tags embedded.
  4. Switch-A forwards the frame out the trunk to Switch-B. Because VLAN 1 is the native VLAN, Switch-A strips the outer tag (as normal trunk behavior) and forwards the frame with only the inner tag (VLAN 20) intact.
  5. Switch-B receives a frame tagged VLAN 20 and delivers it to devices in VLAN 20.
Frame crafted by attacker:
+----------+----------+---------------------+-----+
|  Outer   |  Inner   |                     |     |
| Tag:     | Tag:     |    Payload          | FCS |
| VLAN 1   | VLAN 20  |                     |     |
+----------+----------+---------------------+-----+

After Switch-A strips outer tag (native VLAN behavior):
+----------+---------------------+-----+
|  Inner   |                     |     |
| Tag:     |    Payload          | FCS |
| VLAN 20  |                     |     |
+----------+---------------------+-----+
Delivered to VLAN 20 devices on Switch-B

Why it is one-directional: The return path does not work. Devices in VLAN 20 on Switch-B send normal VLAN 20-tagged frames. Switch-B forwards them tagged VLAN 20 onto the trunk. Switch-A receives them, sees VLAN 20, and forwards them to access ports in VLAN 20. The attacker is not on VLAN 20, so they never receive the reply. This attack can be used for one-way traffic injection (denial of service, unsolicited data delivery) but cannot be used to establish bidirectional communication without additional techniques (e.g., if the attacker has a sniffer on the trunk).

Mitigation:

  • Change the native VLAN on all trunks to an unused VLAN (one with no hosts). If the native VLAN has no hosts, there is nobody to originate the double-tagged frames.
  • Configure vlan dot1q tag native globally to force the switch to tag native VLAN traffic. This makes every frame on the trunk carry an 802.1Q tag, eliminating the distinction between “tagged” and “native”:
Switch(config)# vlan dot1q tag native
  • Never place hosts on the native VLAN.

8. VTP: VLAN Trunking Protocol

VTP is a Cisco proprietary Layer 2 protocol that synchronizes the VLAN database across all switches in a VTP domain. Instead of configuring VLANs on every switch individually, you configure them once on a VTP server and VTP propagates the changes across all trunk links.

On paper this is convenient. In practice, VTP’s revision number mechanism has caused some of the most dramatic and well-documented production outages in enterprise networking.

VTP Modes

Mode Capabilities VLAN Storage
Server Create, modify, delete VLANs. Advertises changes. NVRAM (vlan.dat)
Client Cannot modify VLANs. Receives updates from server. NVRAM (vlan.dat) — VTPv1/v2
Transparent Can create/modify/delete local VLANs only. Forwards VTP messages but does not sync. NVRAM (running-config for extended VLANs)
Off (VTPv3 only) Same as Transparent but does not forward VTP messages at all. Local only

VTP Versions

Version Key Features
VTPv1 Original version. Normal range VLANs only.
VTPv2 Adds Token Ring VLAN support, consistency checks, transparent mode forwarding improvements. Functionally similar to v1 for most deployments.
VTPv3 Extended VLAN range support (1-4094). Primary server concept prevents revision bombing. Private VLAN support. MST propagation. VTP Off mode. MD5 authentication improvements.

The Revision Number Problem (VTP Bomb)

This is the scenario that has caused real production outages. Understand it thoroughly.

Every VTP server maintains a configuration revision number, a 32-bit counter that increments each time a VLAN is created, modified, or deleted. When a switch receives a VTP advertisement, it compares the revision number in the advertisement to its own. If the incoming revision number is higher, the switch assumes the advertisement is newer and replaces its entire VLAN database with the contents of the advertisement.

The catastrophic scenario:

Step 1: Production network has 50 VLANs, revision number = 47.
        All switches are synced and happy.

Step 2: Engineer takes Switch-X out of service for maintenance.
        Over months, VLANs are added/modified in production.
        Production revision number climbs to 89.
        Switch-X still has revision number 47, old VLAN database.

Step 3: Different engineer connects Switch-X to the production
        network to "just check some configs."
        Switch-X is in VTP server mode with revision 47.

Step 4: Chaos. Switch-X has a LOWER revision number (47 < 89),
        so it does NOT overwrite production. So far so good.

BUT: What if Switch-X was used in a test lab where someone
     configured/deleted VLANs many times?
     Switch-X revision number = 112.

Step 5: Switch-X sends VTP advertisement with revision 112.
        Every switch in the production domain has revision < 112.
        Every switch replaces its VLAN database with Switch-X's
        old, incomplete VLAN database.
        50 production VLANs are now gone.
        Network outage.

This scenario has happened in real networks. The fix took a while because the engineers did not initially understand why the VLANs had vanished. The restoration required manually recreating all 50 VLANs from documentation (if documentation existed).

There are two ways to reset a switch’s VTP revision number to 0 before connecting it to a production network:

  1. Change the VTP domain name to something else, then change it back.
  2. Change the VTP mode to transparent, then change it back.

VTPv3 Primary Server

VTPv3 introduced the primary server concept to prevent revision bombing. In VTPv3, only the designated primary server can originate VTP updates that other switches accept. Secondary servers (which have the same capabilities as v1/v2 servers) can hold the VLAN database but cannot propagate changes. A switch must be explicitly promoted to primary server with an exec-level command:

Switch# vtp primary vlan
This system is becoming primary server for feature vlan in the VTP domain.
No conflicting VTP3 devices found.
Do you want to continue? [confirm] y

This is a one-time action. If another switch already holds primary server status, the promotion will fail until that switch relinquishes it.

VTP Configuration

! Configure VTP server
Switch(config)# vtp domain CORP_NETWORK
Switch(config)# vtp mode server
Switch(config)# vtp version 2
Switch(config)# vtp password S3cur3VTP!

! Configure VTP client
Switch(config)# vtp domain CORP_NETWORK
Switch(config)# vtp mode client
Switch(config)# vtp version 2
Switch(config)# vtp password S3cur3VTP!

! Opt out entirely (recommended for most deployments)
Switch(config)# vtp mode transparent
! or, in VTPv3:
Switch(config)# vtp mode off

Verification:

Switch# show vtp status

VTP Version capable             : 1 to 3
VTP version running             : 2
VTP Domain Name                 : CORP_NETWORK
VTP Pruning Mode                : Disabled
VTP Operating Mode              : Server
Maximum VLANs supported locally : 255
Number of existing VLANs        : 12
Configuration Revision          : 23
MD5 digest                      : 0x2A 0x4F 0x91 0xC3 0xB7 0xE2 0xD1 0x85

Fields to verify:

  • VTP version running — Should be consistent across all switches in the domain.
  • VTP Domain Name — Must match exactly (case-sensitive) on all switches for VTP to work.
  • VTP Operating Mode — Server/Client/Transparent/Off.
  • Configuration Revision — Monitor this. Any switch with an unexpectedly high revision number should be investigated before being connected to production.
  • Number of existing VLANs — Cross-check against show vlan brief.

Practical Recommendation

Many enterprise networks have moved to VTP transparent or VTP off on all switches. The automation and simplicity benefit of VTP is not worth the risk of revision number disasters in most environments. If you use Ansible, Terraform, or any other configuration management tool to manage switch configurations, those tools maintain your source of truth and propagate VLANs to every switch individually, making VTP redundant. The modern recommendation for CCNA-level deployments: set every switch to VTP transparent, manage VLANs manually or via automation, and never worry about revision numbers.

9. Inter-VLAN Routing

Layer 2 switches operate at OSI Layer 2. They forward frames based on MAC addresses within a VLAN but they cannot forward packets between VLANs. For traffic to move from VLAN 10 to VLAN 20, a Layer 3 device — a router, a Layer 3 switch, or a firewall — must be involved.

There are three architecturally distinct approaches.

Method 1: Legacy Routing — One Interface Per VLAN

The oldest approach: dedicate one physical router interface to each VLAN. The switch access port connects to the router’s physical interface, which has an IP address that serves as the default gateway for that VLAN.

Topology:
                    +----------+
                    |  Router  |
                    | .1  .1   |
                    | Fa0 Fa1  |
                    +--+---+---+
                       |   |
              VLAN 10  |   | VLAN 20
              access   |   | access
                    +--+---+---+
                    |  Switch  |
                    +----------+
                       |   |
                     [PC1] [PC2]
                    VLAN10 VLAN20

This approach does not scale beyond two or three VLANs. Each VLAN requires a physical interface on the router, and routers have a finite number of interfaces. For this reason it is considered a legacy design and rarely deployed.

Method 2: Router-on-a-Stick

Router-on-a-stick (RoaS) solves the scaling problem by using a single physical link between the switch and the router, configured as a trunk. The router uses subinterfaces — logical divisions of the physical interface, each assigned to one VLAN. The physical interface carries 802.1Q-tagged frames for multiple VLANs; each subinterface decodes its own VLAN tag.

Topology:
                    +----------+
                    |  Router  |
                    |          |
                    |  Gi0/0   | (one physical port)
                    |          |
                    | .10 .20  |
                    | sub sub  |
                    +----+-----+
                         | trunk (802.1Q)
                         | carries VLAN 10, 20, 99
                    +----+-----+
                    |  L2      |
                    |  Switch  |
                    +----------+
                    |         |
               Fa0/1          Fa0/2
               VLAN 10        VLAN 20
                |                 |
              [PC1]             [PC2]
          192.168.10.10     192.168.20.10

Switch configuration:

! Define VLANs
SW1(config)# vlan 10
SW1(config-vlan)# name Engineering
SW1(config)# vlan 20
SW1(config-vlan)# name Finance
SW1(config)# vlan 99
SW1(config-vlan)# name Management

! Configure access ports
SW1(config)# interface FastEthernet0/1
SW1(config-if)# description Engineering PC
SW1(config-if)# switchport mode access
SW1(config-if)# switchport access vlan 10
SW1(config-if)# switchport nonegotiate
SW1(config-if)# spanning-tree portfast
SW1(config-if)# spanning-tree bpduguard enable

SW1(config)# interface FastEthernet0/2
SW1(config-if)# description Finance PC
SW1(config-if)# switchport mode access
SW1(config-if)# switchport access vlan 20
SW1(config-if)# switchport nonegotiate
SW1(config-if)# spanning-tree portfast
SW1(config-if)# spanning-tree bpduguard enable

! Configure trunk to router
SW1(config)# interface GigabitEthernet0/1
SW1(config-if)# description Trunk to Router R1
SW1(config-if)# switchport trunk encapsulation dot1q
SW1(config-if)# switchport mode trunk
SW1(config-if)# switchport trunk native vlan 999
SW1(config-if)# switchport trunk allowed vlan 10,20,99,999
SW1(config-if)# switchport nonegotiate

! Management SVI
SW1(config)# interface vlan 99
SW1(config-if)# ip address 192.168.99.2 255.255.255.0
SW1(config-if)# no shutdown
SW1(config)# ip default-gateway 192.168.99.1

Router configuration:

! Physical interface — no IP address on physical, just bring it up
R1(config)# interface GigabitEthernet0/0
R1(config-if)# description Trunk to SW1
R1(config-if)# no ip address
R1(config-if)# no shutdown

! Subinterface for VLAN 10
R1(config)# interface GigabitEthernet0/0.10
R1(config-subif)# description Engineering VLAN
R1(config-subif)# encapsulation dot1Q 10
R1(config-subif)# ip address 192.168.10.1 255.255.255.0

! Subinterface for VLAN 20
R1(config)# interface GigabitEthernet0/0.20
R1(config-subif)# description Finance VLAN
R1(config-subif)# encapsulation dot1Q 20
R1(config-subif)# ip address 192.168.20.1 255.255.255.0

! Subinterface for Management VLAN
R1(config)# interface GigabitEthernet0/0.99
R1(config-subif)# description Management VLAN
R1(config-subif)# encapsulation dot1Q 99
R1(config-subif)# ip address 192.168.99.1 255.255.255.0

! Note: no subinterface for native VLAN 999 — that VLAN is unused
! If you need to route native VLAN traffic, use:
! encapsulation dot1Q 999 native
! But best practice is to leave the native VLAN unused and unrouted.

Verification on the router:

R1# show ip interface brief

Interface                  IP-Address      OK? Method Status   Protocol
GigabitEthernet0/0         unassigned      YES unset  up       up
GigabitEthernet0/0.10      192.168.10.1    YES manual up       up
GigabitEthernet0/0.20      192.168.20.1    YES manual up       up
GigabitEthernet0/0.99      192.168.99.1    YES manual up       up

Test inter-VLAN routing from a host:

PC1> ping 192.168.20.10
Sending 5, 100-byte ICMP Echos to 192.168.20.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/2/3 ms

RoaS limitations: Every packet traveling between VLANs crosses the trunk link twice (once from source, once back to destination). The trunk becomes a bottleneck. Router CPU handles all routing decisions in software on older platforms (though modern routers use hardware forwarding for common patterns). RoaS is appropriate for labs, small networks with low inter-VLAN traffic volume, and scenarios where you cannot afford a Layer 3 switch.

Method 3: Layer 3 Switch with SVIs

A Layer 3 (multilayer) switch has hardware-based routing capabilities. It can route packets between VLANs at wire speed — no traffic needs to leave the switch to reach a router. The Layer 3 switch creates a Switched Virtual Interface (SVI) for each VLAN. An SVI is a virtual Layer 3 interface associated with a VLAN: it has an IP address, acts as the default gateway for hosts in that VLAN, and participates in the switch’s routing table.

Topology:
                    +------------------+
                    |   Layer 3 Switch |
                    |   (Core-SW1)     |
                    |                  |
                    | SVI10: .1/24     |
                    | SVI20: .1/24     |
                    | SVI99: .1/24     |
                    |                  |
                    | ip routing       |
                    +--+-------+-------+
                       |       |
                 trunk |       | trunk
                       |       |
              +--------+--+   +--+--------+
              | Access-SW1 |   | Access-SW2|
              +------------+   +-----------+
              |    |            |    |
           Fa0/1 Fa0/2       Fa0/3 Fa0/4
           V10  V20           V10  V20
            |    |             |    |
          [PC1][PC2]         [PC3][PC4]

Layer 3 switch configuration:

! Enable Layer 3 routing on the switch
Core-SW1(config)# ip routing

! Create VLANs
Core-SW1(config)# vlan 10
Core-SW1(config-vlan)# name Engineering
Core-SW1(config)# vlan 20
Core-SW1(config-vlan)# name Finance
Core-SW1(config)# vlan 99
Core-SW1(config-vlan)# name Management
Core-SW1(config)# vlan 999
Core-SW1(config-vlan)# name NativeVLAN_Unused

! Create SVIs (the inter-VLAN routing interfaces)
Core-SW1(config)# interface vlan 10
Core-SW1(config-if)# description Engineering VLAN Gateway
Core-SW1(config-if)# ip address 192.168.10.1 255.255.255.0
Core-SW1(config-if)# no shutdown

Core-SW1(config)# interface vlan 20
Core-SW1(config-if)# description Finance VLAN Gateway
Core-SW1(config-if)# ip address 192.168.20.1 255.255.255.0
Core-SW1(config-if)# no shutdown

Core-SW1(config)# interface vlan 99
Core-SW1(config-if)# description Management VLAN
Core-SW1(config-if)# ip address 192.168.99.1 255.255.255.0
Core-SW1(config-if)# no shutdown

! Configure trunk links to access layer switches
Core-SW1(config)# interface GigabitEthernet1/0/23
Core-SW1(config-if)# description Trunk to Access-SW1
Core-SW1(config-if)# switchport trunk encapsulation dot1q
Core-SW1(config-if)# switchport mode trunk
Core-SW1(config-if)# switchport trunk native vlan 999
Core-SW1(config-if)# switchport trunk allowed vlan 10,20,99,999
Core-SW1(config-if)# switchport nonegotiate

Core-SW1(config)# interface GigabitEthernet1/0/24
Core-SW1(config-if)# description Trunk to Access-SW2
Core-SW1(config-if)# switchport trunk encapsulation dot1q
Core-SW1(config-if)# switchport mode trunk
Core-SW1(config-if)# switchport trunk native vlan 999
Core-SW1(config-if)# switchport trunk allowed vlan 10,20,99,999
Core-SW1(config-if)# switchport nonegotiate

Access-SW1 configuration:

! VTP transparent so it manages its own VLAN database
Access-SW1(config)# vtp mode transparent

! Create VLANs locally
Access-SW1(config)# vlan 10
Access-SW1(config-vlan)# name Engineering
Access-SW1(config)# vlan 20
Access-SW1(config-vlan)# name Finance
Access-SW1(config)# vlan 99
Access-SW1(config-vlan)# name Management
Access-SW1(config)# vlan 999
Access-SW1(config-vlan)# name NativeVLAN_Unused

! Access ports
Access-SW1(config)# interface FastEthernet0/1
Access-SW1(config-if)# description PC1 - Engineering
Access-SW1(config-if)# switchport mode access
Access-SW1(config-if)# switchport access vlan 10
Access-SW1(config-if)# switchport nonegotiate
Access-SW1(config-if)# spanning-tree portfast
Access-SW1(config-if)# spanning-tree bpduguard enable

Access-SW1(config)# interface FastEthernet0/2
Access-SW1(config-if)# description PC2 - Finance
Access-SW1(config-if)# switchport mode access
Access-SW1(config-if)# switchport access vlan 20
Access-SW1(config-if)# switchport nonegotiate
Access-SW1(config-if)# spanning-tree portfast
Access-SW1(config-if)# spanning-tree bpduguard enable

! Trunk uplink to Core-SW1
Access-SW1(config)# interface GigabitEthernet0/1
Access-SW1(config-if)# description Trunk to Core-SW1
Access-SW1(config-if)# switchport trunk encapsulation dot1q
Access-SW1(config-if)# switchport mode trunk
Access-SW1(config-if)# switchport trunk native vlan 999
Access-SW1(config-if)# switchport trunk allowed vlan 10,20,99,999
Access-SW1(config-if)# switchport nonegotiate

! Management SVI (no routing — just a management interface)
Access-SW1(config)# interface vlan 99
Access-SW1(config-if)# ip address 192.168.99.10 255.255.255.0
Access-SW1(config-if)# no shutdown
Access-SW1(config)# ip default-gateway 192.168.99.1

The critical command that most people forget: ip routing on the Core switch. Without it, the switch builds no routing table and cannot forward packets between SVIs. The SVIs come up with IP addresses, but no routing occurs. If hosts in VLAN 10 can reach the VLAN 10 SVI gateway (they can ping 192.168.10.1) but cannot reach hosts in VLAN 20, the first thing to check is show ip routing on the core switch.

Verification:

Core-SW1# show ip route

Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, ...

Gateway of last resort is not set

C    192.168.10.0/24 is directly connected, Vlan10
C    192.168.20.0/24 is directly connected, Vlan20
C    192.168.99.0/24 is directly connected, Vlan99

Core-SW1# show interfaces vlan 10

Vlan10 is up, line protocol is up
  Hardware is EtherSVI, address is 0011.2233.4400
  Description: Engineering VLAN Gateway
  Internet address is 192.168.10.1/24
  MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  ...

An SVI’s line protocol only comes up if at least one access or trunk port in that VLAN is in the Forwarding state. If all access ports in VLAN 10 are down or err-disabled, the VLAN 10 SVI line protocol goes down, and routing for that VLAN stops working.

Comparing the Three Methods

Criteria Legacy (1 interface per VLAN) Router-on-a-Stick L3 Switch SVIs
Scalability Very poor Limited (~50 VLANs practical max) Excellent (hardware-based)
Hardware requirement Router with many interfaces Router + L2 switch L3 switch
Throughput Limited by router Limited by router + trunk BW Wire speed (hardware CEF)
Failure domain Per physical link Single trunk is a bottleneck Routing is local to switch
Cost High (many cables/interfaces) Low (one cable) Moderate to high (L3 switch cost)
Appropriate for Legacy reference only Labs, small networks Production environments

10. Voice VLANs

How Cisco IP Phones Work

A Cisco IP phone contains a small integrated 3-port switch with three logical ports:

  1. Uplink port — connects to the wall switch. This is a trunk-capable port that carries both tagged voice frames (VLAN X) and untagged data frames.
  2. PC port — a pass-through port for a connected PC or workstation. The PC sees an untagged access port and has no knowledge of VLANs.
  3. Internal port — the phone’s own voice interface.

When you configure a switch port with both a data VLAN and a voice VLAN:

Switch(config)# interface FastEthernet0/5
Switch(config-if)# description IP Phone + PC
Switch(config-if)# switchport mode access
Switch(config-if)# switchport access vlan 10
Switch(config-if)# switchport voice vlan 100
Switch(config-if)# switchport nonegotiate
Switch(config-if)# spanning-tree portfast

The switch does the following:

  • Assigns the port to VLAN 10 for data traffic (untagged frames from the PC, passed through the phone’s PC port).
  • Assigns VLAN 100 as the voice VLAN. The switch tells the phone which VLAN to use via CDP (or LLDP-MED for non-Cisco phones).
  • The phone tags its own voice traffic with VLAN 100, CoS value 5.
  • The PC’s traffic passes through the phone untagged and the switch places it in VLAN 10.

The MAC address table on the switch will show two entries for this port: the phone’s MAC in VLAN 100 and the PC’s MAC in VLAN 10, both on the same physical interface.

CDP and LLDP-MED for Phone Provisioning

Cisco IP phones use CDP to discover their voice VLAN. The switch sends CDP advertisements that include the voice VLAN ID. The phone reads this and begins tagging its RTP and SIP traffic with that VLAN.

For non-Cisco phones, LLDP-MED (Media Endpoint Discovery) serves the same function. LLDP-MED extends the standard LLDP protocol with network policy TLVs (Type-Length-Values) that communicate VLAN ID, Layer 2 priority (CoS), and DSCP values to endpoints.

! Enable CDP globally (usually on by default)
Switch(config)# cdp run

! Enable LLDP for non-Cisco phones
Switch(config)# lldp run
Switch(config)# interface FastEthernet0/5
Switch(config-if)# lldp transmit
Switch(config-if)# lldp receive

If CDP or LLDP is disabled and the phone does not receive a voice VLAN advertisement, the phone may send all traffic untagged. Voice traffic ends up in the data VLAN, QoS markings are lost, and call quality degrades unpredictably.

QoS Markings for Voice

Voice traffic is extremely sensitive to delay, jitter, and packet loss. Standard practice:

Traffic Type Layer 2 CoS Layer 3 DSCP
Voice bearer (RTP) CoS 5 EF (Expedited Forwarding, DSCP 46)
Voice signaling (SIP, SCCP) CoS 3 CS3 (DSCP 24)
Data CoS 0 Default (DSCP 0)

The auto qos voip cisco-phone command on a Cisco switch interface automatically configures trust for CoS markings from a Cisco IP phone and applies appropriate QoS policies:

Switch(config-if)# auto qos voip cisco-phone

This generates a significant amount of QoS policy-map and class-map configuration automatically. Review what it creates with show running-config before applying it in production, because it affects the entire port’s QoS behavior.

Verification

Switch# show interfaces FastEthernet0/5 switchport

Name: Fa0/5
Switchport: Enabled
Administrative Mode: static access
Operational Mode: static access
Access Mode VLAN: 10 (Engineering)
Trunking Native Mode VLAN: 1 (default)
Voice VLAN: 100                          ! Voice VLAN assigned here
...

Switch# show mac address-table interface FastEthernet0/5

Vlan    Mac Address       Type        Ports
----    -----------       --------    -----
  10    aabb.cc11.2233    DYNAMIC     Fa0/5   ! PC's MAC in data VLAN
 100    aabb.cc44.5566    DYNAMIC     Fa0/5   ! Phone's MAC in voice VLAN

Switch# show cdp neighbors FastEthernet0/5 detail | include VLAN
  Native VLAN  : 10
  Voice VLAN   : 100

11. Management VLAN Best Practices

Dedicated Management VLAN

Do not use VLAN 1 for management. VLAN 1 is the default and is therefore the most commonly targeted. Use a separate, non-obvious VLAN ID for management traffic. Common choices are VLAN 99, 999, or 1000 — but the specific number is less important than the principle of separation.

Every switch should have exactly one management SVI with a specific IP address for SSH access:

! On every switch in the network
Switch(config)# interface vlan 99
Switch(config-if)# description Management SVI
Switch(config-if)# ip address 192.168.99.X 255.255.255.0
Switch(config-if)# no shutdown

! Default gateway for management traffic (on L2 switches)
Switch(config)# ip default-gateway 192.168.99.1

Restricting Management Access

Never leave VTY lines open to all VLANs. Apply an access-class ACL to restrict which source addresses can SSH to the switch:

! Define which hosts/networks can manage this switch
Switch(config)# ip access-list standard MGMT_ACCESS
Switch(config-std-nacl)# permit 192.168.99.0 0.0.0.255
Switch(config-std-nacl)# permit 10.0.100.0 0.0.0.255
Switch(config-std-nacl)# deny any log

! Apply to VTY lines
Switch(config)# line vty 0 4
Switch(config-line)# transport input ssh
Switch(config-line)# access-class MGMT_ACCESS in
Switch(config-line)# exec-timeout 10 0
Switch(config-line)# login local

! Enable SSH (requires hostname and domain name to generate RSA key)
Switch(config)# hostname Core-SW1
Switch(config)# ip domain-name corp.local
Switch(config)# crypto key generate rsa modulus 2048
Switch(config)# ip ssh version 2
Switch(config)# ip ssh time-out 60
Switch(config)# ip ssh authentication-retries 3

Key configuration points:

  • transport input ssh — Allows only SSH on VTY lines. Telnet is disabled. SSH encrypts the session; Telnet sends credentials in cleartext.
  • access-class MGMT_ACCESS in — Only source IP addresses matching the ACL can establish SSH sessions. An attacker on VLAN 10 cannot SSH to the management SVI even if they can reach it at Layer 3.
  • exec-timeout 10 0 — Idle sessions terminate after 10 minutes. Prevents abandoned sessions from consuming VTY lines.
  • login local — Authenticate against local username/password database. In production, this is typically replaced by RADIUS or TACACS+ via the aaa new-model framework.

12. Troubleshooting VLANs and Trunks

Systematic troubleshooting saves time. The following checklist covers the most common failure modes in order of frequency.

Complete Troubleshooting Checklist

Step 1: Verify the VLAN exists and is active.

Switch# show vlan brief

VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Gi0/1
10   Engineering                      active    Fa0/1, Fa0/2
20   Finance                          active    Fa0/3
99   Management                       active
999  NativeVLAN_Unused                active

Check: Is the VLAN in the database? Is its status active? If the VLAN is missing entirely, someone deleted it, VTP wiped it, or you are on the wrong switch. If the status is act/unsup, it is a reserved legacy VLAN.

Trunk ports will not appear in the Ports column. That is normal. If an access port is missing from the expected VLAN, it is either assigned to a different VLAN or is shut down.

Step 2: Verify the access port configuration.

Switch# show interfaces FastEthernet0/1 switchport

Name: Fa0/1
Switchport: Enabled
Administrative Mode: static access
Operational Mode: static access           ! Must match admin mode
Access Mode VLAN: 10 (Engineering)        ! Correct VLAN?
Trunking Native Mode VLAN: 1 (default)
Voice VLAN: none
Negotiation of Trunking: Off              ! DTP disabled

If Administrative Mode is static access but Operational Mode is trunk, a device on the other end is forcing a trunk via DTP. If the VLAN name shows (Inactive) instead of the VLAN name, the VLAN does not exist in the database.

Step 3: Verify trunk status and contents.

Switch# show interfaces trunk

Port        Mode         Encapsulation  Status        Native vlan
Gi0/1       on           802.1q         trunking      999   ! Correct?

Port        Vlans allowed on trunk
Gi0/1       10,20,99,999

Port        Vlans allowed and active in management domain
Gi0/1       10,20,99,999                 ! Is your VLAN here?

Port        Vlans in spanning-tree forwarding state and not pruned
Gi0/1       10,20,99,999                 ! Is your VLAN here?

If a VLAN appears in “allowed on trunk” but not in “allowed and active in management domain”: the VLAN does not exist in the VLAN database on this switch. Create it with vlan X.

If a VLAN appears in “allowed and active in management domain” but not in “spanning-tree forwarding state and not pruned”: STP has blocked this VLAN on this port, or VTP pruning has removed it.

If the Status column shows not-trunking: mode mismatch between the two ends. One side may be in access mode.

Step 4: Check for native VLAN mismatches.

! Look for CDP warnings in the log
Switch# show log | include NATIVE_VLAN
%CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on 
GigabitEthernet0/1 (999), with Core-SW1 GigabitEthernet1/0/23 (1).

If you see this message, one side of the trunk has a different native VLAN configured. Fix the side that is wrong: switchport trunk native vlan 999.

Step 5: Check STP state.

Switch# show spanning-tree vlan 10

VLAN0010
  Spanning tree enabled protocol ieee
  Root ID    Priority    32778
             Address     0011.2233.4400
             ...
  Bridge ID  Priority    32778
             ...
Interface           Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- --------
Fa0/1               Desg FWD 19        128.1    P2p
Gi0/1               Root FWD 4         128.25   P2p Peer(STP)

All ports should be in FWD (Forwarding) state for traffic to flow. If a port is in BLK (Blocking), it is intentionally blocked by STP due to a loop. If a port is in ERR (Error Disabled), check:

Switch# show interfaces FastEthernet0/1 status
Port    Name              Status       Vlan  Duplex Speed Type
Fa0/1               err-disabled    10    auto   auto  10/100BaseTX

Find the err-disable reason:

Switch# show interfaces FastEthernet0/1
...
  err-disabled
...
Switch# show errdisable recovery
ErrDisable Reason          Timer Status    Timer Interval
-----------------          -------------- --------------
bpduguard                  Enabled        300
...

If bpduguard triggered, someone connected a switch to what the access port thought was an end-device port. Remove the offending device, then recover: shutdown followed by no shutdown on the interface.

Step 6: Verify inter-VLAN routing on the core switch.

! Is routing enabled?
Core-SW1# show ip routing
IP routing table version 23, using 1000 bytes of memory
Codes: ...

C    192.168.10.0/24 is directly connected, Vlan10
C    192.168.20.0/24 is directly connected, Vlan20

! If 'show ip routing' returns "IP routing is not configured"
! then ip routing was never enabled:
Core-SW1(config)# ip routing

! Is each SVI up?
Core-SW1# show interfaces vlan 10
Vlan10 is up, line protocol is up
! If line protocol is down, no active ports exist in VLAN 10.
! Check: show vlan brief, verify at least one Forwarding access port in VLAN 10.

Step 7: Test connectivity progressively.

! From PC1 (192.168.10.10), test local gateway first
PC1> ping 192.168.10.1
! Success: Layer 2 and SVI are working in VLAN 10.
! Failure: Layer 2 issue in VLAN 10 (access port, trunk, VLAN database).

! Test remote VLAN gateway
PC1> ping 192.168.20.1
! Success: Inter-VLAN routing is working.
! Failure: Check ip routing on core switch, check VLAN 20 SVI.

! Test remote host
PC1> ping 192.168.20.10
! Success: Full path is working.
! Failure: Remote host's default gateway misconfigured, or VLAN 20 issue.

Common Mistakes Summary

Symptom Likely Cause Fix
Host cannot reach its own gateway VLAN not in database, wrong VLAN on access port show vlan brief, show interfaces switchport
Host cannot reach hosts in other VLAN ip routing not enabled on L3 switch ip routing
SVI line protocol down No active/forwarding port in that VLAN Add/fix an access port in the VLAN
VLAN missing from “active in management domain” VLAN not in VLAN database on this switch vlan X in config
Trunk shows not-trunking Mode mismatch between trunk endpoints Match both ends to switchport mode trunk
Native VLAN mismatch Different native VLAN on each end of trunk switchport trunk native vlan X (match both sides)
Traffic appears in wrong VLAN Native VLAN mismatch, see above As above
DTP negotiation forming unexpected trunk DTP active on port switchport nonegotiate + hardcode mode
VLANs disappeared from all switches VTP revision number bomb Set VTP transparent, recreate VLANs, reset revision
Port is err-disabled BPDUguard triggered (switch connected to access port), or other guard Remove offending device, shut/no shut the port
Management SSH unreachable after VLAN change Management VLAN removed from trunk allowed list switchport trunk allowed vlan add 99

Complete Multi-Switch Reference Configuration

The following is a complete annotated configuration for a three-switch topology: two access layer switches and one core Layer 3 switch. This uses SVIs for inter-VLAN routing. A router-on-a-stick alternative is shown in Section 9.

Topology summary:
  Core-SW1 (Layer 3): Gi1/0/23 -> Access-SW1, Gi1/0/24 -> Access-SW2
  Access-SW1: Fa0/1-Fa0/12 Engineering, Fa0/13-Fa0/24 Finance, Gi0/1 trunk to Core
  Access-SW2: Fa0/1-Fa0/12 Engineering, Fa0/13-Fa0/24 Finance, Gi0/1 trunk to Core
  
  VLANs:
    10  Engineering  192.168.10.0/24  gateway .1
    20  Finance      192.168.20.0/24  gateway .1
    99  Management   192.168.99.0/24  gateway .1
    999 NativeVLAN_Unused (no hosts, no routing)

Core-SW1:

hostname Core-SW1
!
! Disable VTP propagation
vtp mode transparent
!
! VLAN definitions
vlan 10
 name Engineering
vlan 20
 name Finance
vlan 99
 name Management
vlan 999
 name NativeVLAN_Unused
!
! Enable Layer 3 routing
ip routing
!
! SVIs for inter-VLAN routing
interface Vlan10
 description Engineering Gateway
 ip address 192.168.10.1 255.255.255.0
 no shutdown
!
interface Vlan20
 description Finance Gateway
 ip address 192.168.20.1 255.255.255.0
 no shutdown
!
interface Vlan99
 description Management
 ip address 192.168.99.1 255.255.255.0
 no shutdown
!
! Trunk to Access-SW1
interface GigabitEthernet1/0/23
 description Trunk-to-Access-SW1
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport trunk native vlan 999
 switchport trunk allowed vlan 10,20,99,999
 switchport nonegotiate
 no shutdown
!
! Trunk to Access-SW2
interface GigabitEthernet1/0/24
 description Trunk-to-Access-SW2
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport trunk native vlan 999
 switchport trunk allowed vlan 10,20,99,999
 switchport nonegotiate
 no shutdown
!
! SSH management
ip domain-name corp.local
crypto key generate rsa modulus 2048
ip ssh version 2
ip ssh time-out 60
ip ssh authentication-retries 3
!
username admin privilege 15 secret 0 StrongPassword!
!
ip access-list standard MGMT_ACCESS
 permit 192.168.99.0 0.0.0.255
 deny   any log
!
line vty 0 4
 login local
 transport input ssh
 access-class MGMT_ACCESS in
 exec-timeout 10 0

Access-SW1:

hostname Access-SW1
!
vtp mode transparent
!
vlan 10
 name Engineering
vlan 20
 name Finance
vlan 99
 name Management
vlan 999
 name NativeVLAN_Unused
!
! Engineering access ports
interface range FastEthernet0/1-12
 description Engineering-PC
 switchport mode access
 switchport access vlan 10
 switchport nonegotiate
 spanning-tree portfast
 spanning-tree bpduguard enable
 no shutdown
!
! Finance access ports
interface range FastEthernet0/13-24
 description Finance-PC
 switchport mode access
 switchport access vlan 20
 switchport nonegotiate
 spanning-tree portfast
 spanning-tree bpduguard enable
 no shutdown
!
! Trunk uplink to Core-SW1
interface GigabitEthernet0/1
 description Trunk-to-Core-SW1
 switchport trunk encapsulation dot1q
 switchport mode trunk
 switchport trunk native vlan 999
 switchport trunk allowed vlan 10,20,99,999
 switchport nonegotiate
 no shutdown
!
! Management SVI
interface Vlan99
 description Management
 ip address 192.168.99.10 255.255.255.0
 no shutdown
!
ip default-gateway 192.168.99.1
!
ip ssh version 2
!
line vty 0 4
 login local
 transport input ssh
 exec-timeout 10 0

Access-SW2 follows the same pattern as Access-SW1 with a different management IP (192.168.99.11).

Final Notes

VLANs and trunking are foundational. Almost everything else in enterprise switching — spanning tree, EtherChannel, QoS, security policies — assumes you understand how the VLAN boundary works and how trunk links carry tagged frames between switches. The material in this post maps directly to the CCNA 200-301 exam objectives under “Network Access” but extends well beyond exam depth in several areas (VTP revision bombing, double-tagging attack mechanics, SVIs going down when VLANs lose their last active port).

The single most important operational habit to develop: hard-code everything. Hard-code access ports as access, trunk ports as trunk, disable DTP on all of them, change the native VLAN away from VLAN 1, and restrict trunk allowed VLAN lists to only what each trunk needs to carry. These five practices close the majority of common VLAN security and reliability issues before they become incidents.

Comments