Network Edge Services

Services are any additional features or configuration on a device. Generally, services are any addition to the basic device configuration that is not absolutely and minimally required to create the device. Service configurations offered both through the portal and API are vendor- and device-neutral.

Equinix offers many services and the list grows with each release. When using NE and launching a device, the list of available services will depend on things including:

A comprehensive list and description of each service is provided below along with guidance on when and where it is appropriate to use these services.

High Availability

High Availability, (HA) is one of the most critical decision points for your virtual network deployment. An entire section of the Deployment Guide is devoted to High Availability.

Unlike many other services on this list, the selection of this service is presented at the beginning of your device deployment process. We highly recommended selecting this service before doing any other device details and configuration.

HA creates a second, duplicate device for each configured device. The devices are launched as Primary and Secondary and are paired together in an active/active setup. Once two devices are paired, many aspects of the configuration, services, edits, and change management are duplicated between both devices every time. Each service in this section is impacted by HA and noted appropriately.

User Access

User Access is a generic service available with most vendors that provide direct access to the device. It can take several forms. The most common is SSH.

Secure Shell, or SSH, is a common access method that allows approved users to log into the device and operate on it directly. SSH credentials can be added for up to a number of users. Equinix will restrict some activities of the SSH user in order to prevent major accidents or lockouts from occurring, but we try, where able, to minimize this restriction. For example, an SSH user would not be able to delete the SSH interface. This keeps both Equinix operational visibility and the customer’s own users from being locked out of the device with no way to resolve other than a complete delete.

The user access service has the following attributes:

 

Values

Data Requirements

Notes

Configure before launch:

Yes*

 

*users who have been defined for previous devices can be used for this one

Configure at launch:

Yes

 

On additional services section of new device.

Configure during lifecycle:

Yes

 

On additional services tab of device details.

Optional/Required?

Optional

   

Username

Required (w/ password)

Must be at least 3 characters and max 32; must be unique to the market

May add new (w/ password) or select from list of existing users.

Password

Required

Must be at least 6 characters and max 12; may include lower and upper-case letters, numbers, and some special characters

Only defined when creating a new user for first time. The user cannot re-enter the same or new password for an existing user.

Device

UUID; Required

Alphanumeric

On the portal, the device UUID is assumed based on the currently active device that user is viewing.

How many users per device

5

 

 

How many users per account

See notes

 

Number of deployed devices x5

Required same on secondary?

No

 

Can have no user access, same or different.

Some vendors offer a basic user interface loads when navigating to the address or FQDN of the device. The user access service can be used for this purpose, as well, because typically it is a shell over SSH or the CLI already.

When a user logs into the device directly via SSH, they typically use a client such as Telnet, PuTTy or OpenSSH. This will grant them access to the CLI of the device. Equinix adds user permission limitations to prevent catastrophic errors, yet we try to allow as much as possible. Some vendors do not have the ability to limit user controls to SSH.

As a result, the customer assumes all responsibility for configuration changes and adjustments that they commit to the device. Any resulting impairment or outages may not apply to the SLA guarantee. The customer also assumes all responsibility for understanding how to navigate and configure that device using the appropriate OS and version for that vendor.

Users can see and operate on nearly all aspects of the device, just as they would a physical device inside their corporate network. For example, when logged into the device, the user can show the interfaces (with the appropriate command for that vendor and OS) and will see the SSH interface, which always includes a public IPv4Version 4 of the IP protocol providing 32-bit addresses. For standards reference, please see http://www.ietf.org/ rfc/rfc791.txt address issued by Equinix. Read more about interfaces on your device, in the Device Configuration section of the Deployment Guide.

If you are not comfortable making changes directly to the device rather than through the Equinix portal or API, do not enable this service.

When adding user access to an HA pair, the user must elect if they want to duplicate the same user privileges on the secondary device or add a different list of users.

User Access service allows you to enter up to 5 usernames and associated passwords per device. The same username/password combo can be repeated in more than one device, if desired, but must be unique within a single Equinix metro.

