network edge
125 TopicsTech Note: How BGP Local-AS Works with Equinix Internet Access over Fabric (EIAoF)
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! 👇85Views3likes0Comments3 Multicloud Network Designs for Simplified Multicloud Connectivity
If your organization is juggling multiple clouds, there’s a good chance network complexity is clogging progress. What if there were structured, strategic configurations that simplify multicloud connectivity—so you could scale with confidence and clarity?37Views0likes0CommentsThe Data Center is Evolving - Are You?
Times moves fast...don't they? As the line between public and private cloud continues to blur, we're seeing the very definition of "data center" evolve right alongside it. Colocation, edge, interconnection - these aren't just technologies anymore. They're becoming foundational building blocks in how hybrid cloud actually operates today. We used to think of hybrid as static: pair a hyperscaler with some on-prem gear and bada-bing, bada-boom, call it a day...right? Wrong. That model no longer cuts it. Now, we're watching new hybrid patterns emerge that are more agile, distributed, and value-driven. Let's face it, it's no longer about where the workloads are - it's about how infrastructure adapts to optimize performance, cost, and connectivity in real-time. What are you seeing in your markets? Are you rethinking their hybrid strategies through the lens of colocation and interconnection? Are edge facilities shifting the center of gravity? Would love to hear your take - what are your thoughts?57Views0likes0CommentsSimplify App Delivery and Security with F5 and Equinix
Want to simplify global application deployment and secure partner access without physical infrastructure? Join F5 and Equinix on our upcoming webinar to discover how F5 Distributed Cloud Services on Equinix Network Edge can help you accelerate time-to-market, optimize costs, and maintain compliance. Secure your spot now by RSVPing here and learn how to simplify infrastructure for distributed AI applications. Featured Speakers: Rahul Phadke, Director of Product Management at F5 Joe Kanagusuku, Business Development Manager at F5 Mandar Joshi, Director of Product Management at Equinix37Views1like0CommentsNew 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!137Views4likes0CommentsIssues deploying Equinix Connections
I have managed to use several terraform modules without problem. I have used the palo alto cloudgenix vm modules, palo alto firewalls modules, device link modules, and fabric cloud router module. All work okay on the lastest version of equinix/equinix. However as I dive into other connections I get a lot version issues. For example. Leveraging the cloud-router-port connection. https://registry.terraform.io/modules/equinix/fabric/equinix/latest/examples/cloud-router-2-port-connection This would be used to connect the cloud router to the pa firewall mgmt interface. Documentation covers the following version. required_providers { equinix = { source = "equinix/equinix" version = ">= 2.9.0" } } } But code doesnt work without this version terraform { required_providers { equinix = { source = "equinix/equinix" version = "~> 1.26.0" } } } When using new versions error occurs. Failure. Ive redone this several times in my code base. ephemeral.aws_secretsmanager_secret_version.equinix_iac_credentials: Opening... ephemeral.aws_secretsmanager_secret_version.equinix_iac_credentials: Opening complete after 0s module.equinix_deployment.module.fw-mgmt-to-fcr-connection-ch-1a.equinix_fabric_connection.this: Creating... ╷ │ Error: 400 Bad Request Code: EQ-3142558, Message: Json syntax error, please check request body, Details: Unknown json property : aSide.accessPoint.router.package.code. Unexpected value '' │ │ with module.equinix_deployment.module.fw-mgmt-to-fcr-connection-ch-1a.equinix_fabric_connection.this, │ on ..\..\modules\cloud-router-2-port-connection\main.tf line 1, in resource "equinix_fabric_connection" "this": │ 1: resource "equinix_fabric_connection" "this" { I can get past this error and deploy the connection with an older version but then run into version issues when attempting to leverage the virtual-device-2-eia-connection https://registry.terraform.io/modules/equinix/fabric/equinix/latest/examples/virtual-device-2-eia-connection here the primary problem is that on older versions. there is no resource virtual-device-connection. only fabric-device-connection. One thought is to completely separate the fabric cloud router to port module Here is the original cloud router to port module main.tf resource "equinix_fabric_connection" "this" { name = var.connection_name type = var.connection_type bandwidth = var.bandwidth notifications { type = var.notifications_type emails = var.notifications_emails } a_side { access_point { type = "CLOUD_ROUTER" router { uuid = var.aside_fcr_uuid } } } z_side { access_point { type = var.zside_ap_type virtual_device { type = var.zside_vd_type uuid = var.zside_vd_uuid } interface { type = var.zside_interface_type id = var.zside_interface_id } location { metro_code = var.zside_location } } } order { purchase_order_number = var.purchase_order_number } } variables variable "connection_name" { type = string description = "Name of the Fabric connection" } variable "connection_type" { type = string description = "Type of the Fabric connection (e.g., IP_VC)" } variable "bandwidth" { type = number description = "Connection bandwidth in Mbps" } variable "notifications_type" { type = string default = "ALL" description = "Notification type" } variable "notifications_emails" { type = list(string) description = "Emails for notifications" } variable "purchase_order_number" { type = string default = "" } variable "aside_fcr_uuid" { type = string description = "UUID of the FCR device" } variable "zside_ap_type" { type = string default = "VD" } variable "zside_vd_type" { type = string default = "EDGE" } variable "zside_vd_uuid" { type = string } variable "zside_interface_type" { type = string default = "NETWORK" } variable "zside_interface_id" { type = number } variable "zside_location" { type = string } versions.tf terraform { required_providers { equinix = { source = "equinix/equinix" version = "~> 1.26.0" } } } module module "fw-mgmt-to-fcr-connection-ch-1a" { #FCR Router to FW Management Interface Connection source = "../../modules/cloud-router-2-port-connection" connection_name = "fcr-2-fw-mgmt-ch" connection_type = "IP_VC" bandwidth = 50 notifications_type = "ALL" notifications_emails = var.notifications purchase_order_number = "mgmt-connection" #aside Fabric Cloud Router aside_fcr_uuid = module.fcr_ch.id #zside Palo aAlto Firewall zside_ap_type = "VD" #Virtual Device zside_vd_type = "EDGE" zside_vd_uuid = module.pa_vm_ch.id zside_interface_type = "NETWORK" zside_interface_id = 1 # Palo Alto Firewall Management Port zside_location = "CH" #metro code }Solved228Views1like5CommentsTerraform Module Equinix Internet Access. Does it exist?
I scavenged the terraform registry looking for a Equinix Internet Access Terraform module. ] I found an example of a connection to EIA.This is the only thing that comes up in the registry as EIA. https://github.com/equinix/terraform-equinix-fabric/tree/v0.22.0/examples/virtual-device-2-eia-connection But none that creates the EIA itself. Can anyone answer if this may or may not be supported in terraform and if so, what would the resource name be for it? The GUI terminology doesn't always translate one for one, so maybe I'm missing something.106Views0likes2CommentsNeed DDI In the Cloud? Infoblox is Now on Network Edge
Hey everyone—just popping in with some exciting news for those of you building out your virtual networking environments! Infoblox NIOS DDI is now available on Equinix Network Edge 🙌 That means you now have another core piece of your networking stack—DNS, DHCP, and IP address management (IPAM)—available as a virtual networking function alongside firewalls, routers, SD-WAN, and more. What this unlocks for you? Whether you’re working across hybrid or multi-cloud environments, having your full stack available virtually means you can deploy faster, scale smarter, and keep everything centralized—all without touching hardware. Already using Infoblox on-prem? You can now extend those services to the cloud and manage everything through Network Edge. Need better automation? Infoblox helps eliminate manual IPAM tasks and streamlines network provisioning. Focused on security? Built-in Protective DNS helps block threats before they reach your network. Building for scale? Combine Infoblox with other Network Edge VNFs for a complete, cloud-ready networking solution. And yes—it’s available to deploy via the portal, APIs, or Terraform, so you can integrate it however you work best. 👉 Check out the blog post here if you want a deeper dive or to explore use cases. Would love to hear how you’re thinking about virtualizing more of your network stack—or if you’ve already started using Network Edge and want to add Infoblox into the mix. Drop your thoughts or questions below!91Views2likes0CommentsBoost Your Multicloud Strategy with High-Performance Connectivity
Experts from Equinix and Oracle are going to show you how to boost your multicloud strategy with high-performance connectivity. Discover how Oracle Cloud Infrastructure (OCI) via FastConnect enables essential private, dedicated, high-bandwidth connectivity. Key Topics: Predictions and trends for multicloud Oracle Cloud Infrastructure (OCI) distributed cloud Multicloud use cases and challenges How to connect to multiple clouds High-performance cloud-to-cloud connectivity solution Multicloud data integration architecture Fabric Cloud Router Learn more about Equinix and Oracle solution
49Views1like0Comments