Magic Transit Topology: Direct XC vs GRE

Failure modes, redundancy patterns, and the design choices for your Chicago and London rollout.

Jump to: TL;DR GRE topology XC topology Side by side Resilient designs What I recommend On ordering the XC
The honest answer to your concern. Yes, your concern about Cloudflare-side hardware failure impacting a direct XC path is real and correct. A single XC terminates on a specific Cloudflare router in a specific building. If that router fails, that path is down until we restore it. GRE uses anycast, which reconverges to the next Cloudflare data center automatically. That is the core tradeoff, and it is the reason production CNI deployments are almost always built with redundant paths rather than a single XC.

GRE topology (what you would have without CNI)

GRE over the public internet, anycast tunnel endpoints
┌──────────────────────────────┐ │ Cloudflare Global Network │ │ │ Your Chicago Router │ ┌────┐ ┌────┐ ┌────┐ │ ┌───────────────┐ │ │ORD │ │IAD │ │DFW │ │ │ │ │ │ DC │ │ DC │ │ DC │ │ │ GRE tunnel │ │ └─┬──┘ └─┬──┘ └─┬──┘ │ │ endpoint │────┼─────┴───────┴───────┴── │ │ │ │ Anycast tunnel endpoint │ │ BGP peer │ │ (same IP, many DCs) │ └───────┬───────┘ │ │ │ └──────────────────────────────┘ │ ISP uplinks (public internet) ▼ Your ISPs

Traffic from your router encapsulates in GRE, rides your ISP uplinks over the public internet, lands at whichever Cloudflare data center is topologically closest. If that DC fails, the anycast route withdraws and traffic reconverges to the next closest DC within seconds. You do nothing.

Direct XC topology (Cloudflare Network Interconnect)

Direct cross-connect to Cloudflare at Equinix CH2
Equinix CH2 Building ┌───────────────────────────────────────────────┐ │ │ │ Your Cage Cloudflare Cage │ │ ┌──────────┐ ┌──────────────┐ │ │ │ │ │ │ │ │ │ Your │ │ Cloudflare │ │ │ │ Router │◄──── XC ───►│ Router A │ │ │ │ │ │ │ │ │ │ BGP │ │ BGP │ │ │ │ peer │ │ peer │ │ │ └──────────┘ └──────┬───────┘ │ │ │ │ └───────────────────────────────────┼───────────┘ │ ▼ Cloudflare Backbone (to global network)

Traffic from your router goes over a physical fiber cross-connect into a specific Cloudflare router in CH2, then onto the Cloudflare backbone. Better latency, better jitter, does not touch the public internet. But if that specific router or that specific XC fails, this path is down until repair.

Side by side

AspectGRE tunnelDirect XC (CNI)
Where the tunnel or session terminates on CloudflareAnycast IP, resolved to the closest of many Cloudflare DCsA specific router in a specific building
PathPublic internet via your ISPsPhysical fiber into Cloudflare's backbone
Latency and jitterISP dependent, typically higherDirect into backbone, typically lower and more consistent
Impact of one Cloudflare router failingNone, anycast routes around itBGP session drops, path unavailable until restored
Impact of one Cloudflare DC failingReconvergence to next DC, seconds of lossTotal loss of that path if the DC hosting your XC is affected
Impact of a fiber cut on the XCN/APath down until Equinix repairs the fiber
CostNo direct connectivity cost, rides your existing ISPXC MRC to Equinix, port cost from Cloudflare
Redundancy requirementMultiple ISP uplinks on your sideMultiple XCs, or XC plus GRE backup
The point. XC gives you better performance. GRE gives you inherent anycast resilience. Neither is strictly better. The right production design combines them, or uses redundant XCs, so a single Cloudflare-side hardware event does not take you offline.

Three resilient designs for your Chicago rollout

Option A: Two XCs to two Cloudflare routers in CH2 Solid

Equinix CH2 ┌────────────────────────────────────────────┐ │ │ │ Your Cage Cloudflare Cage │ │ ┌──────────┐ ┌──────────────┐ │ │ │ │───XC1─►│ Router A │ │ │ │ Your │ └──────────────┘ │ │ │ Router │ │ │ │ │ ┌──────────────┐ │ │ │ │───XC2─►│ Router B │ │ │ └──────────┘ └──────────────┘ │ │ │ └────────────────────────────────────────────┘

Option B: One XC in CH2 plus one XC in a diverse Cloudflare facility Most resilient

Equinix CH2 Diverse facility ┌──────────────────┐ ┌──────────────────┐ │ Your Cage │ │ Your Cage │ │ ┌──────────┐ │ │ ┌──────────┐ │ │ │ Router │───►│ XC to CF │ │ Router │───►│ XC to CF │ │ A │ │ │ │ B │ │ │ └──────────┘ │ │ └──────────┘ │ └──────────────────┘ └──────────────────┘

Option C: One XC in CH2 plus GRE tunnel as warm backup Best cost-to-resilience ratio

Equinix CH2 ┌────────────────────────────────────────────┐ │ Your Cage Cloudflare Cage │ │ ┌──────────┐ ┌──────────────┐ │ │ │ │───XC──►│ Router A │ │ │ │ Your │ └──────────────┘ │ │ │ Router │ │ │ └────┬─────┘ │ └───────┼────────────────────────────────────┘ │ │ GRE tunnel over ISP uplinks (backup path) ▼ ┌──────────────────────────────────┐ │ Cloudflare Anycast Tunnel │ │ Endpoint (many DCs) │ └──────────────────────────────────┘
The design to avoid: one XC in CH2 with no backup path. A single XC is a single point of failure at the Cloudflare-side hardware layer. If the port, router, or fiber fails, traffic to your Cloudflare service stops on that path until repair. Not a hypothetical, this is exactly the failure mode you were asking about.

What I recommend for your rollout

Chicago (initial rollout). Option C. One XC to Cloudflare in CH2 as the primary path, one GRE tunnel over your existing ISP uplinks as the warm backup. This gives you the latency and jitter benefits of direct connectivity for normal operation, and the anycast resilience of GRE if anything on the Cloudflare side of the XC fails. It is also the cheapest resilient design, because you are not paying for a second XC or a second facility.

London (when it comes online). Same pattern in TH2. One XC to Cloudflare in Telehouse North 2, one GRE tunnel as backup. Design consistency across sites makes operations simpler.

If your SLA or compliance posture requires facility-level redundancy, upgrade Chicago to Option B by adding an XC in a diverse Cloudflare facility. This is not necessary for most customers, but it exists as an option if the risk model calls for it.

On ordering the XC through Cloudflare

You asked whether Cloudflare can order the XC on your behalf to get better Equinix pricing. Straight answer, generally no.

Cross-connects at Equinix are ordered by the customer of record directly through the Equinix portal. Equinix bills the customer for the MRC. Cloudflare does not resell those XCs, which means our Equinix pricing does not flow through to you.

What Cloudflare covers on the CNI side:

What you pay Equinix directly:

If you already have a footprint in CH2 or can reach CH2 economically through Equinix Fabric from CH1, that keeps the XC economics reasonable. If you are provisioning new cage space in CH2 just for this, that is a real cost worth putting on the table.