Redundant Connectivity Through Network Edge

Here are some examples of use cases for EquinixFabric Cloud Router redundancy provided through connections with Network Edge:

• Connections to Redundant Virtual Devices

• Connections to Network Edge Clusters

• Connections to Geo-Redundant Virtual Devices

Fabric Cloud Router customers deploying multicloud applications might want to leverage a centralized redundant secure access point into remote networks. Equinix Fabric allows users to create redundant Fabric Cloud Router-to-Network Edge virtual device connections, to provide highly available internet connectivity to the private networks connected to the Cloud Router.

• Free-of-charge local connectivity between the Fabric Cloud Router and Network Edge devices, up to 1Gbps.

• Out-of-the-box redundancy within the Equinix Fabric network when creating redundant connections to redundant Network Edge devices.

• A variety of supported Network Edge virtual devices and deployment models, to provide highly available and secure connectivity.

• Flexible routing configuration options to manage route/connectivity preference between the Fabric Cloud Router and the redundant Network Edge virtual devices.

Connections to Redundant Virtual Devices

Users can create redundant connectivity to a pair of redundant Network Edge devices, which act as active/active standalone virtual devices. More information on redundant Network Edge devices is available at High Availability Options in Network Edge.

Additionally, a Device Link Group (DLG) can be used to provide connectivity between the redundant virtual devices, for high availability management. See Device Link for more details.

Route preference between the Fabric Cloud Router and the virtual devices can be influenced by using well-known Border Gateway Protocol (BGP) attributes. This allows customers to ensure that all traffic is sent on the primary connection to the primary virtual device. The secondary connection can be used as a failover connection for traffic.

One way to ensure that the primary connection and the virtual device are preferred for traffic is to use the following BGP configuration on the virtual devices:

• To influence traffic from the virtual devices to the Cloud Router:

  • Configure a higher Weight for routes learned from the Cloud Router on the Primary Virtual Device.

  • Alternatively, if weight is not supported on the virtual device, you can configure a higher Local Preference for routes learned from the Fabric Cloud Router on the Primary Virtual Device.

• To influence traffic from the Cloud Router to the virtual devices:

  • For the default routes advertised from the Secondary Virtual Device, you can leverage AS Prepend to inform the Cloud Router that this route is less preferred.

Upon failure of the primary virtual device or primary connection, traffic from the Cloud Router fails over to the secondary connection.

Connections to Network Edge Clusters

Cloud Router users can create redundant connectivity to Network Edge cluster, which acts as a pair of active/standby virtual devices. More information on Network Edge clusters is available at High Availability Options in Network Edge.

For customers deploying redundant topologies using Network Edge clusters, the active node in the cluster can be considered as the owner of both BGP sessions/connections with the Fabric Cloud Router. Redundancy is provided for both connections and Network Edge cluster nodes.

Route preference between the Cloud Router and Network Edge cluster can be influenced by using well-known BGP attributes. This allows customers to ensure that all traffic is sent on the primary connection to the primary virtual device. The secondary connection can be used as a failover connection for traffic. Remember that the active node is the owner of both BGP sessions, so BGP configuration across both nodes should be the same.

One way to ensure that the primary connection is preferred for traffic is to use the following BGP configuration on the cluster nodes:

• To influence traffic from the cluster Nodes to the Cloud Router:

  • Configure a higher Weight for routes learned from the Cloud Router on the Primary Connection for both nodes.

  • Alternatively, if weight is not supported on the virtual devices, you can configure a higher Local Preference for routes learned from the Cloud Router on the Primary Connection on both nodes.

• To influence traffic from the Cloud Router to the cluster nodes:

  • For the routes advertised from the Secondary Connection on both nodes, you can leverage AS Prepend to inform the Cloud Router that this secondary path is less preferred.

Upon failure of the primary connection, traffic from the Cloud Router fails over to the secondary connection.

Failure of the primary node in the Network Edge cluster maintains the primary BGP session active towards the Cloud Router, but this is now active on the secondary node.

Connections to Geo-Redundant Virtual Devices

Users can leverage IP-WAN networks and single connections from a pair of Fabric Cloud Routers to redundant Network Edge devices located in different metro locations. These virtual devices are considered geo-redundant. This redundancy architecture aims to protect against datacenter failure in a particular location. More information on geo-redundant Network Edge devices is available at Achieve Resiliency through Geo-Redundancy.

This use case enables users to connect cloud applications and other Equinix Fabric assets to redundant virtual devices that are located in two different metro locations.