What’s the quickest and slowest deployment in your career?
Minutes? Hours? Days? Months? Years? Let’s hear it! Don’t settle for months, you’ve got Equinix within minutes. Be the first to test drive Equinix Deploy and use our self-service capabilities across Equinix Metal, Equinix Network Edge and Equinix Fabric.New Feature - Equinix Status
Starting today you can check the status of your network products on the new Equinix Status page. View status by product and metro for Equinix Connect, Equinix Fabric, Equinix Internet Exchange, Equinix Metal, Equinix Precision Time, Metro Connect and Network Edge. Be sure to bookmark the https://status.equinix.com/ page. We'd love to hear your thoughts, give feedback online or comment below. Learn more about Equinix Status by reading the documentationBuilding Highly Resilient Networks in Network Edge - Part 1 - Architecture
This is first part of a series of posts highlighting the best practices for customers who desire 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. For more information on Network Edge and device plane resiliency please refer to the Equinix Docs page here. Dual Plane Architecture 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 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 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 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 Vendor Support All Vendors 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.
Great video to share with anyone new to interconnection and data centers
Hi All - New to the community and looking forward to connecting and learning! If you or any new hires on your team (or your mom!) are new to interconnection, ecosystems and data centers, this short “Where is the Physical Internet?” video from investment company Cowen is an excellent intro from the consumer perspective. It's a 9-minute walk-through of Equinix’s NY5 facility that includes insight into the physical infrastructure responsible for securing, cooling/powering, and connecting a modern data center. During the tour, you’ll also learn about the ecosystems at the NY5 data center that attract companies to interconnect there. The video is meant for anyone interested in learning more about where and how data is stored and exchanged. Hope you like it as much as I do!
New Term-Based Discounts for Equinix Fabric Are Here
We're excited to introduce Equinix Fabric Term-Based Discounts for inter-metro i.e. remote virtual connections (VCs) between your own assets and to your service providers including hyperscalers such as AWS, Azure, Google Cloud and Oracle. This new pricing option is designed to help you save more while enjoying the high-performance connectivity you rely on. What's New? You now have the option to select 12, 24, or 36-month contracts for inter-metro VCs from your Fabric ports, Network Edge virtual devices and Fabric Cloud Router instances. Here's how you'll benefit: Lower Monthly Rates: Save between 15% and 50% compared to on-demand pricing. For example, a 1 Gbps inter-metro virtual connection between London to New York drops from $1005/month to just $503/month with a 36-month term-based plan. See how much you can save using the Fabric pricing calculator, accessible via the Fabric portal. Simple Provisioning: No approvals required. Just select your term in the self-service portal or Fabric API and enjoy the savings. Broad Capability Support: Applicable across Point-to-Point (EPL & EVPL), Multipoint-to-Multipoint (EP-LAN & EVP-LAN) and IP-WAN services supported by Fabric Cloud Router. Also supported for Z-side service tokens. Predictable Cost Structure: Term based contracts provided set monthly rates, making it easier for you to manage your annual budget. Things to Note Discounts are available only for inter-metro VCs (intra-metro i.e. local VCs are not eligible. Discounts are currently not supported on Network Edge virtual devices to AWS, but are coming soon. Term-based discounts cannot be added to existing VCs, so you’ll need to create a new VC with your chosen term. Why This Matters By locking in discounted rates, you can optimize costs and achieve predictable spending without sacrificing performance, reliability, or flexibility. This is the perfect opportunity to create cost-efficient connectivity solutions tailored to the demands of your business. We'd Love to Hear From You Tap into these savings today by selecting a term-based discount during your next VC provisioning. We’d love to hear how this pricing option benefits your operations. Share your feedback with the team!Tech Note: Using BGP Local-AS with Equinix Internet Access over Fabric (EIAoF) and Network Edge
Welcome to the Equinix Community! We know you’re always looking for ways to maximize your connectivity, and sometimes technical limitations can be a hurdle. This post dives into a handy BGP feature called Local-AS that helps our Equinix Internet Access over Fabric (EIAoF) customers navigate a current setup requirement. We’ll provide a brief description of BGP Local-AS, a high-level overview of how it works in practice, and how it enables you to maintain your public Autonomous System Number (ASN) while at the same time using an Equinix-assigned private ASN currently required by EIAoF. What is BGP Local-AS? BGP Local-AS is a feature supported by most major network vendors that lets a BGP-speaking device appear to belong to an ASN different from its globally configured one. While it’s not part of the official BGP standard, it’s a powerful feature typically used during major network events like merging autonomous systems or transitioning to a new ASN. For EIAoF customers, it provides a clean, effective method to accommodate the current requirement to use a private ASN for your BGP session. The best part? Once EIAoF is updated to fully support public ASNs, you can simply remove the Local-AS configuration, or even leave it in place until you’re ready for a future transition! How BGP Local-AS Works with EIAoF The picture below provides only the relevant configuration snippets needed to convey the concept of using BGP Local-AS. It's presented using classic, non Address Family Cisco configuration syntax. An explanation of the relevant configuration variables and commands are explained below the picture. This short post is only intended to help readers understand how local-as can be used with EIAoF and is not intended to represent a complete BGP configuration nor an in-depth overview of local-as capabilities. Figure 1 – BGP Local-AS Example Dynamic Configuration Variables Equinix Assigned Primary IPv4 Peering Subnet: 192.0.2.0/30 Equinix Assigned Secondary IPv4 Peering Subnet: 192.0.2.4/30 Equinix Assigned Private ASN: 65000 Customer Public Autonomous System Number (ASN): 64500 Customer Public IPv4 Prefix: 203.0.113.0/24 A Side Key Configuration Command References router bgp 64500 ⬅️ Customer’s public ASN Customer router BGP ASN. This is the ASN BGP speakers use for peering (when not using local-as.) neighbor 192.0.2.1 remote-as 15830 ⬅️ EIA public ASN Defines the BGP connection to the EIA edge gateway router. neighbor 192.0.2.1 local-as 65000 ⬅️ Equinix Assigned Private ASN This makes the EIA edge gateway see this peer as belonging to the private AS 65000 instead of 64500. This router will also prepend AS 65000 to all updates sent to the EIA edge gateway. EIA Edge Gateway Router A *> 203.0.113.0 192.0.2.2 0 0 65000 64500 i The output above is an excerpt from the BGP table on the example EIA router A edge gateway. The fact this prefix appears in the BGP table with the associated ASNs confirms successful peering between EIA and the customer router using AS 65000. You can also see the AS-PATH of the prefix received lists the customer’s real AS, 64500, as the origination AS with the private ASN, 65000, prepended to it. When EIA advertises this prefix to external peers it will strip the private ASN, 65000, and prepend 15830 in its place. This will result in external peers seeing the 203.0.113.0/24 prefix with an AS-PATH of 15830 64500. Important Routing Security Requirement To ensure successful service provisioning with EIA, you must have the necessary Route Objects (RO) defined. Route Object (RO) When using an Equinix-assigned private ASN, you are required to create, or have created, a Route Object (RO) that matches your advertised prefix with the Equinix ASN (15830). If this RO does not exist your EIA service order will fail. Best Practice Recommendations It is recommended to also create a Route Origin Authorization (ROA) using RPKI for improved security and validation. We also strongly recommend that you ensure there is an RO that matches your public ASN to the prefix in addition to the one for ASN 15830. If you have any questions, please share in the comments below! 👇Building Highly Resilient Networks in Network Edge - Part 3 - EVP-LANs
This is the third part of a series of posts highlighting the best practices for customers who require highly resilient networks in Network Edge. This entry highlights how to build resilient EVP-LAN connections in Network Edge. EVP-LAN is another method to connection Network Edge devices EVP-LANs differ from DLGs in that they connect to Network Edge devices and Fabric ports All EVP-LAN connections go to the Fabric, even for devices in the same metro--this is in contrast to DLGs which can be local or remote. As of November 2023, multiple NE devices in the same metro can be part of the same EVP-LAN network, removing the previous restriction of a single NE device per metro. Customers that require maximum resiliency should deploy additional EVP-LANs that span both the Primary and Secondary Fabric networks The same logic applies for EVP-LANs such that they should spread across Primary and Secondary Fabric planes The current maximum bandwidth for all EVP-LAN connections in the same metro is 10GB. This may change in the future. Redundant Devices For proper resiliency, each device in the Redundant Device pair will require a single connection to two different EVP-Networks The Primary device on the Primary plane will use the Primary Fabric switch The Secondary device on the Secondary plane will use the Secondary Fabric switch Clustered Devices Clustered devices are different in that the workflow allows connections to be built to either the Primary or Secondary Fabric For proper resiliency, each node in the Cluster will require a single connection to two different EVP-Networks The next post will cover the best practices for creating resilient Fabric Virtual Connections. You can read the first part of this series here.Network Edge Interface Statistics
Now you can monitor your Network Edge device utilization traffic by accessing your device details. In your Virtual Device Inventory, click on the device you want to monitor. In the Device Details, click the Interfaces tab. Expand the arrow next to the port you want to monitor and a graph will display showing Inbound and Outbound traffic for the last 7 days. Refresh the graph by clicking Refresh. Change the duration using the drop-down. Choose Last 7 days or Last 24 hours.
