What is the practical difference between router-on-a-stick and an L3 switch?

Router-on-a-stick uses one trunked physical link with tagged subinterfaces, so all inter-VLAN traffic shares that interface, while an L3 switch routes between SVIs in hardware and scales with ports and backplane.

When should I prefer a Layer 3 switch over router-on-a-stick?

Use an L3 switch when you need high east–west throughput, fast FHRP failover, or many VLANs; pick ROAS for small sites where simplicity outweighs bandwidth limits.

How do I size and assign VLAN IDs and subnets?

Map IDs to summarizable subnets (for example, VLAN 30 → 10.30.0.0/24) and verify masks before rollout with a quick Subnet Calculator so you don’t overlap networks.

Do I need trunks between access and distribution layers?

Yes; links that carry multiple VLANs must be 802.1Q trunks, with unused VLANs pruned, a non-default native VLAN set, and negotiation disabled to prevent mode flaps.

Why can’t hosts in different VLANs reach each other even though the trunk is up?

Typical causes are missing or down SVIs/subinterfaces, wrong host gateways, ACLs dropping traffic, or mismatched native VLANs redirecting untagged frames.

Where should I place ACLs to control inter-VLAN access?

Put ACLs where they block the most unwanted traffic with the fewest lines—often inbound on user SVIs for client policies and inbound on server SVIs to protect applications, with explicit permits for infra flows.

How can I validate IPv6 inter-VLAN routing end to end?

Ping between VLAN gateways with sourced IPv6 addresses, confirm neighbor tables, allow essential ICMPv6 in ACLs, and test from a client using an IPv6 Connectivity Check to catch path or firewall issues.

What’s a quick way to confirm name resolution and gateway reachability?

Check ARP/ND entries and traceroute to an upstream host, then verify DNS by querying your resolver; if needed, use a simple DNS Lookup Tool to confirm records resolve.

Inter-VLAN Routing: Router-on-a-Stick and L3 Switch Tips

Inter-VLAN routing lets isolated VLANs communicate while keeping segmentation intact, and you can implement it with either a single trunked router interface or routed SVIs on a Layer 3 switch.

Choose the model based on throughput, redundancy, and where you want policy enforced; router-on-a-stick is simple and budget-friendly, while L3 switching provides line-rate forwarding and cleaner scale.

Below we cover practical design, trunking, ACL patterns, and a step-by-step troubleshooting flow you can actually run in a change window.

Inter-VLAN Routing Basics

A VLAN is a Layer 2 broadcast domain; devices in different VLANs need a Layer 3 hop to communicate. You deliver that hop via subinterfaces on a router (router-on-a-stick, often shortened to ROAS) or by creating switch virtual interfaces (SVIs) on a Layer 3 switch. In both cases each VLAN gets a default gateway IP, and IEEE 802.1Q tags keep traffic separated across trunks. Hosts use their in-VLAN gateway; the routing device forwards across VLANs based on its forwarding table.

Router-on-a-Stick: When and How

Use ROAS for small sites with a modest number of VLANs and limited east–west traffic. You trunk a single physical link from the switch to the router, then carve per-VLAN subinterfaces. Upside: simple configuration and a clear policy point on the router. Tradeoff: all inter-VLAN traffic hairpins on one interface, so aggregate throughput is capped by the link speed and router forwarding capacity.

Sample Cisco IOS Configuration

On the access/distribution switch, define VLANs, make the uplink a trunk, prune unused VLANs, and set a non-default native VLAN. Example (condensed): vlan 10,20; interface g1/0/48; switchport mode trunk; switchport trunk allowed vlan 10,20; switchport trunk native vlan 999; spanning-tree portfast trunk (only to a router or server, not switch-to-switch); switchport nonegotiate. On the router, create subinterfaces with dot1q tags and per-VLAN gateways: interface g0/0.10 encapsulation dot1q 10 ip address 192.168.10.1 255.255.255.0; interface g0/0.20 encapsulation dot1q 20 ip address 192.168.20.1 255.255.255.0. Verify trunks on the switch with show interfaces trunk, view router subinterfaces with show ip interface brief, and ping across VLANs using a sourced address to prove Layer 3 reachability.

Layer 3 Switch: SVI-Based Routing

Use an L3 switch when you need wire-speed inter-VLAN forwarding and easy growth to many VLANs. Create one SVI per VLAN and enable routing. Minimal example: global ip routing (and ipv6 unicast-routing for IPv6), then interface vlan 10 ip address 192.168.10.1 255.255.255.0, interface vlan 20 ip address 192.168.20.1 255.255.255.0. Access ports for users/servers join the correct VLAN; the switch routes between SVIs in hardware. If DHCP lives elsewhere, add ip helper-address <server-ip> under each SVI so clients obtain leases across subnets; for IPv6 relay, use ipv6 dhcp relay destination <server-IPv6> on the client-facing SVI.

