Apstra’s Intent-Based Networking
Through some of the work I’ve recently done, I’ve learned more about what products and services Equinix provides. This blog will discuss one of the services Equinix offers, one which is evolving rapidly and has several interesting aspects.
Namely, Equinix Cloud Exchange™ (ECX) and ECX Fabric.
It turns out that if you have an Equinix presence, there’s a lot that ECX can do for you. As far as getting a footprint (presence) at an Equinix facility, it doesn’t necessarily mean signing up for rack space – it can be done via a partner. That will be a subsequent blog topic.
Many of the Equinix sites support ECX, which gives you a relatively easy and fast way to connect from your Equinix presence to a partner Cloud Service Provider (CSP). To use ECX, you do have to get your onsite device physically patched to ECX, at 1 or 10 Gbps, which might take up to 10 days. Typically, this process is done once per Equinix site that you have relevant equipment at.
I suspect ECX physically might consist of several large L3-capable switches, each connected to a pair of routers at the participating CSPs. The other key part of ECX is that its web-based portal automates setting up a L2 (dot1q- or QinQ-based) or L3 (for certain CSPs) connection to the chosen CSP and Virtual Private Cloud (VPC) instance.
Using the ECX web portal to connect virtually to one of the supported CSPs takes about 20 minutes for the Equinix part of the connection. ECX is effectively a set of virtualized patch cables. There are shared links and no Quality of Service (QoS), but managed oversubscription levels.
Using the ECX Portal sets up half the connection. You need something to, in effect, plug that virtual patch cable into at the CSP end. Assuming you have credit card or billing authority set up with the CSP (a first-time chore likely to require a PO), you will have to set up the CSP VPC or virtual port / service. Both ends will need to agree on the dot1q tag or tags that mate the two ends of the virtual connection up (or arrange to have Equinix alter them in the middle). You can then BGP peer across the virtual connection.
The list of ECX supported providers varies by Equinix site. Among those listed for Washington D.C. are Microsoft Azure ExpressRoute, AWS Direct Connect, ServiceNow, and about 30 other providers. For more details, see the ECX Fabric web page.
To sum up, once you’re connected to ECX, and modulo sorting out billing info with CSPs, you can spin up a complete new VPC instance and an ECX to VPC connection in under one hour.
Equinix recently announced ECX Fabric, which extends the ECX function between ECX sites. That doesn’t sound like much, but it is. I’ll explain and rave about it a little, so you appreciate what that does for you.
Suppose you need to access CSP A in ECX location B, but your presence is elsewhere, say in ECX location C. You can now use the ECX portal to set up a link from ECX C to ECX B, thence to CSP A. You would probably want to pick a nearby location to minimize latency, assuming the CSP has a reasonably broad geographic footprint within Equinix.
More than that, you can connect to your other sites or to consenting other parties that are on ECX at the same or another ECX location. So, in effect, ECX Fabric turns ECX into a giant virtual patch panel for connecting rapidly to other entities that are also connected to it.
Right now, Equinix is supporting ECX Fabric regionally, as in, you can click and get connectivity across the US or Europe. Billing is monthly (for any fraction of a month), but you can turn the connectivity up or down. Agile WAN on demand, in effect!
Global connectivity, or ECX Fabric to other regions (US, EU, etc.) is due around June.
My understanding is that speeds up to 10 Gbps are supported, but 40 and 100 Gbps are not currently supported.
Pricing is between you and your local Equinix sales rep. My impression is that across the country, 10 Gbps costs what a local T1 used to cost (YMMV).
That’s all a bit abstract, so maybe a diagram would help.
The above diagram shows three ECX / ECX Fabric virtual connections as heavy blue lines. One connects Corporate presence in Equinix Site A to CSP1: AWS. That’s “plain” ECX.
The other two connections exhibit ECX Fabric. They extend to or through Equinix Site B, which (for now) is within the same region, say US or EU. One is a remote connection to CSP2: Azure – perhaps Azure was not available at Equinix Site A. The other connection terminates at a corporate presence in Equinix Site B. I deliberately left this ambiguous – it might be the same corporation, or another.
Non-Equinix corporate sites 1 and 2 are shown at bottom left and right. Routing allows them to use the ECX virtual connections. They might also be connections to e.g. a corporate MPLS WAN or a MetroEthernet network. Firewalling the CSP connections might be a good idea, but has been omitted to focus on connectivity.
How do you access all this?
You need a presence in one or more Equinix facilities. You can go the route of your own rack space and your own router (switch, firewall, etc.), or you can contract for connectivity through a managed services provider via some form of shared facility. This is called a “Performance Hub”.
In my next featured blog, we will cover Performance Hubs in more detail.
NetCraftsmen does some work for / with Equinix, so this blog may not represent completely neutral opinions.
Comments are welcome, both in agreement or constructive disagreement about the above. I enjoy hearing from readers and carrying on deeper discussion via comments. Thanks in advance!
Hashtags: #Equinix #cloud
Apstra’s Intent-Based Networking
Silver Peak is Serious about SD-WAN
BlueCat: DNS, DDI + Visibility and Workflow Automation
Virgilio “Bong” has sixteen years of professional experience in IT industry from academe, technical and customer support, pre-sales, post sales, project management, training and enablement. He has worked in Cisco Technical Assistance Center (TAC) as a member of the WAN and LAN Switching team. Bong now works for Tech Data as the Field Solutions Architect with a focus on Cisco Security and holds a few Cisco certifications including Fire Jumper Elite.
John is our CTO and the practice lead for a talented team of consultants focused on designing and delivering scalable and secure infrastructure solutions to customers across multiple industry verticals and technologies. Previously he has held several positions including Executive Director/Chief Architect for Global Network Services at JPMorgan Chase. In that capacity, he led a team managing network architecture and services. Prior to his role at JPMorgan Chase, John was a Distinguished Engineer at Cisco working across a number of verticals including Higher Education, Finance, Retail, Government, and Health Care.
He is an expert in working with groups to identify business needs, and align technology strategies to enable business strategies, building in agility and scalability to allow for future changes. John is experienced in the architecture and design of highly available, secure, network infrastructure and data centers, and has worked on projects worldwide. He has worked in both the business and regulatory environments for the design and deployment of complex IT infrastructures.