Connecting Virtual and Physical Environments

Connecting customer environments together is as important as connecting to clouds and the Internet for most customers. The ECXF deployment guide contains significant detail regarding solution design and how to connect to various clouds.

As the ECX FabricECX Fabric is an advanced interconnection solution that improves performance by providing a direct, private network connection grows in its use case coverage, more network service providers and Enterprises are joining the platform and offering their products and services to connect to, as well. But occasionally, the destinations you need to reach from your virtual device are not already present on the ECX Fabric. Thus, we need an alternative for reaching them.

To connect a virtual device to a physical environment, the user needs to access the “outside” physical world from a device that is deployed on a shared compute node with virtual interfaces. Although it is the same end result we want to achieve, it is a different process than literally connecting cables to your physical router. This traditional way was usually done with cross connects from one data center or cage space to the next:

In order to facilitate this same activity with a virtual device that does not occupy a cage in the same way as above, we will need to virtualize certain aspects of the solution, and there are many ways to do so.

The rest of this document focuses primarily on connecting to your Network Service Provider, a specific and common use case that often involves a physical aspect to the solution. However, the principle of connecting to another destination that is not already on ECX is effectively the same process.

All NE devices connect to the outside world through the ECXF platform or through the Internet (aka Equinix ConnectEquinix Connect is a turnkey solution for customers to connect to the Internet. The customer will connect their equipment to an Equinix-provided router or switch by means of one or more physical cross connects), and this satisfies many use cases with no further connection needs. However, many users find that they want their virtual devices connected to an NSPNetwork Service Provider that they will or are already doing business with. Often this helps “normalize” the device with the rest of a global network deployment by integrating it with an existing MPLS network, for example:

This is facilitated through the ECX, and all traffic flowing in and out of the ECX does so through a physical port, whether it is dedicated to a single user or service/use case, or it is used in a multi-tenant way.

For a virtual device user to get to a network service that you have procured, there are a few ways this can be done through the ECX, and we call this “bringing your own connection” or BYOC:

  • NSP is a SellerA seller is a user who makes their services available to end customers through ECX. This guide refers to sellers for shorthand, but ECX generally regards a “seller” as an activity rather than a static person. on ECX: The network provider offers its network products and services publicly through the ECX in the same way that others offer their services; and the virtual device owner will create a connection to the known, published service on ECX

  • Bring your own Network Service: The user will purchase connectivity from a network provider in a specific data center; and the NSP will terminate that connectivity as a port in an Equinix facility and provide details to you so that you can order a port and connect to it through the ECX

  • Connect to your Collocated Resources: The user has at least one physical deployment in an Equinix facility somewhere globally; the needed network connectivity is already inside that collocation facility; and the virtual device will connect to that collocated space through a port at the “edge” of the customer’s physically reserved space

Ultimately, the way we facilitate ANY connection from virtual to physical, including a network connection from the customer provider, is through the ECX, with the same demarcation principles as in the first drawing above:

Further details for each method are specified below.

The use cases and reasons for doing this are numerous, and may include:

  • Connecting the virtual device to a LAN or WAN network

  • Connecting the device to an existing global network service provider that the user is contracted with for MPLS, EVPL, Internet, or other telecommunications services

  • Chain the virtual device to another virtual or physical device or environment off the Equinix platform

  • Attach the device to the edge of other private resources such as deployed servers, storage, or other IT equipment

Basic Steps and Concepts to Connect

In any of the above cases, the basic steps are about the same, as specified below. The implementation of them may differ depending on which method you need:

Additional details about each step are below. Note that there may be multiple steps within it, or none at all, depending on your connection needs.

Order Network Services

The first step is to order services from the network provider of choice, if you have not already. What you order will vary greatly and Equinix offers no specific guidance on which providers and products are best. That said, when we observe deployments from specific providers and product types that go well, we will catalog them in our documentation so you know which ones work best.

If the NSP is part of the ECX selling their services (you can browse and discover your options on ECX, or see this topic for more details), there is a very good chance that their product will interoperate well with your device.

When terminating network services to your virtual device, there may be special configurations needed to ensure they operate properly. The user is responsible for ensuring this is done properly on his or her device as Equinix is not aware of the needs of each product and the NSP requirements. While Equinix cannot predict or specify the exact needs of every NSP and their portfolio of products globally, the services generally boil down to a few categories:

  • Ethernet type, Layer 2 services such as EVPL, E-LAN, or EPL

  • Layer 2.5 type services such as MPLS

  • True Layer 3 peering services such as IPVPN or DIA/high-speed internet

Each of these network services will drive different needs on your device, whether it be IP addressing, protocol configuration and enablement, VLAN assignment, rate limitingA rate limit is a bandwidth control that is placed on a connection or service that limits the amount of traffic that can be sent or received to an amount less than the physical size of the ports. This is also referred to as a policer or “policing” a service, and is typically implemented using a VLAN on a sub-interface. or others.

Not all traffic types have been tested to work with every virtual device, but the platform is designed to be quite open and flexible. Your NSP’s guidance on configuration will be very important to the success of the interconnection.

Equinix has a few rules of thumb when deciding and provisioning network services that will increase the likelihood of it being successful:

  • The handoff from your network provider must be a VLAN-tagged service, whether it is already on ECX or you will connect it to ECX

  • Per above, you will need to know the VLAN assigned to the traffic so you can configure it properly on the ECX

  • We expect that your network service provider will provide the necessary IP addressing, label switches, VLAN, or other logical inventory needs to configure your device and the port fully

  • In theory, nearly any protocol can be supported if the specification from your virtual device vendor says it is supported, but we cannot test every single one. Consult the ECX documentation to discover if there are any limitations to that platform for your traffic type. You can also review the device matrices to see if your specific vendor has any limitations.

  • If you terminate a public Internet service, the number of routes may be restricted as a full Internet routing table could heavily burden the performance of a virtual device. We recommend you either consider physical deployments for route tables beyond 2-5K routes, or deploy with NAT

  • Your NSP service should be policed or rate limited and should never exceed the total size of your virtual devices’ licensed throughput

