The minimum viable Layer 2 connection is a VC between two ports:
In the most common scenarios, one port is represented by a Layer 2 Service Profile as the “seller” of the service, and the ECX isolates and determines services through sub-interfaces and VLANs. A Layer 2 connection in the ECX also means that the end customer typically peers or communicates directly with the provider of the service; this is important as it represents additional configuration that one or both sides may need to create that is outside the control of Equinix.
Any user can create or receive multiple VCs from same port to the same provider as long as they are logically separated with appropriate VLAN tagging. Users can also create multiple services to different providers, and across “types” of services (both Layer 2 and Layer 3).
Many Layer 2 providers will request or mandate some level of redundancy to their service to ensure some level of high availability. From a buyer perspective this is accomplished in one of two ways:
- Additional VCs from the originating port to diverse ports on the provider side
- Additional port and VCs from diverse ECX devices to equivalent device and port on the provider side
The ECX portal or API will guide users through available options, where appropriate. The figure below shows a deployment scenario using redundant ports and Layer 3 connections for high availability. This diagram shows one provider for simplicity, but Aggregators can use the same model for connecting multiple customers to multiple CSPs using redundant ports and connections for high availability. Enterprises can use this model to have multiple connections to a CSP or have redundant connections using redundant physical ports to single or multiple CSPs.
We recommend that typical enterprise customers, who only intend to buy services and are interfacing directly with the ECX, use a dot1q port type.
If 802.1Q is used to connect to Microsoft ExpressRoute, the buyer should be aware of the following condition: the same service key can be used to order separate connections for private or public peerings (one 802.1Q Tag per connection request) when using 802.1Q on the A-side.
Currently, CXP allows up to three Layer 2 virtual connections using the same Service Key without incurring additional charges or needing to generate additional keys. Note: the connections ordered using the same Service Key will be using the same Dedicated Circuit on Azure ExpressRoute.
When provisioning connection towards Azure ExpressRoute using 802.1Q port on the A-side, CXP captures 1 VLAN tag per virtual connection. This should be the same VLAN tag used when configuring Azure private, public or Office365 for ExpressRoute circuits using Azure Resource Manager (ARM) or Classic. For steps to create routing for ExpressRoute circuit, please refer to Microsoft Azure documentation:
Once the connection is provisioned on ECX, BGP sessions must be set up on both the seller edge device (if peering with CSP) and the buyer edge devices. Please refer to seller-specific documentation on seller’s website to set up BGP configuration on the seller edge. For high availability, primary and secondary BGP sessions must be set up with fault detection (BFD) and link failover mechanisms configured on the buyer’s edge devices to failover between ports on ECX. Buyer’s edge devices also must have the necessary QoS configurations to appropriately prioritize traffic into ECX.
To set up BGP peering, the following information is required:
- Source and destination BGP ASNs (Autonomous System Number)
- A set of prefixes (/30 subnets) per connection
- MD5 hash if an authenticated BGP session is needed
Once BGP peering is configured on the buyer and seller edge devices (not required if peering with ECX directly) and the required subnets in each network advertised, the end-to-end communication between the buyer’s edge and the CSP should be possible.