Note: Equinix user credentials are mutually exclusive to the settings and data on this virtual device. It is not related to, nor will it impact or change any user credentials related to the ECX FabricECX Fabric is an advanced interconnection solution that improves performance by providing a direct, private network connection portal or any other Equinix portal, system or property. Therefore, customers can enter users for device access that are not also users of any other Equinix-related tool. Further, if the user wishes to access the device, he must create a user and password in this service; his Equinix credentials will not work for direct access. If a user decides to add credentials that are the same as Equinix user credentials, this is coincidental and there is no synchronization.

Each time a user is entered, changed or deleted and the SAVE button is selected, the full set of user configurations is immediately pushed to the device and Equinix TACACs server, where relevant.

In order to allow access to work properly, users should coordinate it with ACL’s to ensure the accessing addresses are allowed.

Primary Interface Access Control List

This service allows the user to enter one or more IP address blocks that will be whitelisted or ALLOW (in route filtering lexicon) to access the primary interface enabled on all devices. This ACL operates in a traditional manner to other well-known network device ACLs. You should always have at least one whitelisted block if:

Equinix automatically has basic access to the device, but without enabling at least one block of allowed addresses, the above actions will not work for customers outside the Equinix operations. Once an address is entered, Equinix orchestration enables this whitelist in multiple locations:

This includes, but is not limited to:

  • Interfaces on the public gateway router for public internet access
  • Top of rack interfaces facing the GW routers
  • Primary or internet interface on the VNF
  • Select troubleshooting and operations tools

The Primary interface ACL service has the following attributes:

 

Values

Data Requirements

Notes

Configure before launch

No/NA

   

Configure at launch:

Yes

 

On the Additional Services section of the new device.

Configure during lifecycle:

Yes

 

On the Additional Services tab of device details.

Optional/Required?

Optional*

 

May be required on some devices, see device profile or details for more information.

IP Address

x.x.x.x/y

IPv4 address in numeric format; where X is min 0 and max 255, and y is min 1 and max 32

The system will block 0.0.0.0/0; system does not validate or verify address blocks or ownership against an IRR at this time; may be public or private.

Device

UUID; Required

alphanumeric

On the portal, the device UUID is assumed based on the currently active device that user is viewing.

How many IP blocks per device

50

   

How many IP addresses per account

Unlimited

 

NA

Max CIDR/Subnet size

None

 

/1 or smaller; system will block /0

Reqd same on secondary?

No

 

May have the same or different.

When adding this service to an HA pair, users must specify whether they want the same set of IP addresses added to the secondary device. They can also specify a different list.

Equinix maintains a TACACs server that allows SSH users to access devices from whitelisted IP addresses, and from Internet backbone routers. This service informs Equinix infrastructure which IP addresses and subnets are allowed to access the device. This service will work for both individual users through an SSH client as well as 3rd party software, applications or orchestration that will manage the device. It is for this reason that a user may need to configure this service even if they have no users defined, such as:

  • An SDWAN device where external SaaS will manage access
  • A network performance software package that will capture SNMP traps through the SSH interface
  • Third party software or orchestration that will control this device
  • And many other possible scenarios

Although the blocks are limited to 50, the user can effectively enter a very large number of concurrent addresses if needed when accounting for the subnet. The system will restrict some entries (such as a “permit all” 0/0 entry, and some private address space). At any time during the lifecycle of the device, users may add to or remove from this list.

Note: As soon as the SAVE button is selected, the configuration of all whitelisted addresses will be pushed to the device. If this includes the removal of or changes to an address, there will be service interruption for anyone associated with that address attempting to access the device.

All users listed in the User Access service are able to access the device from all addresses listed in this service. Equinix recommends that you add as few permitted addresses as possible in as small a subnet as possible. Users should consult with their corporate IT organization to determine the likely origin addresses of those people or systems that need to access the device. Individual users can use a service like whatsmyip to determine the public address you are configuring from on your computer or terminal.

Equinix does not validate ownership of the entered IP subnets with any registry such as ARIN. All traffic from these addresses is solely the customer's responsibility.

Device Link – Beta Version

The device link service creates a Layer 2, full-mesh LAN between two or more Network Edge devices that a user has access to.  The devices must be across Metros (in 2020, devices inside the same Metro can be linked). 

This service can be used to accomplish several use cases:

  • Connect Virtual Devices together across Metros to create a WAN or other private network configuration

  • Direct traffic flow from one device to the next in sequence, or “service chain” items together

  • Connect redundant or High Availability-configured devices together to synchronize them using relevant protocols