FHRP for Default Gateway Redundancy

Two L3 switches can share a virtual IP as the default gateway using first-hop redundancy protocols like HSRP or VRRP. Each SVI has a real address plus the virtual IP; if the active device fails, the standby takes over. Example on both switches: under interface vlan 10 give unique real IPs, then configure standby 10 ip 192.168.10.1 (HSRP) or vrrp 10 ip 192.168.10.1 (VRRP). Tune preemption and priorities so your preferred switch is normally active, and track uplinks so a WAN/core failure can trigger a role change.

Trunking and VLAN Design

Consistent numbering and summarizable addressing reduce cognitive load. Map VLAN IDs to matching subnets (for example, VLAN 30 → 10.30.0.0/24) so you can recognize a subnet on sight. Keep broadcast domains reasonable; /24s are easy, but size with /23 or /25 when density requires. On trunks, explicitly allow only needed VLANs, set the native VLAN to an unused ID, and disable DTP to avoid unintended negotiation. Where you bundle links, use EtherChannel/LACP, configure the trunk on the logical port-channel (not on individual members), and ensure hashing fits your flow patterns; make sure both sides match allowed/native VLANs and LACP mode.

Native VLAN, Allowed VLANs, MTU, EtherChannel

The native VLAN carries untagged frames on dot1q; leaving it at default invites confusion and can enable VLAN-hopping tricks. Pick an unused native VLAN, carry it only where necessary, and monitor for unexpected untagged traffic. Align MTU end to end if you use overlays or tunneling; a single undersized port produces silent drops and “it works but it’s slow” complaints. With EtherChannel, apply trunk config at the port-channel so all members inherit it, and check load-balancing settings so your traffic doesn’t pin to one link based on MAC/IP/port hashing.

ACLs for Inter-VLAN Policy

Inter-VLAN routing shouldn’t imply full mesh access. Use extended ACLs to admit only what’s needed. For user-to-server flows, apply ACLs closest to the source to drop early and save bandwidth; to protect servers, apply inbound on the server VLAN SVI so only permitted traffic reaches critical hosts. Order entries from most specific to least; prefer explicit application permits over broad “established” shortcuts unless your platform lacks better options. On L3 switches, define ip access-list extended NAME then apply with ip access-group NAME in on the SVI. For IPv6, use ipv6 traffic-filter NAME in and allow essential ICMPv6 (neighbor solicitation/advertisement and, when using SLAAC, router solicitation/advertisement). Some platforms implicitly permit NDP inside IPv6 ACLs, but it’s still wise to include explicit lines so future edits don’t break neighbor discovery.

Common ACL Pitfalls

Three chronic gotchas: blocking ARP or NDP (IPv6 needs ICMPv6 for neighbor discovery and Path MTU/“Packet Too Big”), applying ACLs in the wrong direction, and shadowed lines where an early broad permit/deny makes later lines useless. Always include infrastructure allowances (DHCP, DNS, management), and watch for asymmetric return paths in multi-router designs—the packet you deny on one path might be the response to a permitted flow on another.

Troubleshooting Playbook

Work bottom-up. Confirm VLAN existence and access port membership (show vlan brief), trunk state and allowed lists on both sides (show interfaces trunk), SVI/subinterface status and gateway IPs (show ip interface brief / show ipv6 interface brief), and routing entries (show ip route / show ipv6 route). From each gateway, ping across VLANs using a sourced address (ping 192.168.20.10 source 192.168.10.1) to prove Layer 3 reachability independent of hosts. Check ARP/ND tables for resolved neighbors and stale entries. If pings work but apps fail, test TCP/UDP (for example, telnet <host> 443 or platform-specific TCP tests) and review ACL hit counters.

Packet Captures and Validation

When counters don’t tell the story, capture traffic. Mirror the access port (SPAN) or use a tap to verify tags, gateways, and the three-way handshake. On routed hops, confirm TTL decrement and checksum updates to prove forwarding. Look for MTU trouble (ICMP “fragmentation needed” or IPv6 “Packet Too Big”), mismatched native VLANs (untagged frames on the wrong VLAN), or gratuitous ARP/ND storms that hint at loops.

Security Hardening Checklist

Enforce least privilege with inter-VLAN ACLs; separate user, server, and management VLANs; disable unused switchports and place them in a blackhole VLAN; enable DHCP snooping, dynamic ARP inspection, and IP source guard where supported; lock down native VLAN and disable DTP; apply PortFast only to edge links (including trunk-to-router or to virtualization hosts) and never on switch-to-switch trunks; prefer FHRP authentication; rate-limit control-plane traffic and log; keep a gold baseline config so you can diff after changes. You’ll know you’re winning when broadcast noise drops, counters look clean, and your ACLs are short and explainable.