Buy and Configure ECX Resources

In order to connect through the ECX, certain things must be present, whether they are owned by the NSP or the customer. In very simple terms, in order to connect from one side to the other, two ports and a connection between them is required. Fortunately, many of these components are already present.

On the virtual device side, each device already comes with a virtual port facing the ECX, and the method for creating a connection is covered extensively elsewhere. Therefore, most of the work needed is to get to the network service (or the Z-Side):

  • If the NSP is an active participant on the ECX selling services, you simply need to create a connection to that service, so you can jump to the next step

  • If the NSP can provide a port to you on the ECX, they will specify which service to connect to – and it could be a “private” service (more on service profiles below). You can jump to the next step to connect the device, but must first have permission from the NSP to see the service to connect to

  • If the NSP will provide a physical tie-down location only in an Equinix data center, you will need to procure a port to connect the NSP to, and then you will define a service around that port so that you can connect to it

When you opt to connect to your network service provider from a virtual device, we recommend that you use the special connection flows rather than standard create connection flows. This is because it will ensure your NSP connection is on a discrete interface and VRF that allows you to configure it separately and differently from other ECX cloud traffic. Each virtual device is launched with a reserved network provider interface whether you opt to use it or not:

About Service Profiles

As of the current release, the way you connect to anything on the ECX as a destination or Z-end is by using a Service Profile. Anyone can create a service profile on ECX with a port, and the service profile can be set to be private so that only users in your customer organization can see and use it. You can also whitelist other NE and ECX users to see your private profile even if they are not part of your organization or account.

Additionally, you can delete the profile or remove the port from the profile immediately after creating a connection from your device to the port, and the connection remains in place. Users can also add BGPBorder Gateway Protocol. A standardized exterior gateway protocol designed to exchange routing and reachability information between autonomous systems on the internet settings as with other services to ensure peering occurs between the environments. For this type of connectivity, Equinix recommends a Layer-2 service profile. Information about configuring a Layer-2 service profile can be found here.

More information on service profiles in general can be found in the ECX documentation here.

NSP is a Seller on ECX

This is by far the simplest method for virtual device owners, and we encourage network providers to participate in the ECX ecosystem wherever possible.

Learn More

If the NSP has a presence on the ECX Fabric, you can easily find them in the list of services available, just as you would with a cloud provider. A great example of this is Verizon's "Software Defined Interconnect," available in several markets globally.

The design is fast and simple, and we strongly encourage NSP's to adopt this model for the benefit of our mutual customers. The user need only create a connection to the service, and the solution looks like this, where the blue arrow is a connection requested on the ECX:

Bring Your Own Network Service

If you'd like to connect to a network provider with a virtual device, but the network provider is not present on ECX as a seller, they must be able to do one of two things:

  1. Have a presence on the ECX Fabric that they use for BUYING ECX services and be able to use that port as a destination for you to connect to

  2. Have a physical presence in Equinix facilities where they can reserve a physical port for you and generate a Letter of Authorization/Customer Facilities Assignment – LOA/CFA for short

If the NSP will use the second method above, the virtual device owner will follow this process to get connected to the LOA/CFA:

A couple of terms are important here, if you are not familiar with them:

  • LOA/CFA, or Letter of Authorization/Carrier Facilities Assignment – think of the LOA as a "permission" that the owner of a space in a data center issues to another that allows that entity to access their cage for a certain purpose. In this case, the purpose is so that the virtual device user can connect to the NSP. The CFA is a specific location in the data center, usually referring to cabinets, shelves, and plugs, where the connection shall occur.

  • Remote port – a port is a physical place where interconnection occurs between two parties. The cables from each party are literally plugged together so that data can pass. Generally, the port is owned by the same party where the port is physically located. A remote port indicates that a port is present in a location that is NOT OWNED by the customer that will be responsible for and own the port. In this scenario, the customer of the virtual device will procure a remote port and "own" that port in a physical location that he has no actual presence in.

A remote port can be used when there is no physical CPE router collocated in an Equinix datacenter. In this case, the virtual router can be connected to the ECX switch via a Layer-2 service profile with the NSP connection terminated directly on the ECX switch. In this scenario the service profile is owned by the customer and is responsible for setting the correct attributes to establish connectivity. It would look like below, where the blue arrow is an ECX connection from the virtual device to the port that the user purchases so that it can be connected to the NSP:

To connect, you place an order from your NSP and then provide Equinix with a LOA/CFA. The LOA/CFA gives Equinix the authorization to connect between the NSP demarcation point and the ECX switch to establish connectivity as shown above. As in the case of a physical connection, you can also connect to any location on the fabric – either local or remote.

Connect To Your Collocated Resources

With this deployment, your CPE may be collocated within an Equinix data center. In order to reach it, you will need a physical port on the cloud exchange and a defined service profile, explained here, to connect the virtual router to it. In the diagram below, some physical equipment in your cabinet connects to the virtual router via the ECX fabric:

Note: This virtual cross-connect can happen between any two locations that are on the ECX Fabric – either local or remote. In the below example, the owner of a virtual device has connected remotely to a cage he owns in another metro, using the ECX Fabric as the method of reaching to that port.