A picture containing clock

Description automatically generated

Note: Device link does not specify the exact routing or traffic flow at Layer 3. This must be created via configuration of the interfaces protocols and other needs.

The Device Link service has the following attributes:

 

Values

Data Requirements

Notes

Device

No/NA

Virtual device name

Each device that will be part of the overall link group must be specified

Device Link Group Name

text

May not exceed 50 characters; must be unique to your account

More here

Device InterfaceAn interface is a point on a device where data flows in and out. The virtual device is like a physical device because it has some amount of interfaces that allow it to transmit and receive data from the outside world. This can be in the form of an Internet connection, a connection to ECX, a service chain to another virtual device or any other communication.

 

 

Each device in the group requires an interface that’s dedicated to the device link group

IP Address Pool

 

Must be in CIDR format; single subnet only

 

IP Address Interface

 

 

As devices are added, an IP address is allocated to the interface from the defined pool or subnet

Metro throughput/ Speed

number

Whole number from 1-1000

Measured in Mbps; this is the total possible throughput in and out of the Metro

To create a Device Link, a “group” is defined.  This group will have a common name and requires the use of a single interface on each device that will be part of the group.  A device can be part of more than one group, but each device is on a discrete interface:

Additionally, the group must have an IP address pool to pull from.  The IP address may be public or private, but is user-defined.  When devices are added to the pool, each is assigned an overlay address from the subnet until the subnet is exhausted.  Once exhausted, the device link may not accept additional devices.  While most users will likely have relatively small groups, the IP address pool cannot be augmented or added to once it has been defined.  We recommend that you place a large enough pool on the group that there is little to no risk of exhaustion in the future.

There system does not limit the number of devices that can be added to a device link. However, there are practical limitations to routing, so recommend that no single group exceed 10-12 total devices. 

Although the device link is a Layer 2 construct, the IP addressing, “Global ASN” and some other steps are necessary for a proper configuration.  This Global ASN setting is not exclusive to Device Link, but if no other services or settings have been created when a device is added to the group, an ASN must be specified for the device.  If a Global ASN was already specified for a connection, VPN tunnel or other service, the system will automatically use that ASN instead.

At this time, device link works between Metros only.  Users may add one device per Metro per device link group.  Traffic travels from one device to another between the Metros using the same backbone that the ECX Fabric portal uses.

The traffic that travels traverses in and out of a Metro is policed as a single measure of throughput for each Metro.  This is important to understand so that users setup the device link to optimize for the traffic flow and overlay routing that is intended.

For example, in a full mesh setup, users will typically have the same throughput setting in every Metro, as below:

A close up of text on a white background

Description automatically generated

Alternatively, if the intention with a Device Link group is to set up a hub and spoke routing schema, users might add throughput limits like the below:

 

As functionality is added to allow more than one device per Metro into a device link, this design and throughput setup will become critical.  This configuration will remain a “per Metro” setting, not a “per device” throughput setting.  Within the Metro, there is no enforced throughput policy, but there may be other limitations, such as the throughput of the device itself, the available capacity in the compute node or the best effort traffic competing with other traffic.

If the routing design, throughput, or others cause more traffic to flow to or from a Metro than is allocated, packets will be dropped as it is a best effort service.  Users can edit and change the amount for each Metro at any time.

Because a single device can be part of multiple device links, users can also use this to overlay unidirectional traffic patterns for some use cases, such as firewalls that filter traffic and then return it to another device.  See an example of this:

Device link is always capable of being bidirectional, depending on the overlay routing rules that the user creates.

A device link may contain any combination of primary and secondary devices that are also part of an HA pairing.  This is the case even if the combination does not represent the same pairs.  For example, a device link could theoretically include the primary device of HA pair A and the secondary device of HA pair B.

Some Virtual Devices may be restricted from using device links due to settings that are native to the vendor or the current configuration.  The system will indicate when a device is not eligible to be part of a device link.  Here are some examples of why a Virtual DeviceThe Virtual Device is the software "image" that launches on the ENE platform when a user selects a device. The device could be a router, firewall or other types. This image is generally specific to a vendor (for example: Cisco) and specific device ID that the vendor has integrated with our platform. From this Virtual Device, you can create connections like you would from a port on ECX. may not be allowed:

  • The device has no more interfaces available

  • The device is incapable of rebooting or reloading to add a net new interface

  • The device is already part of the same group (it cannot be added twice)

  • There are no additional IP addresses to allocate from the original customer pool that was defined

