This is first part of a series of posts highlighting the best practices for customers who require highly resilient networks in Network Edge. This entry will focus on the foundational architecture of Plane A and Plane B in Network Edge and how these building blocks should be utilized for resiliency.
Network Edge is built upon a standard data center redundancy architecture with multiple pods that have dedicated power supplies and a dedicated Top of Rack (ToR) switch.
It consists of multiple compute planes commonly referred to as Plane A and Plane B for design simplicity
Plane A connects to the Primary Fabric network and Plane B connects to the Secondary Fabric network
The most important concept for understanding Network Edge resiliency: the device plane determines which Fabric switch is used for device connections. Future posts will dive much deeper in the various ways that Network Edge devices connect to other devices, Clouds and co-location.
While referred to as Plane A and Plane B, in reality there are multiple compute planes in each NE pod
The actual number varies based on the size of the metro
This allows devices to be deployed in a manner where they are not co-mingled on the same compute plane, eliminating compute as a single point of failure
Network Edge offers multiple resiliency options that can be summarized as device options and connection options
Device options are local and provide resiliency against failures at the compute and device level in the local metro
This is analogous to what the industry refers to as ”High Availability (HA)”
Connection resiliency is a separate option for customers that require additional resiliency with device connections (DLGs, VCs and EVP-LAN networks). This will be discussed in depth in separate sections.
It is common to combine both local resiliency and connection resiliency, but it is not required—ultimately it depends on the customer’s requirements
Geo-redundancy is an architecture that expands on local resiliency by utilizing multiple metros to eliminate issues that may affect NE at the metro level (not covered in this presentation)
Single devices have no resiliency for compute and device failures
The first single device is always connected to the Primary Compute Plane *
Single devices always make connections over the Primary Fabric network
Single devices can convert to Redundant Devices via the anti-affinity feature
Anti-Affinity Deployment Option
By default single devices have no resiliency
However, single devices can be placed in divergent compute planes. This is commonly called anti-affinity and is part of the device creation workflow
Checking the "Select Diverse From" box allows customers to add new devices that are resilient to each other
Customers can verify this by viewing their NE Admin Dashboard and sorting their devices by "Plane"
This feature allows customer to convert a single device install to Redundant Devices
By default, the first single device was deployed on the Primary Fabric
The actual compute plane is irrelevant until the 2nd device is provisioned
The 2nd device is deployed on the Secondary Fabric AND in a different compute plane than the first device
Resilient Device Options
These options provide local (intra-metro) resiliency to protect against hardware or power failures in the local Network Edge pod
By default, the two virtual devices are deployed in separate compute planes (A and B)
In reality there are more than two compute planes, but they are distinct from each other
The primary device is connected to the Primary Fabric network and the secondary/passive device is connected to the Secondary Fabric network
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
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 config 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, Clustered devices can only be deployed in the same metro
Fortinet, Juniper, NGINX and Palo Alto
The next post will cover the best practices for creating resilient device connections with Device Link Groups and can be found here.
Equinix is the world's digital infrastructure company. Digital leaders harness our trusted platform to bring together and interconnect the foundational infrastructure that powers their success. We enable our customers to access all the right places, partners and possibilities they need to accelerate advantage.