Cisco VLAN and Inter-VLAN Routing Configuration Guide

VLAN configuration looks easy until traffic silently goes to the wrong place — which is why verification and hardening matter as much as the commands themselves. This guide walks through the complete workflow on Cisco Catalyst switches (IOS 15.x / IOS-XE 17.x): creating VLANs, assigning access ports, building 802.1Q trunks with a dedicated native VLAN, enabling ip routing, creating SVIs for inter-VLAN routing, adding DHCP pools, and finishing with security hardening. Every step includes the show commands that catch mistakes before they become outages.

VLAN and 802.1Q Fundamentals

A VLAN is a Layer 2 broadcast domain. Without it, every port on a switch is in the same domain: a single broadcast from one workstation reaches every other port, and MAC tables and Spanning Tree instances all have to cover one flat topology. Giving each department, floor or function its own VLAN shrinks failure domains, contains broadcast storms, and lets you apply policy per subnet rather than per port.

IEEE 802.1Q is what carries VLANs between switches. It inserts a 4-byte tag - a 16-bit TPID of 0x8100, a 3-bit priority field, a 1-bit Canonical Format Indicator and a 12-bit VLAN ID - immediately after the source MAC address. Because 12 bits is not enough for 4096+ values, the usable range is 1 to 4094: VLAN 1 is the default and should never carry user traffic, 1002-1005 are reserved for legacy Token Ring and FDDI, and 1006-4094 are the extended range that Cisco software only treats as normal-range-capable on newer platforms. Only the VLAN ID really matters for day-to-day operations, but the untagged "native VLAN" concept does: on a trunk, frames without a tag belong to the native VLAN on both ends, which is precisely why a mismatch there causes a silent cross-connect between two VLANs.

Port modes you will meet in this guide:

• Access - belongs to exactly one VLAN, sends untagged frames to the host, tags them internally.
• Trunk - carries multiple VLANs, tags each frame with its VLAN ID except for the native VLAN.
• Routed (Layer 3) port - no switchport turns the port into a router interface with its own IP address, no VLAN involved.

Should You Use VTP?

VLAN Trunking Protocol propagates the VLAN database across a domain (server and client modes) and can save a great deal of typing in a large campus. It also carries the most famous self-inflicted outage in Cisco switching: plug a switch with a higher configuration revision number into a server-mode domain and it overwrites every VLAN definition in the domain, deleting VLANs that are still in production. The modern recommendation is to run VTP in transparent mode - or disable it - and manage VLANs with configuration files, templates or automation instead. If you keep it, use VTP version 3 (which supports off and has additional protections), always set a domain password, and never leave a lab switch in server mode on a production trunk. The same logic applies to DTP (Dynamic Trunking Protocol): what should be a static trunk can be negotiated, and negotiation is an attack surface. Prefer switchport mode trunk plus switchport nonegotiate.

Step 1: Create the VLANs

Switch# configure terminal
Switch(config)# vlan 10
Switch(config-vlan)# name Engineering
Switch(config-vlan)# exit
Switch(config)# vlan 20
Switch(config-vlan)# name Sales
Switch(config-vlan)# exit
Switch(config)# vlan 99
Switch(config-vlan)# name Native-VLAN
Switch(config-vlan)# exit
Switch# show vlan brief

Repeat the block for each VLAN and confirm with show vlan brief, which lists every VLAN, its name, status and assigned ports. A VLAN that exists in the database but has no ports is normal at this stage - it will show as active with an empty port list. If a VLAN is missing from the output entirely on a trunking switch, the usual cause is VTP having overwritten the database, not a typo.

Step 2: Assign Access Ports

Switch(config)# interface range GigabitEthernet1/0/1 - 8
Switch(config-if-range)# switchport mode access
Switch(config-if-range)# switchport access vlan 10
Switch(config-if-range)# spanning-tree portfast
Switch(config-if-range)# no shutdown

Enable spanning-tree portfast only on ports connected to end devices — never on switch-to-switch links.

Two more details that bite in production. First, switchport mode access is not optional: a port left at the default dynamic auto can become a trunk if a neighbour negotiates one, which converts a workstation link into a VLAN-hopping path. Second, pair PortFast with BPDU Guard (spanning-tree bpduguard enable or the global spanning-tree portfast bpduguard default), otherwise an accidental loop through a wall port can take the whole access VLAN down. On ports that face an access point or a voice device, remember that a Cisco phone uses a voice VLAN trunk and needs switchport mode access plus switchport voice vlan <id>, not a manually configured trunk.

Step 3: Configure Trunk Ports

Switch(config)# interface GigabitEthernet1/0/24
Switch(config-if)# switchport trunk encapsulation dot1q
Switch(config-if)# switchport mode trunk
Switch(config-if)# switchport trunk native vlan 99
Switch(config-if)# switchport trunk allowed vlan 10,20,30,99
Switch(config-if)# no shutdown