BGP (on A Connection)

The Border Gateway Protocol ( BGPBorder Gateway Protocol. A standardized exterior gateway protocol designed to exchange routing and reachability information between autonomous systems on the internet) service is the most common method used by service providers to transmit data into and out of their cloud, network and other services. BGP settings can be added to any connection associated with a device once that connection is up and running. The settings specified in each BGP instance will be pushed to the device as a configuration change to the interface associated with the connection.

The BGP service has the following attributes:

 

Values

Data Requirements

Notes

Configure before launch:

No

 

Can only be done on a connection AFTER the connection is in provisioned state.

Configure at launch:

No

 

Per above

Configure during lifecycle:

Yes

 

Found on connection details once the connection has been provisioned.

Optional/required?

Optional*

 

Connections may not operate properly if some info is not entered here, but the system will not force you to enter BGP info.

Users can also enter manually on device directly. Some devices will restrict/prevent BGP entry because it should be entered on the orchestration, GUI or software of the vendor.

Local ASN

Required

Must be in numeric format and can be 2- or 4-byte, public or private.

"Local" refers to the virtual device or the customer side equipment or images. Some restricted or pre-reserved AS' will apply.

Local IP Address

Required

Must be IPv4 address; may be public or private and must be part of same subnet as the local IP address;

Expressed in CIDR format so that the subnet can be matched with a remote IP address.

Remote ASN

required

Must be in numeric format and can be 2- or 4-byte, public or private.

"Remote" refers to the cloud, network, or other Z-end location that the user connects their device to.

Remote IP Address

required

Must be IPv4 address; may be public or private and must be part of same subnet as the remote IP address;

Expressed in CIDR format so that the subnet can be matched with a local IP address.

BGP Authentication KeyThe Authentication Key is a unique identifier authorizing Equinix to provision a connection towards the CSP. This Key usually contains alphanumeric characters. Note: to Equinix, an Authentication Key is a generic term and is not encrypted on ECX. Cloud Service Providers might use a different name to refer to the same key. For example: Azure ExpressRoute calls the authorization key the “service key” while AWS calls it the “account ID.”

Optional

Can only be letters or numerals. May not begin with a number.

Some limits are based on single vendor differences; if the user needs to enter BGP auth key outside of these rules and device supports the format, it can be done manually via CLI.

ConnectionConnection is a general term that refers to any solution that results in the ability to pass data from one point to another. Connections can be made with Layer 2 or Layer 3 technology, may involve several parts or components and can be created from the portal or with APIs in a variety of ways.

UUID; Required

Alphanumeric

On the portal, the connection UUID is assumed based on the currently active connection that user is viewing.

Provisioning Status

NA

May include: Provisioning, Deprovisioning, Provisioned or Deprovisioned.

Not user-defined; indicates whether the configuration has been pushed or pulled successfully from the device following a user request to add, edit or delete it.

BGP State

NA

May include: Idle, Connect, Active, Open/Sent, Open/Confirm or Established.

Not user-defined; follows BGP industry standards; BGP is peering successfully when it is in an established state.

How many per connection?

1

NA

 

Delete fully?

No*

 

Once created, the BGP settings can only be deleted completely by deleting the connection it is associated to.

Reqd same on secondary?

No

   

When a BGP service is added to an ECX Fabric Layer 2 connection, your device can peer with the equivalent settings on the other side of that connection, just as you would set up a physical router to do the same. A typical setup with a connection from your device to a public cloud provider might look something like this:

Unless the user specifically requests or configures a custom setup, all connections to the ECX Fabric will traverse a single VRF from multiple virtual interfaces.

Read more about the typical setup and architecture.

These various connections can then peer with each other or with sessions on other interfaces (such as toward the public internet or a VPN tunnel).

Unless specifically limited in certain cases, all BGP settings share these common attributes:

  • Any allowed ASN can be appended to either public or private IPv4 address space
  • Equinix does not restrict ASN and IP combinations, but 3rd parties and providers may

