Virtual Connection Resiliency
Virtual connections allow you to specify the level of resiliency your deployment requires. The workflows are flexible, allowing for multiple scenarios to accommodate redundancy, if required.
Virtual connection workflows differ between Redundant and Cluster deployments. Redundant device connections originate from each individual virtual device in the redundant pair, while clustered device connections originate from the cluster.
Redundant Virtual Connections
Redundant devices are deployed on different compute planes using affinity. Once deployed, the devices do not share any configuration information and function as two independent devices. To achieve redundancy through to the Fabric participant, you create virtual connections on the Primary and Secondary Fabric as shown below. Primary plane connects to the Primary Fabric network (or Primary Fabric Plane) and Secondary plane connects to the Secondary Fabric network.
This is one of the most important concepts for understanding Network Edge resiliency. The device plane determines which Fabric network (or Fabric Plane) is used for device connections.
Redundant devices can be deployed in the same metro or in different metros allowing you to build redundant solutions that span geographic distances. Workflows are flexible and you can create connections on both the primary and secondary Fabric plane or on each plane as needed for your use-case.
Cluster Virtual Connections
Clustered devices are deployed on primary and secondary compute planes and have higher-level workflows to build either an Active-Active or Active-Standby pair of virtual devices.
Clusters can be built in the same metro only. For example, if a virtual circuit is built on both the primary and secondary Fabric plane, the workflow will create two connections to the cluster and assign an interface for each connection to both Cluster nodes. The image below (Connecting to Same Metro/Same Provider) shows a primary and secondary Fabric connection to an Active-Standby cluster with cluster-node0 active and cluster-node1 standby. In the event of a cluster failover and cluster-node1 becomes active the connections are moved to cluster-node1.
Redundant Devices | Clustered Devices | |
---|---|---|
Deployment | Two devices, both Active, appearing as two devices in the Network Edge portal. Both devices have all interfaces forwarding | Two devices, only one is ever Active. The Passive (non-Active) device data plane is not forwarding |
WAN Management | Both devices get a unique L3 address that is active for WAN management | Each node gets a unique L3 address for WAN management as well as a Cluster address that connects to the active node (either 0 or 1) |
Device Linking Groups | None are created at device inception | Two are created by default to share configuration synchronization and failover communication |
Fabric Virtual Connections | Connections can be built to one or both devices | Single connections are built to a special VNI that connects to the Active Cluster node only. Customer can create optional, additional secondary connection(s) |
Supports Geo Redundancy | Yes, Redundant devices can be deployed in different metros | No, Cluster devices can only be deployed in the same metro |
Vendor Support | All vendors | Fortinet FortiGate FirewallsJuniper vSRX FirewallsNGINX PlusPalo Alto VM-Series Firewalls |
All scenarios shown in the following illustrations assume the Provider participant connects to both the Primary and Secondary Fabric. If there are any questions about redundant Fabric connections, consult with your Equinix Global Solution Architect.
Connecting to Same Metro/Same Provider
Use this connection scenario to connect to the same provider using Network Edge devices in the same metro location. In this scenario, Network Edge supports both Redundant and Cluster deployments. Virtual circuit workflows ensure each circuit is provisioned on the Primary and Secondary Fabric planes, respectively. An example is redundant connections to the same Fabric participants.
Connecting to Same Metro/Different Providers
Use this connection scenario to connect to different providers using Network Edge devices in the same metro location. In this scenario, Network Edge supports both Redundant and Cluster deployments. Virtual circuit workflows ensure each circuit is provisioned on the Primary and Secondary Fabric planes, respectively. An example is redundant connections to different Fabric participants.
Connecting to Different Metro/Same Provider
Use this connection scenario to connect to the same providers using Network Edge virtual instances in different metro locations. In this scenario, Network Edge supports Redundant deployments but does not support Cluster deployments. Virtual circuit workflows ensure each circuit is provisioned on the Primary and Secondary Fabric planes, respectively. An example is redundant connections from two different metros to the same Fabric participant.
Connecting to Different Metro/Different Providers
Use this connection scenario to connect to different providers using Network Edge devices in different metro locations to different Fabric participants. In this scenario, Network Edge supports Redundant deployments but does not support Cluster deployments. Virtual circuit workflows ensure provisioning for each circuit on the Primary and Secondary Fabric planes, respectively. An example is redundant connections from two different metros to the different Fabric participants.
EVP-LAN Networks
Network Edge supports EVP-LAN connection to allow multipoint-to-multipoint networking. EVP-LAN enables you to interconnect your data center assets across many locations through a common network instead of requiring direct connections between individual locations. This topic describes how to create a private multipoint-to-multipoint network and connect to that network from your Network Edge devices.
EVP-LANs differ from the DLGs in that they connect to Network Edge devices and Fabric ports. Multiple Network Edge devices in the same metro can be part of the same EVP-LAN network. Customers that require maximum resiliency should deploy additional EVP-LANs that span both the Primary and Secondary Fabric networks.
For proper resiliency, each device in the Redundant device pair will require a single connection to two different EVP-LAN networks. The Primary device on the Primary plane will use the Primary Fabric network. The Secondary device on the Secondary plane will use the Secondary Fabric network.
Clustered devices are different in that the workflow allows connections to be built to either the Primary or Secondary Fabric networks.