Always set the allowed VLAN list explicitly — the default "all" is a security risk — and use a native VLAN other than 1 to mitigate VLAN hopping. Both ends must agree on encapsulation, native VLAN, and allowed VLANs.

On Catalyst 3560/3750 with classic IOS, the switchport trunk encapsulation dot1q line is required because the platform also supported ISL. On IOS-XE platforms such as the Catalyst 9300/9500/9400, 802.1Q is the only encapsulation the hardware supports and the command is rejected as unrecognised - leave it out rather than copying it from an old template. To keep the native VLAN meaningful, give it its own ID (99 here), never leave it at 1, and make sure no access port anywhere carries that native VLAN as its access VLAN, because that combination lets a host send tagged frames straight into another VLAN.

An explicit allowed list on trunks is also an operational safety net: a new VLAN created at one end does not instantly start flooding across a link that is not supposed to carry it. Add VLANs to the list deliberately, and prune stale ones with switchport trunk allowed vlan remove <id>. Verify trunks after every change:

Switch# show interfaces trunk
Switch# show interfaces GigabitEthernet1/0/24 switchport
Switch# show spanning-tree interface GigabitEthernet1/0/24

show interfaces trunk is worth reading closely: it prints Mode, Encapsulation, Status, Native VLAN, and two separate VLAN lists - the VLANs allowed on the trunk and the VLANs active and forwarding in STP. A VLAN that appears in the first list but not the second is defined but not yet active on the link, usually because STP has not converged or the VLAN exists only at one end. A native VLAN mismatch is called out explicitly in that output ("Native VLAN mismatch discovered on ..."), so there is no need to guess.

The Three Ways to Route Between VLANs

Inter-VLAN routing on a Layer 3 switch uses an SVI per VLAN. That is not the only option, and choosing the right one up front saves a redesign later:

Router-on-a-stick is still perfectly valid for a small site. The subinterface configuration is short, and it is the only option when the router, not the switch, is the default gateway:

Router(config)# interface GigabitEthernet0/0
Router(config-if)# no shutdown
Router(config)# interface GigabitEthernet0/0.10
Router(config-subif)# encapsulation dot1q 10
Router(config-subif)# ip address 10.10.10.1 255.255.255.0
Router(config-subif)# interface GigabitEthernet0/0.20
Router(config-subif)# encapsulation dot1q 20
Router(config-subif)# ip address 10.10.20.1 255.255.255.0

Whichever method you pick, hosts still need the correct default gateway. The single most common inter-VLAN failure is not a routing problem at all - it is a workstation configured with the wrong gateway, or with a static IP in the wrong subnet.

Step 4: SVIs for Inter-VLAN Routing

Switch(config)# ip routing
Switch(config)# interface vlan 10
Switch(config-if)# ip address 10.10.10.1 255.255.255.0
Switch(config-if)# no shutdown
Switch(config-if)# exit
Switch(config)# interface vlan 20
Switch(config-if)# ip address 10.10.20.1 255.255.255.0

Hosts in each VLAN use the SVI IP as their default gateway. A common mistake is forgetting ip routing — the SVIs come up but nothing routes between them.

An SVI reports up only when the VLAN is active - that is, at least one port in that VLAN is up and forwarding in STP, or a trunk is carrying it. That behaviour is a feature: it stops the switch from advertising reachability for a subnet with nothing behind it. If you need the SVI to stay up regardless (for example, on a switch that peers a routing protocol over a trunk to a remote site), some platforms support no autostate under the SVI. Check the SVI state in show ip interface brief and show interfaces vlan 10 before assuming a routing problem.

Think about the default route as well. SVIs let the switch route between VLANs, but Internet or WAN traffic still needs ip route 0.0.0.0 0.0.0.0 <next-hop> pointing at the firewall or WAN router, plus a matching route on that device back toward the VLAN subnets. A missing return route produces the classic "ping works one way" symptom.

Step 5: DHCP Pools (Optional but Recommended)

Switch(config)# ip dhcp pool VLAN10-POOL
Switch(dhcp-config)# network 10.10.10.0 255.255.255.0
Switch(dhcp-config)# default-router 10.10.10.1
Switch(dhcp-config)# dns-server 10.10.30.10
Switch(config)# ip dhcp excluded-address 10.10.10.1 10.10.10.10

Local pools are convenient but do not scale across dozens of VLANs. The standard design keeps one central DHCP server (a Windows/Linux host, an ISE deployment, or the firewall) and lets the Layer 3 switch relay client broadcasts to it with ip helper-address on each SVI:

Switch(config)# interface vlan 10
Switch(config-if)# ip helper-address 10.10.30.10
Switch(config-if)# interface vlan 20
Switch(config-if)# ip helper-address 10.10.30.10