The BGP service goes through a series of states that conform to the standards defined by RFC 4271, but may have some nuance depending on your specific vendor and device. This state transition is different from the state of the overall device and should not be confused with a broader failure.

Although the BGP sessionA routing session configured between two peers using the BGP. For standards reference, please see http://www.ietf.org/rfc/rfc4271.txt may cycle through all 7 standard stages, the most notable BGP states are:

  • Idle: the connection is not actively peering
  • Established: the connection is peering and route tables are being updated
  • Failed: the attempt to peer or find the ASN has failed and should be deleted or tried again

Consult with your vendor guidance or common BGP tutorials for more detail and state possibilities if you see one not mentioned here.

Some devices do not support multi-ASN as specified in RFC 7705. If this is the case, you should not enter more than one ASN for across all connections you create to your device. If you do, the previous ones will be overwritten immediately on all other connections. Where possible, the system will warn you and prevent you from doing so, but always be sure you consult with your vendor and device guidance and specifications.

When a user adds a connection to an HA pair, the system enforces two connections but does not force BGP settings be added to both at the same time. Users need to be aware that they must configure connection each separately. While traffic will flow over one or the other if both are not configured, the solution will not be complete and other systems or cloud environments may malfunction or alarm until both sessions are established.

In an HA scenario, users can also perform customizations in the CLI. The BGP service does not support it from the portal or API, but an example would be BGP communities used to favor one route over another. Consult with your vendor guidance for how to do this and the tradeoffs associated. Equinix cannot guarantee the flow of traffic when customizations are made in the device directly.

VPN Tunnels And Sites

The VPN service allows the definition of one or more VPN tunnels per device. Each site to site includes an IPsec tunnel with 256-bit encryption and can reach many remote sites or locations. Typically, the tunnel is over the interface toward the public internet but can be used in any combination.

The VPN service has the following attributes:

 

Values

Data Requirements

Notes

Configure before launch:

No

 

 

Configure at launch:

No

 

Requires at least one active connection; connections are not provisioned at startup of device

Configure during lifecycle:

Yes

 

on additional services tab of device details

Optional/required?

Optional

 

 

Remote Site: VPN Name

Required

Minimum 3 and maximum 50 characters; most characters accepted.

The informal name given to the overall configuration and solution for a VPN tunnel and will appear in inventory.

Remote Site: Site Name

Required

Between 2 and 10 characters, must be alphanumeric. Will appear in the configuration of the device.

 

Remote Site: Pre-shared Key

required

Alphanumeric only, no special characters or spaces.

 

Remote Site: Remote Peer IP Address

required

Must be IPv4 address; must be public and must be part of same subnet as the remote IP address.

User/customer should provide a public address; if none is available, they could purchase an IP block from Equinix

Equinix VNF: Local ASN

required

Must be in numeric format and can be 2- or 4-byte, public or private.

Some restricted or pre-reserved AS' will apply

Equinix VNF: Tunnel IP Address

required

Must be an IPv4 address, be private and be part of same subnet as the tunnel remote IP address.

 

Equinix VNF: Remote Peer ASN

required

Must be in numeric format and can be 2- or 4-byte, public or private.

Some restricted or pre-reserved AS' will apply

Equinix VNF: Remote Peer IP Address

required

Must be IPv4 address, be private and part of the same subnet as the local IP address.

 

Equinix VNF: Authentication Key

required

Can only be letters or numerals, may not begin with a number.

 

Device

UUID; Required

Alphanumeric

On the portal, the device UUID is assumed based on the currently active device that user is viewing.

How many tunnels per device

10

   

Provisioning State

NA

May include: provisioning, provisioned or failed

Not user-defined

Reqd same on secondary?

Yes*

 

An equivalent VPN tunnel is required on secondary when HA is active. The VPN settings may be different as it may point back to a different site.

Users can add up to 10 separate site-to-site VPN tunnels. A public IP address is required for each site. The user is responsible for providing these addresses, although they can purchase a block separately from the ECXF portal. When configuring or changing a current VPN tunnel, the system will push the configuration in two stages, and so you can operate on and edit one at a time:

  1. Details about the remote site or location
  2. Details about the peering between the tunnel and the cloud or other provider of choice

