A Layer 3 service is created by combining RIs into a service profile, and then defining its characteristics and business rules:
The following is the basic workflow to get started:
Equinix recommends you always have a second and redundant RI that advertises the same routes as the primary, and include BOTH in your service profile, per metro. When this is done, a buyer who subscribes to your service, even if they do not have redundancy themselves, will continue to receive routes even if one of your devices fails:
Throughout the lifecycle of your service, you may add ports or RIs to your profile, remove or edit them and other activities. You can use connectors to add many ports to one or more RIs, swap between or migrate services from one device to another without taking down the RI and you can add or remove RIs from the service profile. Be aware, however, that this could have consequences to live customers if the advertised routes change over the lifecycle.
Example above: Multiple connectors pointing to the same RI. Assuming all connectors accept all routes, one can be taken down without compromising any subscribed users
As in the example above, all RIs and the advertisements to them will be advertised to any subscriber. The subscriber does not choose whether to receive only the “orange” or “green” routes above. As a provider, if you want orange and green to be discrete services that are purchased and assigned separately, you should have them in separate service profiles. They do not necessarily have to be on different ports.
Unlike Layer 2 service profiles, it is not necessary, by default, to “approve” each subscription as it is created by a buyer. As soon as the pre-requisites have been met, the subscription goes live and route advertisement begins.
Providers can opt to request an authentication ID on the subscription from the customer, but the ECX system does not currently validate it before traffic begins to flow. Providers can find the authentication ID in the portal or API with the record of the RIs to which it is subscribed.
Users can enable their profile to receive remote subscriptions, meaning that buyers can reach your services even if they are not physically deployed where your service profile is available. However, the provider must be capable of accepting routes from all interconnected metros, which may significantly increase the size of the route table. This includes the Equinix public routes, which amount to a /24 per metro.
Example above: Service profile is available in metros 2 and 4 with buyers in metros 1-4. Each metro has a block of IP addresses used for NAP, reservation and other purposes by Equinix. Provider must allow advertisement from all in order to received remote connections.
The setting for receiving remote connections is all or nothing for a service profile; users cannot elect to receive remotes into one metro and not another. If this is the desired effect, providers should create two separate service profiles.