Network Edge

We’re rolling out a major update designed to give you more control, deeper visibility, and fewer infrastructure headaches. We’ve officially added a dedicated 30 GB local logging storage allocation directly to your Fortinet (FTNT) firewalls. This means your device now has a massive, built-in buffer to retain traffic logs, threat logs, event logs, and policy violation records completely on-device.Fortinet Virtual FirewallWhy this matters for you?If you've ever had to hunt down a network issue or investigate a security alert, you know that getting to your logs quickly is everything. In the past, relying solely on external syslog servers or SIEM forwarding could sometimes mean dealing with latency, complex setups, or even temporary gaps in data.By bringing 30 GB of storage directly to the firewall, we're eliminating those hurdles.What you get:Instant Troubleshooting: Access historical log data right from the device the second you need it. No more waiting on external queries. Sharper Forens

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-connectionThis 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 versionterraform {  required_providers {    equinix = {      source  = "equinix/equinix"      version = "~> 1.26.0"    }  }}When using new versions error occurs. F

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? C

In this video, we'll cover the features that are included in the latest Network Edge release. With Cisco SolutionsPlus, customers can now order Network Edge products directly from Cisco. We are now offering Blue Cat Edge as part of our existing Blue Cat solution on Network Edge. See what's new with Network Edge today: https://fabric.equinix.com/

Hi team,  Could someone explain the new BlueCat offering on Equinix Network Edge?

Is it possible to connect Network Edge devices to Fabric Cloud Router?

Hello everyone, We're using Virtual circuits between Fabric ports & Edge virtual devices, it works fine but still it's impossible to get the link usage statistics as for other circuits.Any news about that option that is missing? Thanks 🙂

 I saw that Equinix now offers subscription licenses for the Cisco 8KV on Equinix Network Edge.  Does this support 16 core/8G memory devices?

Can anyone explain what kind of support is available for the Cisco Catalyst 8000V?

Do you have Equinix-configured Cisco CSR1000V Network Edge devices? Make sure you migrate them using the info below:

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 ArchitectureNetwork 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 networkThe 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 vario

Can I deploy Zscaler on Equinix?

What are virtual device interface statistics on Network Edge?

I've heard about the new Zscaler offering -- what is it?

..

This is the second 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 Device Link Group (DLG) connections. For more information on Device Link Resiliency please refer to the Equinix docs page here.Device Link Groups are used to connect Network Edge device interfaces to other Network Edge device interfaces​ They can be local (same metro) or remote and are a shared broadcast domain​ A single DLG, like a single Ethernet cable, provides no resiliency​ Local DLGs do not traverse the Equinix Fabric and aren’t susceptible to Fabric switch outages ​ Hybrid DLGs have some devices connected to the Primary Fabric plane and other to the Secondary​ Customers that require maximum resiliency should deploy additional DLGs that connect to both the Primary and Secondary Fabric networks​ Redundant Devices can have one or both devices connect to the DLG​ Clustered devices act as one log

This is the fourth and final 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 Fabric Virtual Connections.Virtual connections allow NE devices to connect to CSPs, NSPs and ISPs as well as co-location​ The same logic still applies: the NE device plane determines which Fabric switch is used​ The VC connection workflow is very similar to the EVP-LAN workflow with some differences​ Customers that require VC link resiliency should create two or more VCs to their NE devices with each connection traversing the Primary and Secondary fabric switch​ Some CSPs like Azure require resiliency but most do not​ The Fabric portal allows connections to be created as redundant or single-legged​ The workflow is highlighted in the next few slides for both Redundant and Clustered devicesRedundant Devices Clustered Devices This concludes a four part series on building Highly Resilient Net

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 i

Are there any tools available to help me migrate my Equinix-Configured CSR1000V to the Self-Configured C8000V version? 

If I want to replace my Network Edge device due to issues with the VNF, am I able to recover my initially provisioned device?

To help you connect, we have added "connectToCloudVision," "cvpType," "cvpFqdn," "cvpIpAddress," "cvaasPort," "cvpPort," and "cvpToken" fields. Check out the following pages for details: Launch Self-Configured Device Get Virtual Devices Get Virtual Device {uuid}  

..

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.