Configuring Layer 2 Service Offerings
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's important that the provider make clear to their customers the order of events in their own documentation. You might want to clarify when an end-customer will go through an intermediary to get to Equinix, and is unaware that their intermediary is 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's bound. While this can be helpful for providers and buyers alike, it can also be confusing for buyers.
Example: 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.