VLANs create separate Layer 2 broadcast domains, which is useful for segmentation but also means hosts in different VLANs cannot communicate without a Layer 3 function. A multilayer switch provides that function by using switched virtual interfaces (SVIs) as routed gateways for VLANs. When ip routing is enabled and the relevant VLAN interfaces are operational, the switch can route directly between connected VLAN prefixes without sending the traffic to an external router-on-a-stick link.
Within Inter-VLAN Routing with Layer 3 Switches, the current 200-301 CCNA v1.1 exam includes VLANs, trunks, IPv4/IPv6 addressing, and routing fundamentals that come together in inter-VLAN routing. The key is to reason through the packet twice: first as an Ethernet frame entering the source VLAN, then as a routed IP packet that leaves through the destination VLAN with a new Layer 2 header.
Start with the Layer 2 separation that makes routing necessary
Hosts in the same VLAN share a Layer 2 broadcast domain and can normally resolve each other directly using ARP for IPv4 or Neighbor Discovery for IPv6. Hosts in different VLANs are separated at Layer 2 even if they are connected to the same physical switch. A frame from VLAN 10 is not simply flooded into VLAN 20.
When a host determines that the destination is outside its local IP subnet, it sends the frame to its configured default gateway. On a multilayer switch, that gateway is commonly the SVI address for the host’s VLAN. The switch receives the frame as the Layer 3 gateway, looks up the destination IP prefix, and routes the packet toward the destination VLAN.
The VLAN remains a Layer 2 construct; the SVI is the Layer 3 interface associated with it. Keeping those roles separate makes many campus problems easier to diagnose.
A host’s ARP table provides a useful clue about whether routing is occurring. For an off-subnet destination, the host should resolve the MAC address of its default gateway, not the remote host. If a capture shows the host ARPing directly for an address that should be remote, the subnet mask is probably wrong. This endpoint evidence can resolve an apparent inter-VLAN routing problem before an engineer touches the switch configuration.
Create an SVI for each routed VLAN that needs a gateway
An SVI is configured as an interface VLAN and assigned an IP address and prefix. That address often becomes the default gateway used by endpoints in the VLAN. The SVI can also participate in routing protocols, ACLs, DHCP relay, first-hop redundancy, and other Layer 3 features supported by the platform.
The SVI’s line protocol depends on the VLAN and switching state. A perfectly written interface vlan 20 configuration may remain down if VLAN 20 does not exist, is suspended, or has no active Layer 2 port in the conditions required by the platform. Troubleshooting should therefore check VLAN existence and port/trunk state rather than focusing only on the SVI configuration.
Gateway addressing must match the host subnet. The subnet size for each VLAN should be chosen deliberately so hosts, DHCP scopes, SVI addresses, and route advertisements all agree.
SVI state can depend on autostate behavior and active Layer 2 membership. During staged deployment, an SVI may remain down until at least one associated access or trunk port is operational for that VLAN. This is useful because a routed interface should not normally advertise a connected network that has no active Layer 2 presence, but it can confuse engineers who create the SVI first. Verify platform-specific SVI state rules during deployment and troubleshooting.
Enable Layer 3 forwarding on a multilayer switch
On platforms that support multilayer routing, ip routing enables IPv4 forwarding between Layer 3 interfaces. Without routing enabled, multiple SVIs may exist for management or limited functions without the switch acting as a normal IPv4 router between them. The exact defaults and commands can vary by platform and software release, so confirm the current device behavior.
Once routing is active, connected routes for operational SVIs appear in the routing table. A packet from VLAN 10 destined for a host in connected VLAN 20 can be routed directly: the switch removes the incoming Ethernet header, decrements the IP TTL, performs the route lookup, resolves the destination host in VLAN 20, and builds a new Ethernet frame for the egress port.
This is hardware-forwarded at high speed on modern multilayer switches, which is why campus designs commonly route at the distribution or access layer instead of forcing every inter-VLAN packet through a separate router.
Connected routes from SVIs are only the start of the routing table. If VLAN 10 must reach a data center prefix, the multilayer switch needs a static or dynamic route beyond its connected networks. Conversely, upstream routers need a return path to the campus VLANs. Testing only VLAN 10 to VLAN 20 proves local inter-VLAN routing, not end-to-end reachability to remote networks.
Keep trunks and VLAN membership correct across the Layer 2 path
Inter-VLAN routing cannot repair a missing VLAN on the access path. The source host must actually enter the expected VLAN, and trunks must carry that VLAN wherever the design requires Layer 2 extension. If a user port is accidentally in VLAN 30 while its DHCP scope and gateway belong to VLAN 20, the routing table may look healthy while the endpoint fails.
Verify access VLAN assignment, trunk mode, allowed VLAN lists, native VLAN expectations, and STP state. A VLAN can be present on one switch and absent or pruned on the next. The SVI may be up on the gateway switch while a remote access switch cannot reach it because the trunk does not carry the VLAN.
Use the Layer 2 topology diagram alongside the Layer 3 prefix plan. The routing function begins only after the frame reaches the correct gateway SVI.
Trunk pruning can be intentional. In a hierarchical campus, not every VLAN should span every trunk, and limiting VLAN propagation can reduce unnecessary Layer 2 scope. The mistake is allowing the physical topology and the VLAN reachability plan to drift apart. Keep the allowed-VLAN list derived from documented service placement so an operator can distinguish a deliberate prune from an accidental omission.
Compare multilayer switching with router-on-a-stick
Router-on-a-stick uses one physical router link configured as an 802.1Q trunk with multiple Layer 3 subinterfaces. Each subinterface represents a VLAN gateway. The model is easy to visualize and useful in small networks or labs, but all inter-VLAN traffic crosses the shared physical router link.
A multilayer switch routes between SVIs internally and can provide far more aggregate bandwidth for campus VLANs. It also places routing close to the switching fabric. The tradeoff is that the switch becomes part of the Layer 3 design and must be managed with routing, redundancy, ACL, and control-plane considerations rather than as a purely Layer 2 device.
The right model depends on scale, platform roles, fault domains, and operational standards. The CCNA objective is to understand how both perform the same logical function: provide Layer 3 gateways for multiple VLANs.
Router-on-a-stick also introduces a failure and capacity dependency on the trunk and router interface. A single physical failure can remove every VLAN gateway carried by that link. A multilayer switch may provide better local resilience and throughput, but it can also concentrate many gateways on one chassis. Compare the failure domains rather than assuming the higher-performance design is automatically the more available design.
Apply policy at the routed boundary without confusing it with segmentation
VLAN separation does not automatically mean security isolation. Once a multilayer switch routes between connected VLANs, traffic can flow unless ACLs, firewalls, VRFs, or other policy restrict it. Treat the SVI boundary as a convenient enforcement point, not as proof that two user groups are isolated.
SVI ACLs can filter traffic, but direction matters. An inbound ACL on a source VLAN sees packets as they enter the Layer 3 interface; an outbound ACL on a destination SVI sees packets after the route decision. Document policy intent in terms of sources, destinations, and applications rather than building an unmaintainable collection of exceptions.
For stronger segmentation, private VLANs, VRFs, firewalls, or software-defined policy may be more appropriate. VLANs organize Layer 2 domains; security architecture decides what communication should be allowed between them.
Policy can be applied with routed ACLs, but some traffic may bypass the expected SVI if the topology includes bridges, overlays, service appliances, or host-local communication. Security design should define where enforcement is authoritative. If a firewall is the required policy boundary, routing every sensitive VLAN directly on a campus switch may create a path that never reaches the firewall unless VRF or route design deliberately steers it there.
Add resilient gateways without creating a new single point of failure
If one multilayer switch owns every SVI gateway, a switch failure removes inter-VLAN routing for all attached VLANs. Campus designs often deploy redundant Layer 3 switches and use a first-hop redundancy protocol for shared gateway addresses. The hosts keep a stable gateway while the active routing device can change.
Redundancy must extend beyond the virtual gateway. Both switches need appropriate VLAN reachability, upstream routes, policies, DHCP relay, and capacity. A backup gateway that cannot reach the WAN or data center is not a useful backup. Align Layer 2 and Layer 3 redundancy so failover does not create unnecessary hairpin paths.
The broader campus concepts in 350-401 ENCOR help connect inter-VLAN routing to high availability, routing protocols, and scalable enterprise topology.
First-hop redundancy pairs should use consistent gateway addressing and service configuration. DHCP relay, ACLs, QoS, multicast settings, and routing should not exist only on the currently active switch. A failover test that verifies only ping to the virtual gateway can miss missing helper addresses or policy on the standby. Validate representative applications after failover so the redundant gateway is proven to provide equivalent service, not just ICMP reachability.
Troubleshoot from the host toward the routing table
On the host, verify IP address, prefix length, VLAN attachment, and default gateway. Then verify the gateway SVI is up/up and uses an address in the same subnet. Check that the VLAN exists and that the access or trunk path can actually reach the gateway switch. Ping the gateway before testing a remote VLAN.
On the switch, inspect connected routes and ARP or neighbor entries. If the destination VLAN is connected, confirm its SVI is up and that the destination host is reachable in that VLAN. If the destination is remote, follow the routing table and return path. The 300-410 ENARSI troubleshooting mindset is useful: determine whether failure is Layer 2, local Layer 3, policy, or upstream routing before changing configuration.
Packet captures at the source and destination VLANs can confirm whether the switch is routing and rewriting frames as expected. That evidence is more useful than repeatedly bouncing interfaces.
A useful troubleshooting split is source VLAN, routing decision, and destination VLAN. Prove the source frame reaches the SVI; prove the route points to the expected connected or remote prefix; then prove the destination SVI or next hop can resolve and forward the packet. This prevents teams from bouncing trunks because a route is missing, or changing routes because an access port is assigned to the wrong VLAN.
Design VLANs, prefixes, and routing as one system
Change validation should include traffic in both directions and at least one flow that crosses a security or service dependency such as DNS, DHCP, or a firewall. A simple ping from one SVI to another proves only that the switch can route between its own interface addresses. A client-to-server test verifies endpoint masks, ARP, access VLANs, gateway selection, policy, and return routing together.
Keep VLAN IDs, names, IP prefixes, gateway addresses, DHCP scopes, security zones, and owners in a common source of truth. When a new VLAN is created, the Layer 2 definition, SVI, address plan, DHCP relay, routing advertisement, and policy should be part of one coordinated change.
Avoid extending VLANs farther than the application or mobility requirement demands. Large Layer 2 domains increase broadcast scope and failure impact. Routing closer to the access layer can create smaller fault domains, but it also changes where services such as DHCP relay and first-hop redundancy live. Make that boundary explicit in diagrams and operations.
Inter-VLAN routing is predictable when the design is read in sequence: the endpoint recognizes an off-subnet destination, sends to the SVI gateway, the multilayer switch selects a route, and a new frame is emitted into the destination VLAN. Every failure can be mapped to one step in that path.
Control-plane protection and management reachability should be validated after enabling many SVIs. Each new gateway can create protocol, ARP, DHCP relay, ACL, and monitoring state. Large campus switches have ample forwarding performance, but operational scale still benefits from consistent templates and sensible limits. Treat every SVI as a routed interface with ownership, policy, and telemetry rather than as a lightweight VLAN label.
Routed-access campus designs move the Layer 3 boundary closer to users and may eliminate large Layer 2 trunks between access and distribution layers. That can reduce STP dependence and fault-domain size, but it changes where VLAN gateways, DHCP relay, multicast, and policy reside. Migration should therefore update operational ownership and monitoring along with topology. The same user subnet may now fail at a different device than the support team expects from the old design.