A port is the primary access method into the ECX Fabric, and as such, is the most important component to get right. As a note, most parameters of the port CANNOT be edited from the portal or API after it has been ordered, but there are a few items where noted below.
The following parameters are chosen by the user when procuring ports:
1G SX MMF
1G LX SMF
10G LR SMF
|1G MMF may be limited in some regions and is generally not recommended by Equinix|
|Encapsulation||802.1Q (TPID: 0x8100) 802.1ad (TPID: 0x8100, 0x88a8, 0x9100)||In case of the frame type 802.1ad (QinQ) the TPID value of 0x8100, 0x88a8, 0x9100 in the CRD applies to the outer tag while the inner tag uses 0x8100|
|MTU||9192 bytes||Ports on ECX Fabric are set to a default MTU size of 9192 bytes|
LAG Group name (with which ports)LAG quantity (min 1; max 8)
|If ports should be configured as members of 802.3ad Link Aggregation Group (LAG) members. ECX Fabric uses the LACP protocol. ECX Fabric does not support MC-LAG|
Although all ports are initially set up with either “Dot1q” or Q-in-Q” tagging formats, users can also designate some Layer 3 connectors as untagged (see that section for more detail). To do this, the user must:
- Verify there are no current services already on the port that are tagged
- Ensure that only Layer 3 type services are intended for this port
A port used for untagged traffic can accept remote connections and connectors that do not have a VLAN value. The ECX Fabric orchestration system will assign a default or “native” VLAN that is appended to all incoming traffic; that VLAN is stripped out before traffic is passed back to the port. If a user sends any traffic with a VLAN framed in the payload, the traffic will be switched to a VC or connector with that value, or it will be dropped at the port and will not enter the ECX Fabric or be passed to any services.
The above diagram is a complex port example with the following characteristics:
- Multiple tags can go to the same provider
- Tags can go to both Layer 2 and Layer 3 services
- All untagged traffic goes to one provider if created that way
- Tags without a destination are dropped.
There are three ways in which a port is used to access ECX Fabric services:
The same physical port or logical port group can be used for both Layer 2 and Layer 3 services, and can be used for both buying and selling activities of any type.
Primary vs. secondary chassis groups
The ECX Fabric platform is arranged into “chassis groups.” Each metro has both a primary and a secondary, and within that group may have one or more routers. When ports are ordered and provisioned, it is important to understand where they will be deployed, depending on your needs and preferences.
Ports are typically named for the chassis group they reside on to help users understand when they see a list of ports in the portal or other methods, but technically a user can name them whatever they want at the time of turn-up.
The ECX Fabric platform may limit certain actions or solutions depending on the port that has been selected for buy or sell activity. For example, see the below examples of a solution in which redundancy on the provider side has been mandated:
The following optional services are available on the “Port” component, and must be specified at the time of order placement:
- Unlimited connections: This package is a billing option that increases the price of the port, but enables zero-cost virtual connections and connectors. In the default scenario, all ports are billed at one price, then each virtual connection and connector attached to that port is also charged a monthly rate. With unlimited connections, there is no monthly charge for any VC or connector, and there is no theoretical limit to the quantity a user can provision per port/port group
Equinix strongly advises users to select a consistent port pricing arrangement across all deployments and all primary/secondary, LAG groups, etc. Generally, you should choose to add this package to all ports in your ECX deployment, or to none of them. Unless the user intends to buy more than 2-3 discrete services per port, it generally does not make financial sense to convert to this model. It is intended for larger scale aggregators.