Separate Routing From Switching In A Small High‑Speed LAN

Thesis: A dedicated router and a line‑rate switch solve different problems; separating them keeps local bulk traffic off the gateway and makes performance sizing honest.

Router Responsibilities ≠ Switch Responsibilities

Routing and switching are adjacent concerns but different contracts. A router is the policy and stateful boundary: north–south routing, NAT (if you use it), VPN termination, inter‑network policy, BGP/OSPF when required, ACL enforcement, and anything that stores per‑flow state. A switch is the fast fabric: MAC learning, VLAN isolation, STP/fast reroute on the L2 plane, and line‑rate forwarding of local traffic.

Treat those responsibilities as explicit adapters with clear acceptance criteria. If a device needs to maintain per‑session logs, hold connection tables, or terminate tunnels, it belongs on the router side of the contract. If it needs to forward multi‑gigabit LAN flows with minimal latency, it belongs on the switch.

Tradeoffs: consolidating responsibilities reduces device count and points of management but increases blast radius and forces the gateway to be sized for local bulk traffic it shouldn’t see.

East–West Belongs On The Switching Fabric

East–west traffic (host‑to‑host inside the LAN) is where line‑rate switching matters. When two PCs or a PC and a server exchange large files, you want that traffic to stay on the switching fabric instead of detouring through a CPU‑bound router.

Keeping bulk flows local lowers latency, reduces router CPU pressure, and makes predictable capacity planning possible. Failure modes to watch for include: accidental hairpins from misconfigured routing/VLANs, oversubscribed uplinks on access switches, and underprovisioned switching ASIC features (ACLs or SVI offload limitations).

Design constraint: trust your switches to do what they’re good at — forward — and your router to enforce policy at the edge.

VLAN Routing Is A Sizing Multiplier

Putting devices into VLANs changes who has to do the routing. Within a VLAN, east‑west stays on the switch. Cross‑VLAN traffic requires a router or an L3 SVI; that decision multiplies the router’s required throughput.

Where VLAN routing happens changes the math:

• If the switch provides L3 SVIs and hardware‑accelerated routing, most inter‑VLAN traffic can stay at line rate on the switch.
• If SVIs are not hardware‑accelerated, or if the switch punts packets to a CPU for ACLs or mirroring, inter‑VLAN traffic can become a router problem.

Worksheet: How to estimate gateway sizing

• Variables:
  • N = number of active endpoints
  • B = average per‑endpoint bandwidth during peak (Mbps)
  • P_ns = proportion of traffic that is north–south (0–1)
  • P_cv = proportion of east–west traffic that crosses VLANs (0–1)
• Gateway throughput requirement (Mbps) ≈ N * B * (P_ns + P_cv)

Use dry runs: measure real peak B with a load generator and measure VLAN crossing. The worst mistake is assuming all local traffic is north–south — that inflates router sizing unnecessarily.

Failure modes: miscounting P_cv (many apps use cross‑VLAN microservices), implicit multicast/ARP storms, and management features that force CPU involvement on switches.

When A Single Combined Box Is Still Reasonable

There are cases where a combined router/switch box is sensible:

• Very small networks where aggregate bandwidth and policy needs are low.
• Environments with strict budget or footprint limits and a tolerance for higher blast radius.
• When the integrated device provides true ASIC‑level L3 switching and meets your SVI and ACL requirements.

When choosing a combined box, demand honest acceptance criteria: it must sustain your measured peak LAN flows without maxing CPU, must support required ACLs in hardware, and must log/monitor without degrading forwarding.

Costs: consolidation buys simplicity but hides the multiple failure modes behind a single box. If you accept that, plan for faster replacement and stronger backups for configs.

Implementation Checklist: Two‑Box Gateway

Use this checklist before flipping the switch.

• Acceptance criteria
  • Measured peak east–west load and north–south load
  • VLAN map with expected P_cv for each service
  • List of policy features that must remain on the router (VPN, stateful firewall, NAT, BGP)
• Hardware selection
  • Switch: line‑rate ports, SVI hardware offload, enough MAC and ACL capacity
  • Router: interfaces for WAN, CPU and forwarding plane sized for north–south plus any punted traffic
• Configuration steps (dry run in lab first)
  • Build VLANs and trunk ports, verify L2 forwarding
  • Decide where SVIs live (switch versus router) and document routing plane
  • Apply least‑privilege ACLs on the router for north–south; prefer switch ACLs only if hardware accelerated
• Validation
  • Run file transfers across same VLAN and across VLANs, record path and device CPU
  • Simulate VPN connections and verify connection counts
  • Validate logging and rollback plan
• Rollback plan
  • Clear, time‑boxed rollback steps
  • Configuration backups and a tested restore

Failure Modes, Monitoring, And Rollback

Plan for observability at the boundary between switch and router. Minimum signals:

• Router CPU and flow table utilization, VPN tunnel counts, and interface errors
• Switch forwarding rates per port, SVI utilization, hardware ACL counters, and trunk utilization
• Application latency for east‑west transfers and north‑south transactions

Keep the blast radius small: manage switch and router credentials separately, apply least privilege for configuration APIs, and automate config snapshots. During an upgrade or config change, run a dry run where possible, implement changes during a narrow maintenance window, and have an explicit rollback timebox.

When things fail, logs matter more than guesswork. Capture flow samples (sFlow/NetFlow) and correlate them with device counters before flipping configurations you can’t revert quickly.

Grounded Takeaway

Separate routing from switching when the network has significant local bulk transfer, multiple VLANs, or stateful edge services. The two‑box pattern makes capacity and failure modes explicit: switches forward; routers enforce policy. Use measured traffic, the VLAN routing worksheet above, and a dry‑run checklist to verify sizing before you commit. If budget or simplicity trumps isolation, a combined box can be acceptable — but only with clear acceptance criteria and a tested rollback plan.

If you want a short checklist to take into a lab or procurement meeting, use the Implementation Checklist above. For design discussion or assistance, /contact.