Everything up to this point stayed inside your cage. This part is about the handful of strands that leave it, and about the paperwork that governs them — because the paperwork is genuinely the hard part.
The chain, end to end
Almost all confusion here dissolves once you can draw the path. It is four links.
┌── YOUR CAGE ───────────────────────┐
│ │
│ server ── ToR switch ── your edge │
│ router │
│ │ │
│ ┌────┴────┐ │
│ │ DEMARC │ │ ← the boundary of responsibility.
│ │ PANEL │ │ Your side / their side.
│ └────┬────┘ │
└─────────────────────────────┼───────┘
│
╔═══════════╧═══════════╗
║ CROSS-CONNECT ║ ← a physical cable the
║ (a cable, not a ║ facility installs and
║ service) ║ charges rent on.
╚═══════════╤═══════════╝
│
┌── MEET-ME ROOM (MMR) ───────┼──────────────────────────────┐
│ restricted room. Every carrier, cloud on-ramp and │
│ tenant terminates here on fibre distribution frames. │
│ │
│ [carrier A] [carrier B] [AWS] [Azure] [the IX] ... │
└─────────────────────────────────────────────────────────────┘
Your responsibility ends at the demarc. The cross-connect is the facility's to install and maintain. The far end belongs to whoever you connected to.
Demarc
The demarcation point is a boundary of responsibility, expressed as a physical object — normally a patch panel in or beside your cage.
The reason it matters operationally: when a circuit is down, the very first thing that happens is an argument about which side the fault is on, and every conversation you have with the facility and the carrier will be framed by it. "Is the light present at the demarc?" is the question that resolves it. If light is arriving at your panel and your router sees nothing, it is yours. If no light is arriving, it is theirs.
This is why "please check for light at the demarc panel and read me the port label" is one of the most valuable remote hands requests in existence. It is a five-minute task that assigns ownership of an outage.
Meet-Me Room
The MMR is the building's switchboard: a secured room containing fibre distribution frames, patch panels and optical termination equipment, where every carrier, cloud provider and tenant in the facility lands their network.
You do not get access. Nobody gets casual access — the MMR is typically the most access-controlled space in the building, because it contains everyone's connectivity at once.
The property that makes a facility valuable is the contents of its MMR. A carrier-neutral facility is one that lets any carrier terminate there and does not force you to buy connectivity from the landlord. The number and identity of carriers, clouds and exchanges present in the MMR is, in practice, the main thing that distinguishes one datacenter from another once power and cooling are adequate. When someone says a facility is "well connected", that is what they mean.
Cross-connect
A cross-connect is a physical cable installed by the facility between two termination points in the building — nearly always from your demarc panel to some other party's termination in the MMR.
The things to internalise:
It is a cable, not a circuit and not a service. There is no bandwidth associated with it. It carries whatever the two ends agree to run over it. Ordering a cross-connect and expecting connectivity is like ordering a patch lead and expecting an ISP.
It has an install fee and a recurring monthly rental. Cross-connect rent is a meaningful line item, and it is why consolidating onto fewer, bigger connections is a real cost lever.
It takes days, not minutes. A human has to route and patch it. Plan lead time into any project that needs one, and plan more if the facility is busy.
It comes in flavours. Singlemode fibre is the default for anything modern. Multimode and copper exist, usually for legacy hand-offs. Specify which you need, because the far end dictates it.
A and Z. The two ends of a circuit are the A-side and the Z-side. This is unrelated to the A/B of power from Part 2 — same letters, different domain. Context disambiguates: power has A and B, circuits have A and Z.
LOA-CFA, the document that makes it happen
To order a cross-connect, you supply a Letter of Authorization / Connecting Facility Assignment.
The other party issues it. It says, in effect: this customer is authorised to connect to us, and here is the exact cabinet, patch panel and port to land it on. The facility will not patch anything without it, because they have no other proof the far end consented to being connected to.
A good LOA-CFA identifies the party, the location, the cabinet, the panel and the port. That precision is the point — a technician in the MMR needs to find one specific port among thousands.
Two operational details worth knowing. They expire. AWS, for example, issues an LOA-CFA for a Direct Connect port and the authority lapses if the cross-connect is not completed in time; you re-download it from the console to renew. And you will normally need two: one from the far end for their side, and often one from yourself authorising the facility to land it on your panel.
The realistic sequence for a cloud on-ramp:
- Request a port from the provider in their console. They allocate it and issue an LOA-CFA.
- Download the LOA-CFA.
- Open a cross-connect order with the facility, attaching the LOA-CFA, specifying your cabinet, your panel, your port, and the media type.
- Facility schedules a technician. Days pass.
- Cross-connect is installed. You confirm light and the provider confirms their side.
- Configure the logical layer — VLAN, BGP session, addressing.
Steps 1 to 5 are paperwork and waiting. Step 6 is the part that feels like engineering and takes twenty minutes. Budget accordingly, and start the paperwork long before you think you need to.
Direct connect to a cloud
A direct connection to a cloud provider is a cross-connect whose far end is the provider's router rather than a carrier's. The brand names: AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect.
The benefit is that traffic to that cloud leaves your cabinet, crosses the MMR on your fibre, and lands on the provider without traversing the public internet. You get predictable latency, no exposure to internet-path weather, generally lower egress pricing, and a private path for things you would rather not route publicly.
Two purchasing models, and the difference matters:
Dedicated. An entire physical port that is yours. In AWS's case 1, 10, 100 or 400 Gbps. You order the cross-connect yourself, using the LOA-CFA process above. You get full control, the option of MACsec encryption on your own port, and the highest availability commitments. You also need to be physically present in a facility where the provider has a presence.
Hosted. A logical slice of a partner's existing port, sold to you in much smaller increments — AWS hosted connections run from 50 Mbps up to 25 Gbps. The partner already has the cross-connect, so you order none. It is faster to provision, available at sizes a dedicated port cannot offer, and it is the right answer if you need 500 Mbps rather than 10 Gbps.
Choose dedicated if you need the bandwidth, the control or the encryption. Choose hosted if you need a modest amount of private connectivity quickly, or if you are not in the right building.
Redundancy here is a physical question, not a logical one. Two connections that share a cross-connect, a panel, a room or a building are not redundant. If the direct connection matters, the second one should land on a different provider device, ideally in a different facility, and you should be able to say which physical elements the two paths share. Ask specifically; "we have two connections" is not an answer.
Getting to the internet: transit, peering, IX
Three distinct things, frequently muddled.
IP transit is the commercial service of "reach the entire internet through me". You buy it from a carrier, you announce your prefixes to them over BGP, and they carry your traffic anywhere. It is the default and it is what most people mean by "our internet connection".
Peering is a direct BGP relationship with another network, over which you exchange only traffic destined for each other's customers. It is not a route to the internet — it is a shortcut to that specific network. Because both sides benefit, peering is settlement-free in the overwhelming majority of cases.
An Internet Exchange (IX) is shared infrastructure — a large layer-2 switching fabric in a colocation facility — where many networks connect once and then peer with many others. You take one cross-connect to the IX, and from that single port you can establish BGP sessions with hundreds of networks. That leverage is the entire value proposition.
TRANSIT PEERING IX
─────── ─────── ──
you ──► carrier ──► the you ◄──► them you ──┐
(paid, reaches (direct, usually them ─┤ IX
everywhere) free, only their more ─┤ fabric
own customers) more ─┘
one cross-connect,
many BGP sessions
In practice a mature network buys transit from two carriers for full reachability and resilience, and peers at an IX to move the large, cheap, latency-sensitive volume — which is why an IX presence pays for itself once your traffic is big enough.
Billing is worth understanding because it is unlike anything else you buy. IP transit is normally billed on the 95th percentile: usage is sampled at five-minute intervals across the month, the samples are sorted, the top 5 % are discarded, and you pay on the highest remaining sample. Roughly the top 36 hours of every month are free.
The consequences are genuinely useful. Short bursts are free — a release, a backup window, a traffic spike, provided it stays under about 36 hours in aggregate. Sustained increases cost immediately. And a commit is a minimum monthly volume you agree to pay for regardless of use, in exchange for a lower per-megabit rate; a common shape is a commit around 10 % of port capacity. So a large port with a small commit is a legitimate way to buy burst headroom cheaply, and scheduling bulk transfers so they do not extend your 95th percentile is a real and effective cost optimisation.
What to know about your own connectivity
Five questions. If you cannot answer them, that is your homework, and every one of them is answerable by asking rather than by touching anything.
- How many cross-connects leave your cage, and where does each one terminate?
- For each, which physical panel and port is it on at your end? This is what you quote in a ticket.
- Which are transit, which are peering, which are cloud on-ramps?
- What do your two "redundant" paths physically share? Same panel? Same room? Same building? Same conduit into the street?
- What is your 95th percentile, and what is your commit?
Question 4 is the one that catches people. Diversity on paper is common; diversity in conduit is rare and expensive; the difference only becomes visible when a digger finds the one duct both circuits happened to use.
The one-line summary
Demarc is where your responsibility ends. The MMR is the building's switchboard and its tenant list is what makes a facility valuable. A cross-connect is a rented physical cable, ordered with an LOA-CFA from the far end, and it takes days. Direct connect is a cross-connect to a cloud — dedicated for a whole port, hosted for a slice. Transit reaches everywhere and is billed at the 95th percentile; peering is a free shortcut to one network; an IX is one cross-connect that gets you hundreds of them.
Next up: Part 7 — directing remote hands, which is where all six previous parts turn into a ticket that works the first time.