Each Network Edge device loads out for the first time with a specific configuration. This configuration may vary significantly, depending on the vendor. This series of documents will not cover every device in depth, but will share relevant examples. There are also several basic and common elements found in most devices.
During device creation, a best practice configuration is applied for all initial global settings. In addition to the global settings that are common to all, local settings that define interfaces, layer-3 virtualization, access-lists and routes for remote reachability are applied.
This final configuration is a combination of:
- User-defined inputs via the portal or API
- Standard templates that lay the foundation for cloud connectivity
- Pre-loaded inventory items from our internal orchestration (such as unique IP addresses)
Although there is no practical effect or user impact at this time, Equinix deploys using an OpenStack environment, and uses the same tenant for multiple devices deployed by the same account in the same metro. In the future, this will allow additional choices and interactions between the devices you have deployed.
Unless specifically mentioned otherwise, most devices will boot up with at least 10 interfaces active, and some devices show these under the interfaces tab in device details. As of the publish date, some devices do not display in interface tab but will be coming soon.
Equinix has determined that most use cases will not require any more than this quantity, and we believe it is appropriate to normalize where we can. Contact Equinix operations if you are at risk of running out of available interfaces.
Devices have three interfaces instantiated by default:
- Management (MGMT)
- External/Public internet
- A reserved network interface
The MGMT interface is used internally by provisioning systems for monitoring and configuration management. SSHSecure Shell is a protocol that allows customers to connect to a device (that supports and has enabled SSH) directly. This allows the user to access all features of the device, including those not supported from the portal or API, and make changes, manage and observe and other activities. Caution: if a user connects into a device directly and makes changes that are not tracked or possible from the portal or API, some functions may fall out of sync and may into work at all and Equinix cannot guarantee support and accuracy once this occurs. is used for secure access and the Public Internet interface is a loopback used for external reachability. The remaining interfaces are reserved for connectivity to cloud services. The Network interface is reserved for future use.
NE utilizes Layer 3 virtualization for control and data plane isolation. The implementation method is vendor-specific -- consult the respective documentation for specifics.
For the purposes of this document, we will use VRF to describe Layer 3 virtualization. Your implementation might be different.
Three VRFs are created for virtual devices
The MGMT interface is associated with the MGMT VRF. The SSH and Loopback interfaces are assigned to the external VRF, the remaining reserved interfaces are assigned to the cloud VRF.
Each device comes equipped with a loopback interface that is created and placed in the external VRF and assigned an Equinix-owned public IP address during device creation. This interface is used for external connectivity requirements such as creating VPN tunnels and SSH access. External reachability to the virtual device is achieved by adding a host route on the gateway router that points the loopback address to the SSH interface on the virtual device as the next hop. The gateway router is part of the Equinix infrastructure for NE and the routes are configured automatically as part of the provisioning process for virtual devices.
The MGT interface is placed in its own VRF and is used for management and provisioning activities.
The remaining interfaces reserved for cloud connectivity are associated with the cloud VRF and connected to the Equinix Cloud Exchange. These interfaces can then be used for virtual connections to respective cloud service providers.
The remaining interfaces are there for user customization and some forthcoming features, such as dedicated NSPNetwork Service Provider links, service chaining, and others to be announced. Equinix orchestration will not provision cloud services on these reserved interfaces.
As of the current release, there is no NAT, route filtering, or other configuration shortcuts in the portal or API, but customers can generally configure and activate these services, as needed, directly in the device. A few use cases are specified below as examples. Users should note, however, that the more they "customize" the device directly at the CLI by logging in via SSH, or with a 3rd party application or software orchestrator (as with SDWAN), the more the device may be out of sync with the features and settings that the Equinix NE portal tracks. It is the customer's responsibility to understand what has been customized and when a new setting from the portal, for example, may potentially "overwrite" what has been done outside of the portal. In short, any device configuration not done via the portal can be considered customized and all the caveats mentioned above are applicable. It is recommended to complete all configuration parameters exposed via the portal using the portal.
Layer 3 Configuration
Initial Layer 3 configuration to establish BGPBorder Gateway Protocol. A standardized exterior gateway protocol designed to exchange routing and reachability information between autonomous systems on the internet connectivity should always be configured via the portal or your SaaS application, where able. This article describes how to establish BGP connectivity via the portal. Local and remote ASN information along with local and remote IP addressing will be configured on the virtual device via the backend provisioning system once entered in the portal. Additionally, you can add a BGP authentication key if required.
Once the initial BGP configuration is complete and connectivity is established, you can manually configure other parameters as needed via your device CLI. Route-maps, default route generation, as-prepending and updating descriptions are some of the more common tasks.
Each device has a wide diversity of protocols supported and the workflow to make them effective. Some have proprietary protocols only found in devices from a single vendor.
Equinix encounters significant differentiation in some devices. We will attempt to document them here, but in general, we advise that you consult with the documentation for that vendor. From an Equinix standpoint, all standard non-proprietary protocols are generally supported. Proprietary Layer 3 (e.g. EIGRP) and higher protocols would be supported when connecting between devices over the Equinix switching fabric as Equinix would be unaware of the higher layer protocols.
There are rare situations where the traffic patterns may disrupt ECXF or our Internet service, and so we occasionally disable or restrict the amount possible. One example of this is multicast traffic. While it is impossible to list every protocol supported, Equinix includes notable inclusions or exclusions where we believe it may be of interest to many users and their use cases in the tables at the end of this article.
Use Cases with "Customized" Configuration
A series of specific use cases are coming soon from our expert engineers and architects in the field. Each use case will include a basic summary of what it is, drawings, a statement of why, and a walkthrough of what was done to build, customize, finalize, and test it in production.
- Use Case 1: Multi-cloud traffic directly between each other
- Use Case 2: NE to NSP or colo
- Use Case 3: backhaul of cloud traffic to a branch office with VPN tunnel
Below you will find a detailed chart for each vendor and the devices and software packages currently supported. The initial boot-up specifications are included. We always recommend you consult with the vendor documentation for the most current, detailed, and accurate information about each VNF. A few notes:
- The interfaces note how many are included at the time of launch, and how many are possible per device. This does not mean you will have that many usable immediately, and some are also reserved for other purposes, noted below.
- The “max throughput average” is a statement of the sustained throughput that Equinix test labs were able to consistently achieve. Your results may differ, and each device comes with a pre-provisioned amount of throughput that is generally lower than the stated amounts. The sizing of small, medium and large should correspond with the Edge Instance that is allocated for your device at the time of launch
- The “boot time average” is a statement of Equinix test lab observations on a repeated and consistent basis across multiple scenarios and configurations. Your results will vary, and they are not the official stated times by the vendor
- Reserved interfaces and route domains are both stated in CLI terms that you will see when logged into your device. You should NEVER delete or change these. they are noted purely to indicate what to expect
- Although many aspects of the starting configuration can be changed after it is launched with the CLI, always exercise caution before doing so, as Equinix cannot guarantee stability and proper operations once the user begins customizing in CLI or other means. When in doubt, consult with Equinix operations or vendor guidance first
- For details on which services are supported per device, see the Services article