Remember that ip helper-address relays more than DHCP: by default it also forwards UDP 69 (TFTP), 53 (DNS), 37 (time), 49 (TACACS) and 137/138 (NetBIOS), which is exactly the kind of unnecessary traffic a security review will flag. Suppress what you do not need with no ip forward-protocol udp <port>, or be explicit with ip forward-protocol udp bootps and let the default list shrink. The DHCP request arrives at the server with the SVI address as the gateway address, so the server needs a scope for every subnet it serves, and its reply has to route back to the client subnet.

Step 6: Verify and Harden

Switch# show vlan brief
Switch# show interfaces trunk
Switch# show ip interface brief
Switch# show ip route

Test inter-VLAN routing by pinging from a host in VLAN 10 to a host in VLAN 20; if it fails, check the SVI state, the host default gateway, and ip routing. Finally: shut down VLAN 1 on trunks, shut unused ports into a dead-end VLAN (e.g., VLAN 999), keep the dedicated native VLAN, and save with copy running-config startup-config.

Troubleshooting Inter-VLAN Routing

Work down this checklist when a host in one VLAN cannot reach a host in another. Each step has a command that gives a yes/no answer, which is faster than guessing.

1. Are both hosts actually in the VLANs you think? show vlan brief to confirm port membership, and check the host's IP and mask.
2. Is the SVI up and correct? show ip interface brief - look for up/up and the right address. A down SVI means no active port in that VLAN.
3. Is routing enabled? show ip route should list the connected subnets with a C flag. No connected routes means ip routing is missing.
4. Does the trunk carry both VLANs? show interfaces trunk - check the allowed and active lists, the native VLAN on both ends, and that the transit switch has the VLAN created.
5. Is the MAC learning correctly? show mac address-table vlan 10 shows where each host was last seen; a MAC that moves between two ports repeatedly points at a loop or a duplicate address.
6. Is a filter dropping it? show ip interface vlan 10 displays any inbound/outbound access list. A badly scoped ACL on an SVI is a very common cause of "it worked yesterday".
7. Is the host's gateway reachable? Ping the SVI from the host, then ping the far host from the switch with a sourced address: ping 10.10.20.50 source vlan 10.

Layer 2 Hardening Checklist

Once routing works, close the common Layer 2 attack paths. None of these commands change user behaviour, and all of them are worth having in the template:

• Kill VLAN 1 - remove it from trunks (switchport trunk allowed vlan remove 1), never use it for management or user traffic.
• Dedicated native VLAN - a VLAN ID that exists nowhere as an access VLAN, so 802.1Q double-tagging has no target.
• Disable DTP - switchport nonegotiate on every trunk.
• Shut unused ports - interface range ... shutdown, and park them in a dead-end VLAN such as 999.
• Port security - switchport port-security maximum 2 with violation restrict limits MAC flooding on access ports.
• DHCP snooping - ip dhcp snooping and ip dhcp snooping vlan 10,20, with only genuine uplinks marked trust. This stops a rogue DHCP server on a desk port.
• Dynamic ARP inspection - ip arp inspection vlan 10,20 blocks ARP spoofing and depends on the snooping bindings being populated first.
• IP Source Guard - ip verify source ties a port to the DHCP-learned address.
• Storm control - storm-control broadcast level 5 on access ports keeps a single misbehaving NIC from saturating the VLAN.
• Lock down the management SVI - its own VLAN, a standard ACL permitting only the management subnet, and line vty restricted by access-class.
• Save the configuration - copy running-config startup-config. A perfect design lost on the next reload is not a design.

VLAN Configuration FAQ

Can a Catalyst 2960 do inter-VLAN routing? No. The 2960 family is Layer 2 only - it can create VLANs and trunks, but has no routing engine. Use a 3560/3750/9300-series or an external router, and configure the 2960 as an access switch with a trunk uplink.

Why is switchport trunk encapsulation dot1q rejected? Because the platform only supports 802.1Q, so the command no longer exists in IOS-XE. Skip it; the trunk still negotiates dot1q.

How many SVIs can I configure? One per VLAN that needs routing. The limit is a licensing/platform matter, but if you find yourself creating hundreds of SVIs on one switch, a routed-access design with /31 links is usually the better architecture.

Do I need a default gateway on the switch itself? Yes, for management traffic that leaves the management subnet: ip default-gateway when routing is disabled, or a static default route when ip routing is on.

Is a trunk required between two access switches? Only if both VLANs must exist on both. If each switch serves its own VLANs, a single routed (or trunk with a transit VLAN) uplink to the distribution layer is enough.

For the Arista equivalent, see our EOS VLAN, trunk and port-channel guide; for redundancy design, the Cisco Nexus vPC failover checklist is a good next stop.

If you build your DHCP pools on a remote server instead of the switch, the steps in Cisco IP helper-address and DHCP relay cover the relay side in detail. For a native-VLAN or trunk-fault drill, see Arista EOS VLAN troubleshooting: native VLAN and trunks, and when the design moves to per-VLAN STP tuning, Cisco MST configuration: region, instance and VLAN mapping.

原文链接：https://syseng.io/blog/guide-31-vlan-configuration-cisco