Once you have entered the VPN details, the configuration is pushed to the device immediately. If it is a change or a delete, there could be a service impact to current traffic over those tunnels.

The BGP session operates in the same way on the tunnel as it does on individual connections, including the states and transitions. However, the BGP session is independent from that BGP session, and should not be confused with other larger failures of the device or its connections.

When adding VPN tunnels to an HA pair, the system will enforce two VPNs; one on primary and one on secondary – to the same remote site.

Additional Internet Bandwidth

This service allows the user to increase the amount of public Internet traffic that can flow in and out of the device.

Note: Additional internet bandwidth is a charged service.

Every virtual device comes with a small amount of public internet bandwidth (15 Mbps) and a public IP address that makes it accessible. This should satisfy many use cases and customer needs, such as SSH access to configure the device directly.

However, some use cases will require additional throughput. The Additional Internet bandwidth service allows a user to significantly increase the amount of traffic that can flow to and from the device through a dedicated internet access service provided by Equinix. Specifically, we use our own product called Equinix ConnectEquinix Connect is a turnkey solution for customers to connect to the Internet. The customer will connect their equipment to an Equinix-provided router or switch by means of one or more physical cross connects in a multi-tenant manner, which means a common physical port accesses the EC border routers for multiple devices on the NE platform, and traffic eventually flows to the internet via gateway routers owned by Equinix. Find more details on the larger product.

The Additional Internet service has the following attributes:

 

Values

Data Requirements

Notes

Configure before launch:

No

 

 

Configure at launch:

Yes

 

On the Additional Services section of the new device.

Configure during lifecycle:

Yes

 

On the Additional Services tab of device details.

Optional/required?

Optional

 

All devices include 15Mbps of internet. If the user removes values or does not use this service, it is assumed disabled, although the 15 Mbps remains active.

Additional Mbps

Whole number

Measured in Mbps or Gbps

May be any value above or below current or previous value, should not go below 15.

Device

UUID; Required

Alphanumeric

On the portal, the device UUID is assumed based on the currently active device that user is viewing.

Max BW

Whole number

 

May not exceed the overall throughput of the associated device.

Incremental charges

Yes

Expressed in local currency where the device resides, calculated by additional Mbps value x Tier rate.

Additional internet is derived from Equinix Connect service and has several pricing tiers, expressed "per Megabit per second."

Reqd same on secondary?

No

 

 

In the example below, a virtual router is connected to several clouds on the right, and then feeds that traffic to multiple locations at left, through the public internet interface using VPN tunnels. This implementation is likely to demand more throughput than the default amount.

Unless specified otherwise when configuring your device, the Internet traffic uses the same interface as the SSH link, so both use a single, shared public IP address that is issued at the time of device creation. The total amount of throughput can be customized but may not exceed the total of your device's allowed throughput. Traffic is treated as best effort and is not guaranteed. For the purpose of measuring it against other traditional Internet access services, there is only one charge and selection made for the committed rate. There is no additional burst rate or charge.

When adding Internet bandwidth to an HA-paired device, the system will not require you to have the same settings on both devices. Users can add differing amounts to each device. This can be useful if you do not plan to pass traffic over the internet to the secondary device under normal conditions. This may save on expenses, and in an emergency the user can always ramp it up via portal or even create scripts to do so automatically via API when certain conditions are met.

If your use case demands large amounts of traffic via VPN tunnels, for example, and the primary solution fails, you may be bottlenecked and drop packets when traffic shifts to the secondary with a smaller Internet throughput allowance.

Equinix always recommends that the user maintain equivalent settings on the primary and secondary solutions.

Service to Device Matrix

The following chart details which Equinix services are available on which devices and software packages.

  • 0 indicates the service can be configured at Day Zero, or before the device is launched into active service
  • 1 indicates Day One+: the service can be added, edited, or deleted after the device has launched and throughout its lifecycle
  • X indicates that the service is not available on this device. In many cases, an equivalent service can be configured directly on the device or using a 3rd party application, although this is not actively configured or tracked by the Equinix platform

Required indicates that the service is Required.

0 = available at configuration time

1 = available after configuration

X = feature not available as a service from the ECX Fabric portal but may be configured on the device or vendor portal