How Colocation Changes the Way You Design Enterprise Network Topology

Most enterprise networks were drawn around a building. The headquarters sat at the center, branch offices connected back to it, and the internet edge lived in a comms room down the hall. Move your core infrastructure into a colocation facility and that assumption breaks. The center of gravity shifts, and a topology that made sense in an on-premises world starts to look inefficient the moment your servers live somewhere else.

Here's what actually changes when you design for colocation.

The WAN edge relocates

In a traditional design, traffic from branch sites terminates at headquarters because that's where the servers are. Once workloads move to a colocation cage, headquarters becomes just another branch. It consumes applications rather than hosting them.

That reversal has real consequences. Your MPLS or SD-WAN hub belongs at the facility, not the office. Backhaul patterns that once made sense now add a pointless hop. If your corporate office still terminates every VPN tunnel before forwarding traffic to colocated servers, you're paying latency twice.

The cleanest approach is to treat the colocation cage as the new hub and headquarters as a spoke. SD-WAN makes this straightforward — you deploy edge devices at the facility, advertise your data center prefixes from there, and let branch sites build tunnels directly.

Routing gets more interesting

On-premises networks usually run a default route toward a single ISP. Colocation removes that constraint, and most teams underuse the freedom.

A carrier-neutral facility gives you access to multiple Tier 1 providers in the same building. That opens the door to BGP multihoming with your own autonomous system number and provider-independent address space. Instead of renumbering when you switch carriers, you keep your prefixes and change upstream. Instead of an outage when one provider has a bad day, you fail over in seconds.

This is a design decision, not a procurement one. You need to plan AS path prepending for inbound traffic engineering, decide whether you accept full tables or default routes from each upstream, and size your edge routers for the memory that full tables require. Communities let you influence how upstream providers propagate your routes, which matters more than most teams realize when regional performance varies.

If BGP is more operational overhead than your team wants, redundant transit with automated failover still beats a single circuit — but you give up the traffic engineering control.

Layer 2 becomes a physical question

Inside a facility, connectivity happens through cross-connects and meet-me rooms rather than switches you own. A fiber pair between your cage and a carrier's equipment is a physical asset with a monthly cost and a provisioning lead time.

That changes how you plan. You can't spin up a new uplink in an afternoon. You need to think about diverse paths — two cross-connects entering your cage from separate points, terminating on separate switches, ideally through separate conduit. Diversity that exists on paper but shares a single riser is not diversity.

It also changes VLAN design. Extending Layer 2 across facilities is possible with VXLAN or similar overlays, but the failure domains get large quickly. Most mature designs keep Layer 3 boundaries tight and use overlays only where an application genuinely requires adjacency.

Redundancy priorities shift

Facility operators handle power and cooling redundancy — N+1 or 2N configurations, dual feeds, backup generation, environmental monitoring. That work moves off your plate.

What doesn't move off your plate is network path redundancy. The most common colocation failure isn't a facility problem; it's a single point of failure inside the customer's own cage. One firewall. One core switch. Both uplinks landing on the same line card.

Design for the failure modes you still own: redundant firewalls in active-passive or active-active, dual top-of-rack switches with MLAG or a similar mechanism, and management access that survives a data plane outage. Out-of-band management deserves particular attention. If your only path to the console is through the network you just broke, remote hands become the fix — and that's slower than a console server on a separate circuit.

Cloud on-ramps become part of the topology

Colocation facilities sit close to cloud provider peering points, which makes direct connectivity practical. A dedicated circuit into a public cloud region gives you predictable latency and lower egress costs than internet transit.

Design that connection deliberately. Decide which prefixes you advertise into the cloud and which you accept. Plan for asymmetric routing, which appears fast when hybrid workloads span both environments. Build a second circuit or a VPN backup, because a single direct connection is a single point of failure with a long repair window.

The security perimeter distributes

With workloads in a facility, branch users on SD-WAN, and applications in public cloud, there's no longer one place to inspect traffic. Inspection points multiply.

Practical designs place next-generation firewalls at the colocation edge for north-south traffic, use segmentation inside the cage for east-west, and push identity-based policy toward users regardless of location. Network detection and response tools help here — they see lateral movement that perimeter firewalls miss entirely.

Start with traffic, not racks

The most useful first step isn't choosing a cabinet size. It's mapping where your traffic actually originates and terminates today, then asking which of those paths get shorter when the servers move.

Usually the answer reshapes the diagram more than the move itself does.