Skip to main content

Connection Resilience and Redundancy

In addition to deploying redundant Fabric ports, when creating connections using Equinix Fabric, consider the following recommendations to take advantage of Equinix Fabric's highly resilient and highly available underlying network architecture.

Bidirectional Forwarding Detection (BFD)​

For Layer 2 services, Equinix Fabric is transparent to Bidirectional Forwarding Detection (BFD) protocol. If you want to run BFD across a Layer 2 connection, set your timers as shown:

  • Intra-metro - 100ms x 3 = 300ms
  • Intra-region - 300ms x 3 = 900ms
  • Inter-region - 500ms x 3 = 1500ms

These recommended BFD timer values are calculated based on the delay (latency/distance) of the connection.

Because BFD relies on the timely arrival of control packets, the physical distance between endpoints (propagation delay) and the number of network hops (potential jitter) are factors.

Because one-way delay is used for standard asynchronous BFD and round-trip delay when implementing BFD echo mode, we use the higher of the two (round-trip used for echo mode) as the basis of our recommendations.

To mitigate for false positives (flapping), we recommend a standard multiplier of 3 to allow for two lost or delayed packets without triggering a failure and dropping the session. If the third packet is also missed, this indicates a genuine link failure.

The recommended values are based on geographic latency domains rather than a one-size-fits-all.

Multipoint Networks​

The SLA for connections to multipoint networks (E-LAN and E-Tree) is 99.9% for single connections to the network. A redundant connection to a network where the connection is created on both primary and secondary ports has an SLA of 99.999%.

Although E-LAN and E-Tree networks themselves are neither inherently primary or secondary, if you want to achieve the highest possible level of availability and resiliency, it is recommended that you create two discrete networks, and create connections exclusively on primary ports or primary Network Edge devices into the one and similarly connections exclusively on secondary ports and secondary devices into the other.

Point-to-Point Connections​

Equinix Fabric adheres to an availability SLA of 99.9% for a single connection and 99.999% for redundant connections. Connections are considered redundant when two connections that are part of the same service are created with one on a primary port and another on a secondary port.

For more detail on our SLA please see Equinix Fabric Product Policy.

It is important that when you create connections, the origin and destination ports are of the same priority.

For example, create a primary connection where both the origin and destination ports are primary ports and create a secondary connection where both the origin and destination ports are secondary ports.

In this way you can be confident that connections are built in the most resilient manner and minimize exposure to both planned and unplanned outages.

Connecting Your Own Assets​

Ensure that your origin port (A-side) and your destination port (Z-side) are of the same priority. To create redundant connections between ports:

  • First, create a connection on a primary port and select a primary port for the destination port.
  • Then, create a connection on a secondary port and select a secondary port for the destination.
  • Adhering to this convention of provisioning between assets of the same priority reduces exposure to outages (both planned and unplanned) on your virtual connection.

Connecting to a Generic L2 Service Provider​

When you connect to a service provider, it is the service provider's responsibility to accept the connection request on a port that is the same priority as the port that the connection request came from.

The service provider is presented with a warning if they attempt to accept a connection on a port that has a mismatch in priority.

Connecting to a Global CSP​

Global Cloud Service Providers (CSPs) such as AWS, Azure, GCP, Oracle, IBM, Alibaba are API integrated and provisioning is automated to always enforce the logic of primary (origin) to primary (destination) so that the connections are always provisioned optimally.

For example, if you create a connection from your primary port then the connection terminates on another primary port facing the CSP. Similarly, if you create a connection from your secondary port, the connection terminates on a secondary port facing the CSP. If available, you can create redundant connections to a CSP that creates both connections from your primary and secondary ports to primary and secondary ports facing the CSP.

For further best practices on architecting for resiliency that are provider-specific, refer to Connecting to a Cloud Service Provider. Or one of the examples below:

Connecting to Other Fabric Customers Using a Z-side Service Token​

If you attempt to create a connection between your origin (A-side) port and a Z-side service token (destination) and there is a mismatch between the priority of your origin port and the destination port associated with the service token, the Portal returns a warning.

You should either select a different port for the origin or contact the issuer of the Z-side token for a new token that is of the correct priority for the connection you want to create.

Checking Existing Connections Priority​

You can check to see if any of your existing connections have a mismatch in priority. Both your Connections Inventory and the Connection Details have a Priority Mismatch indicator if an existing connection has a mismatch in priority between the origin and the destination.

In the Connections Inventory:

In the Connection Details, Origin tab:

You can also compare the port priority in the Connection Details Origin tab with that of the Destination tab to confirm how the connection is mismatched.

Correcting a Mismatch in Priority​

Connections to your own assets

If you own both the origin (A-side) and destination (Z-side) ports of the connection, you can either:

Connections to service provider

Connections to another customer using a Z-side service token

  • If the origin (A-side) port is the cause of the mismatch, migrate the A-side of the connection to a port of the correct priority.

  • If the destination (Z-side) port is the cause of the mismatch, contact the token issuer for a new service token of the correct priority and recreate the connection.

Was this page helpful?