Two carrier contracts are a starting point for redundant data center connectivity. The useful question is what happens when one component fails: which traffic moves, where it moves, and what must remain available for that move to work. Build the design around those answers before choosing circuit speeds.
Trace the physical paths behind the carrier names
Carrier diversity and route diversity address different risks. Separate providers can still use the same last-mile operator, underground duct, building entrance, or upstream facility. Two invoices do not establish that a single cable incident leaves one circuit working.
Ask for a documented diversity review covering the path from your equipment through the building and into each provider network. Where detailed maps cannot be shared, request written confirmation of the relevant separations and any known common segments.
- Identify shared ducts, entrances, risers, and meet-me rooms.
- Confirm the underlying last-mile supplier for each service.
- Ask where separate access paths meet common upstream infrastructure.
Record unknowns explicitly. A provider's network map or an on-net label alone cannot establish the independence of your ordered circuits.
Confirm the building, demarcation, and delivery sequence
Ask whether the carrier is present in your actual building and where its handoff sits. Presence elsewhere on a campus may require an interbuilding connection. That additional segment needs an owner, delivery plan, and diversity review.
A cross-connect links designated endpoints; it does not automatically complete every patch to your router. Equinix, for example, assigns customers responsibility for patching from its demarcation point to their equipment. Confirm your facility's own boundary and installation scope. Equinix demarcation documentation.
Put authorization and port assignments into the schedule. For AWS Direct Connect, the LOA-CFA—Letter of Authorization and Connecting Facility Assignment—authorizes the cross-connect, which is then ordered through the relevant provider. AWS also treats a campus as one Direct Connect location. These are useful reminders to confirm both paperwork and location boundaries. AWS connection workflow.
Track carrier readiness, LOA/CFA issuance where applicable, cross-connect completion, final patching, and acceptance separately in the deployment plan.
Specify what each connection actually delivers
Three common service categories solve different problems:
- Dedicated Internet Access (DIA) delivers Internet connectivity to a customer site, with addressing and routing options defined by the service.
- IP transit provides Internet reachability for a network, typically through a BGP relationship with the upstream provider.
- Transport connects specified endpoints through services such as Ethernet or wavelength connectivity; it does not inherently include Internet access.
Start a connectivity review with destinations and traffic requirements. A private link to another facility and an Internet connection may both be necessary, but one cannot be assumed to replace the other.
Review equipment and routing as one design
Two routers still share a failure risk if both depend on one switch, power source, firewall, or configuration mistake. Trace the complete forwarding path, including downstream connectivity. Check that the surviving equipment and circuit can carry the required workload during maintenance or failure.
Decide who operates routing before ordering. Your own autonomous system number (ASN), address space, and BGP sessions may be appropriate when announcing the same public prefixes through multiple providers. Requirements differ for managed Internet services and other failover designs. RFC 4116 describes several IPv4 approaches with different addressing and AS-number implications. RFC 4116.
Full Internet routing tables are not a universal requirement. Default routes or selected routes may meet the design's needs; confirm how they will be withdrawn when the upstream path becomes unusable. Agree on prefix acceptance, routing responsibility, and inbound as well as outbound behavior before commissioning.
Test failure and recovery under controlled conditions
Schedule failover tests with a rollback plan and agreed acceptance criteria. AWS's Direct Connect toolkit explicitly supports bringing down a BGP session to verify traffic moves to a redundant interface. Its resiliency models also distinguish separate devices from separate locations. AWS resiliency guidance.
Use that principle in your own environment: test each circuit and relevant equipment failure independently. Observe packet loss, latency, route changes, BGP session state, and application sessions from both inside and outside the facility. Check whether existing sessions survive and whether new sessions succeed.
Measure the remaining path under representative load. Then restore the original path and verify recovery. A successful routing change alone does not show that the application remained usable.
Make maintenance and escalation part of acceptance
Document circuit IDs, demarcations, support contacts, maintenance notification channels, and escalation ownership before handover. Specify who opens tickets when the carrier, facility, and equipment operator each own part of the path.
During a partner discussion, establish who coordinates overlapping maintenance and requests investigation of shared infrastructure. Agree on communication expectations and response procedures for the actual services being ordered. Keep the resulting runbook with the topology, test results, and unresolved dependencies so the next operator can act without reconstructing the design.