How far should VLANs extend, and where should routing begin?

Check why the same VLAN must extend to another wiring closet ↑

Before extending a VLAN to another wiring closet, ask whether its endpoints must share an L2 segment. An application's use of IP does not, by itself, require several closets to share one broadcast domain.

Within one VLAN, endpoints can discover each other's MAC addresses on the local link and exchange frames directly. Across a routing boundary, an endpoint instead sends its frame to its own gateway, not to the remote destination. First check whether that difference affects the business requirement.

If a device must keep its address after moving, or an application depends on a particular L2 behavior, document the reason. Distinguish operating habits from essential application requirements. If the requirement cannot change, account for the extent of the VLAN and the resulting failure and change impacts.

If only IP connectivity is needed, consider keeping each VLAN within its access segment. Moving the routing boundary still changes addressing, policy, DHCP forwarding, and management. Compare the benefit of a smaller broadcast domain with the work of changing addresses and policies.

An incorrect subnet mask changes an endpoint's initial decision: look for the destination on the local link, or send to the gateway. Before examining the destination MAC address, check the source address, mask, and selected next hop. This order helps avoid mistaking an addressing problem for a switch's MAC-learning problem.

Keep PC-A and App-S in the same roles while comparing boundary locations. An educational comparison that retains addresses is not a migration procedure. Separating a subnet spread across several access segments needs its own address plan; moving the gateway symbol on a diagram is not enough.

When distribution hosts the gateway, how far does a frame travel? ↑

In the L2 access example, PC-A's frame travels to a gateway at the distribution layer. The access layer provides VLAN connectivity through L2 forwarding. The gateway examines the destination IP address to choose a route to the next network.

PC-A is 10.60.10.21/24, and App-S is 10.60.20.10/24. Because the destination is outside PC-A's local subnet, it uses the gateway at 10.60.10.1, resolving that interface's MAC address with ARP. Here, the gateway is on D1, and VLAN10 extends from A1 to D1.

PC-A's Ethernet header targets D1's gateway MAC, while its IP header targets App-S. A1 forwards toward D1 using information for the VLAN and destination MAC. A1 may also apply ACL or QoS rules that inspect IP fields. Reading those fields is not the same as using the destination IP address for routing to another network.

D1 extracts the packet from the frame addressed to it and selects forwarding information for the destination IP address. If App-S's subnet is directly connected, D1 looks up App-S's MAC in its neighbor information, using ARP on that link if needed. It then creates a new Ethernet header from its outgoing interface's MAC to App-S's MAC.

The endpoint connects to A1, and its gateway is on D1, so the required VLAN must actually reach between them. A healthy uplink cable is not enough: if that VLAN is not allowed, the gateway is unreachable. Check physical connectivity and forwarding for the required VLAN separately.

The source and destination IP addresses stay unchanged in this internal example without NAT. Forwarding-related values, including the IPv4 TTL and header checksum, change as routers process the packet. Replies travel through App-S's gateway toward PC-A. A device first selects a route for the packet, then resolves the MAC address needed on that route using ARP.

Follow PC-A's frame with D1 as its gateway. A1 forwards by destination MAC; D1 performs routing and creates a new frame for App-S.

Moving the gateway to access changes the next hop and headers ↑

With routed access, an endpoint's gateway sits on the access switch, and the uplink is a routed connection. Compared with the previous design, the endpoint's first frame is removed at a different device, which routes the packet toward a different next hop.

For comparison, keep PC-A's gateway address at 10.60.10.1, but assign it to A1 instead. PC-A now sends frames to A1's gateway MAC. This is a separate design that retains the address to make comparison easier—not an instruction to configure the same address on D1 and A1 simultaneously during migration.

Connect A1 and D1 on 10.255.1.0/30, with A1 at .2 and D1 at .1. For App-S, A1 selects next hop 10.255.1.1 from its forwarding entry. On this Ethernet link, it obtains that next hop's MAC from neighbor information or ARP, then creates a frame from its uplink interface to D1.

