Protected vs Dual-Diverse: GPU Network Handoffs

Compare the protection boundary before buying the service

For an inter-site GPU network, a protected connection can leave a shared handoff node in place. An alternative route between two nodes cannot bypass an unavailable endpoint node. The purchase question is therefore which physical dependency the service protects, and what it presents to the customer at each end.

Equinix's Metro Connect documentation, checked October 19, 2026, makes the distinction explicit. Protected Metro Connect has two diverse fiber paths, one switch at each location and one physical customer connection per location. It expressly excludes node protection. Dual-Diverse Metro Connect has two diverse fiber paths, two switches per location and two physical customer connections at each end; Equinix lists node protection for that offering.

Use these named descriptions to ask whether the proposed service covers route loss alone or also loss of a provider node. If the requirement includes the latter, Protected's stated scope leaves it unresolved. Confirm the actual offered configuration and demarcations for the two locations before carrying its protection claim into the customer design.

References: [E1]

Accommodate the handoffs without guessing the tenant hardware

The provider's switch count describes its service architecture. It does not automatically become a requirement to purchase or install the same number of tenant switches. The customer network owner must decide which equipment receives the handoffs and which equipment dependencies the design is intended to avoid.

Two service connections delivered to two ports on one tenant chassis would still share that chassis. Receiving them on different tenant devices changes that particular dependency, but also introduces equipment placement, interface, power and cabling questions. The appropriate arrangement follows the approved network and facility design; a transport product comparison cannot select it.

At each site, identify the physical handoff positions and the customer equipment interfaces that continue them. Confirm the required media, connectors and equipment compatibility from the actual provider return and equipment documentation. Plan patch positions, routing, cable management and access for every included continuation. Equinix's cited service description excludes patch cables between its panels and customer equipment, so that local portion needs an identified scope and materials owner.

The practical estimating difference is the number and arrangement of local connections to accommodate. It is not a universal doubling of every cable or material line. A continuation may use several assemblies and patch points, or an existing installation may be proposed for reuse. The actual endpoint-to-endpoint arrangement determines the physical work and quantities.

References: [E1]

Look beneath the circuit identifier for the shared resource

RFC 4202, published in October 2005, defines a shared risk link group, or SRLG, around links sharing a resource whose failure may affect them all. Its concrete example is two fibers in the same conduit. A link can belong to more than one such group.

That concept explains why two logical links or two circuit identifiers are insufficient evidence of physical independence. Names distinguish connections; they do not identify every resource carrying them. A pair of routes might avoid one common resource while retaining another at a building entry, handoff or tenant continuation.

Use the shared-resource concept to ask a bounded physical question: for the event the customer wants to tolerate, which resources would affect both connections? The RFC supplies vocabulary for that question. It does not inspect a provider route or discover a tenant's physical dependencies.

References: [R1]

Worked comparison: separate routes, separate nodes, one common conduit

Consider two fictional alternatives between Site Cedar and Site Juniper. All identifiers and dependency relationships below are stipulated for explanation. The alternatives illustrate the purchase distinction; they are not representations of an actual provider installation.

Option A has route legs R1 and R2 between the sites. Both legs reach provider node C0 at Cedar and provider node J0 at Juniper. C0 presents customer handoff CH0; J0 presents JH0. There are two inter-site route legs but only one handoff node and one customer connection at each site. Another route leg does not remove C0 or J0 from the chain.

Option B instead has provider nodes C1 and C2 at Cedar and J1 and J2 at Juniper. One route leg joins C1 to J1; the other joins C2 to J2. Each node presents its own customer handoff: CH1 and CH2 at Cedar, JH1 and JH2 at Juniper. The alternative therefore presents four customer handoffs across the two sites, compared with A's two. This count describes interfaces, not individual fiber strands or an assembly bill of materials.

Now follow B into the tenant installation. Cedar continuations CL1 and CL2 run from CH1 and CH2 to their assigned tenant equipment interfaces. Stipulate that both continuations pass through the same physical conduit, CP-C. Juniper also needs continuations from JH1 and JH2, but their physical dependencies are unspecified in this example.

For an event stipulated to make both cables in CP-C unusable, both Cedar continuations would be affected despite B's separate provider nodes. Option B removes the shared provider handoff-node arrangement shown in A, while retaining a common local physical parent at Cedar. Juniper's unspecified arrangement remains unknown. The comparison identifies a remaining dependency; it supplies neither a failure probability nor a complete resilient design.

Define where an end-to-end independence claim starts and ends

Before calling two connections independent, name their customer endpoints and the failure or maintenance condition the claim covers. Provider-demarcation-to-provider-demarcation diversity and tenant-equipment-to-tenant-equipment independence cover different lengths of the physical chain. Extending the words end to end beyond the supplied evidence hides that difference.

A complete assessment would need applicable information about the transport routes and provider nodes, both delivery boundaries, local continuations and receiving equipment. Relevant shared facilities or power dependencies also need assessment where they fall within the stated requirement. Provider confirmation supports its own boundary; customer and facility information must cover the remaining portions. A diagram showing separate lines supplies no evidence for an inaccessible or undocumented segment.

In the fictional comparison, the next decision is whether the customer's requirement permits the Cedar conduit dependency. If it does, the accepted scope of that sharing should remain explicit. If it does not, the responsible owners need a suitable local design response and evidence for it. Changing the transport order alone leaves CP-C unchanged. Moving one cable to a differently named pathway would also need evidence about the underlying physical resources; a new label cannot settle the question.

There is no universal separation distance or automatic choice of tenant hardware established by this comparison. It is a buyer's method for locating the unresolved dependency, not a field procedure or authorization to alter a live connection.

References: [R1]

Keep transport resilience separate from network and workload behavior

A protection purchase defines part of the physical service arrangement. The customer network owner still has to establish how the receiving equipment uses its available interfaces, how loss is detected, and how traffic is handled under the approved design. Two connected ports do not establish a configured failover result.

Keep the evidence at its actual boundary. Provider delivery information describes the supplied transport service. Tenant installation records describe the agreed local physical work and checks. Network verification addresses the configured behavior. Application assessment addresses what the intended GPU workload does under the agreed conditions, including whether a communication interruption is acceptable to that workload.

The buyer should assign those outputs before treating a delivered service or completed cable package as overall readiness. Any operational testing needs its separately agreed method, authority and criteria. This article prescribes no failover configuration, outage exercise or workload acceptance threshold.

Bring the selected handoffs into the local installation scope

Leviathan's Colocation Installation service is the relevant starting point for discussing customer-side equipment installation and cabling inside authorized space. Structured Cabling is relevant when the requested work centers on the local assemblies, patching, routing, identification and physical connection records. The service and project-inquiry links below lead to those existing scopes.

For an initial inquiry, share a nonconfidential outline of the two site boundaries, the number and location of customer handoffs, the intended equipment endpoints and the local work still required. Identify who supplies the approved equipment and assemblies, which route questions remain open and what physical output the receiving team needs. Agree the actual tasks, access, checks, resources and availability for the engagement.

Carrier-service selection and delivery remain with the customer and provider. Leviathan's discussion concerns the customer's local physical package; it does not sell the protected transport service or establish its resilience.

References: [L1][L2]