Configuring Layer 2 Service Offerings

The first step in offering services for sale on the ECX FabricECX Fabric is an advanced interconnection solution that improves performance by providing a direct, private network connection is choosing whether to offer a Layer 2 or Layer 3 service model. This selection will impact the minimum viable workflow and pre-requisites that a user must have when buying the service. We recommend consulting with Equinix personnel, product, engineers and architects if you are unsure which path to take.

A Layer 2 service is created by combining ports into a service profile and then defining its characteristics and business rules.

The following is the basic workflow to get started:

Throughout the lifecycle of your service, you can add ports in new or existing markets (for capacity), remove those ports or upgrade and change certain aspects of your service.

Another critical task is to review and approve connection requests as they are made. This can be done manually through the portal, automatically by coding to the API or, with prior arrangement and ECX Fabric development, by having ECX Fabric integrate into your provisioning systems.

In any case, the primary items that must be determined per connection request include:

  • Whether the requestor has a valid authentication ID, if relevant and asked for

  • To which local port the users connection should be terminated, depending on your preference, fill factor, capacity management decisions, and other factors at your discretion

  • To which VLAN the connection should be mapped on your port

ECX Fabric will not begin provisioning and orchestration of the connection and will not consume any of the physical or logical resources until approval has occurred.

Once approval has been received, the entire workflow to completion will occur within seconds and the user will be capable of sending traffic to your service within minutes.

Some providers require their users to perform certain actions in their own portal or tools, such as selecting the interconnection provider (in this case, Equinix is the provider). If this is necessary, it is important that the provider make clear to their customers the order of events in their own documentation. You may also wish to clarify when an end customer will be going through an intermediary to get to Equinix, and is unaware that their intermediary will be using the services of Equinix for this task.

Often, it involves coming to your portal and services first, setting up or buying something, taking specific information from that transaction to the ECX Fabric, provisioning a connection, and sometimes even coming BACK to your portal to finalize details. This frequently confuses users; Equinix cannot customize guidance for every provider with a discrete, private interconnection offer.

When a buyerA buyer is a user who connects to an available service through ECX. A buyer can be an enterprise end customer of the seller service or an aggregator, managed service provider, network service provider or system integrator company that bundles its service offerings with ECX. chooses Equinix as the connectivity option, the provider should link the buyer to the CXP automatically or point to the CXP link (http://cloudExchangeportal.equinix.com) to order connections.

In most scenarios, buyers and providers will use Dot1q type ports. Some providers choose to use Q-in-Q ports, especially if they offer more than one subscription service to their users. This allows their systems to identify an S-Tag as a single customer incoming on an aggregatedOn Enterprise Cloud Exchange (ECX), aggregators are Network Service Providers (NSPs) and Managed Service Providers (MSPs) who provide multi-tenant services. Aggregators are both buyers of ECX service from Equinix and sellers of value-added services over ECX to their end customers. port, and then the C-Tags below will indicate the service for which it is bound. While this can be very helpful for providers and buyers alike, it can also be highly confusing for buyers.

Example above: Provider offers red and blue services and labels in lieu of provider-side C-tagging. When buyer creates connections, user maps C-tags to the service name, not the C-tags to the right.

Because ECX Fabric systems have no way of knowing which C-Tag will be bound for a service, a buyer is normally required to gather this information from the provider in advance and enter it into the ECX Fabric when creating a connection.

For this purpose, ECX Fabric offers the optional Enhanced Dot1q to QinQ Translation Support.  This service allows a provider to name the services that a buyer will connect with. When the buyer creates a connection, the system will present them with these more familiar names in lieu of the C-Tag matching exercise. For example, a provider might define Acme Cloud Storage and Acme Cloud ComputeCompute refers to the resources or assets necessary to run a device in the ENE platform. In most ways, the ENE platform is an infrastructure as a service platform underneath, but we typically do not ask customers to get involved in that aspect of the platform. To run efficiently, each device and/or service requires some pre-determined amount of compute. Equinix has thoroughly tested each device and service with the vendor before offering it to the public. This testing ensures that the amount of compute selected on the user's behalf is already optimized to run smoothly with the vendor's recommendations. Customers do not need to customize or tweak the compute in most cases. and Acme Cloud CRM.

How are we doing?