D1 forwards the received IP packet toward App-S using the destination and its forwarding information. If App-S is directly connected, D1 uses App-S's MAC; if another router is required, it uses that next hop's MAC. Keep the final destination IP separate from the current link's destination MAC to follow the process even when the boundary moves.

Here, D1 connects directly to App-S's subnet, so it resolves App-S's MAC address. If another router were needed, D1 would instead resolve that next hop's MAC address. The IP destination identifies the final server; the MAC destination identifies the device receiving the frame on the current link.

For replies to return, D1 also needs a route to 10.60.10.0/24 through A1. A1 delivers the final frame to PC-A's MAC. The diagram's gateway MAC and next-hop MAC labels distinguish roles, not actual device addresses or the virtual MAC format of a first-hop redundancy protocol.

In this alternative, A1 is the gateway. Compare the final IP destination with the destination MAC on each link: PC-A→A1, A1→D1, and D1→App-S.

Gateway placement also changes where STP, redundancy, and policy apply ↑

Moving the L2/L3 boundary usually changes where functions are needed and how far they apply, rather than removing them. Revisit which protocols handle link and device failures in each design.

With L2 uplinks, check the extent of each VLAN and how loops are prevented. If the gateway spans multiple distribution devices, examine how first-hop redundancy interacts with frame forwarding. Equal device counts do not imply equal normal or failure paths.

After converting an uplink to a routed connection, its alternate paths can be handled through routing and forwarding updates. That does not remove every access-side L2 loop risk. Connections and protection mechanisms in the endpoint segments still need review.

Policy may need to move too. Rules previously enforced at the distribution gateway—such as inter-VLAN ACLs—may no longer see that traffic. If DHCP uses a server on another network, check the relay location and the client subnet that the server identifies. Moving the boundary changes forwarding, address configuration, and security together.

Moving policy to another device also moves where you observe traffic and counters. Between endpoints, routing previously visible on D1 may now finish at A1. An unchanged counter on the old device does not prove there is no traffic; observe actual requests at the new boundary.

Do not compare products' convergence or state-retention capabilities by feature names alone. Verify that the required routing functions, resources, and operational checks are available on the access devices. Test whether the design reduces the failure domain, and whether operators can keep it manageable.

Redraw both designs with the same PC-A and App-S. On the left, VLAN10 extends to D1; on the right, it ends at A1. A different gateway means the PC resolves a different device's MAC address, and D1 needs a different way to route replies.

Record why you chose this boundary and rejected the alternatives↑

Once you choose the L2/L3 boundary, document the reasoning alongside the diagram. What matters is how the design supports required communication and limits outage impact—not whether it is newer.

Where L2 adjacency is genuinely required, consider retaining it within a limited area. If IP connectivity between segments is sufficient and the failure domain needs to be divided at the access layer, compare routed access. Evaluate features, operational capability, and address and policy migration costs on the same basis.

For the chosen design, record both directions of communication in normal and failure conditions. Whose MAC does PC-A resolve? Which device selects the IP forwarding entry? How do replies return? Verify the existence of a basic path separately from whether the business traffic is allowed by policy.

Add a short reason for each rejected alternative: missing feature support, address-mobility requirements, or migration work disproportionate to the acceptable impact. This makes the decision easier to revisit when conditions change and explains why the previous design made sense at the time.

Be specific about requests to extend a VLAN across locations. Keeping an endpoint's address for convenience differs from an application requiring L2 adjacency. Consider whether renumbering or service redesign can meet the need before deciding how far the VLAN must extend.

For a real migration, test communication in the new design and prepare a rollback procedure. The diagrams above compare architectures; plan the actual cutover sequence for the site's conditions to limit disruption. The next multiple-closet two-tier example uses routed access to build the connections. The redundancy article then distinguishes first-hop failover from upstream-path failover.