An Internet Exchange Point (IXP) is a place where networks meet and allows them to send traffic straight to one another with fewer hops, latency, and improved performance, rather than routing traffic across different cities, or continents before reaching final destination.
The London Internet Exchange (LINX), operates several IXPs across the globe and has over 900 connected members. Running an exchange at this scale means equipment from multiple vendors, thousands of BGP sessions and provisioning of every port and service from each member. Doing all of this manually, while the network continued to grow geographically and increase in size and complexity, would have created significant scalability challenges. That is why LINX turned to automation.
Life Before Automation
A decade ago, engineers made all network changes manually, whether that be customer edge interfaces, peering infrastructure or core fabric, typing commands into one device at a time on the command line via CLI. It worked but carried a heavy operational overhead. Every change had to be made carefully, reviewing and auditing changes was difficult, and each new member added more manual work. Furthermore, the source of truth was often out of sync, while configuration conventions and styles could vary significantly across devices. This lack of consistency made changes less predictable and increased the coordination required between engineers.
If LINX wanted to connect new members and grow the exchange safely, something needed to change.
Automating Network Configuration
LINX built its first Network Configuration Automation Platform (NCA), which generates each device’s configuration from a single trusted set of network data and standardised configuration templates. An approach known as data-driven configuration. Before anything is deployed it shows engineers exactly what will change, and every change is version-controlled. This has allowed LINX to be more consistent, because every member port is set up in the same way; to deploy more safely, because changes are checked before they reach the network; and to keep a clear audit trail. Automation is only as good as the data behind it, which led to LINX building its own source of truth to keep , live picture of the network.
Scaling Network Automation
While the original NCA was designed around supervised changes initiated by network engineers, NCA 2.0 was built to perform low-risk network changes asynchronously and without human supervision.
Requests are passed to the automation engine through messaging queues and processed by workers in the background. This allowed LINX to move from automation designed primarily for network operators to an automation engine capable of supporting member-driven requests at scale. This was an important foundation for self-service: without an automation platform capable of safely making asynchronous network changes without an engineer overseeing each one, exposing those capabilities to members would not have been practical.
Bringing Self-Service to Members
Network automation alone, however, is only one part of delivering a service. LINX built its Order Management System (OMS) to orchestrate the complete service workflow around those automated network changes.
OMS coordinates the systems and activities involved in delivering a service, including the LINX Portal, IX-API, technical service inventory (the network source of truth), network automation and other business and operational systems. Where a network configuration change is required, OMS can invoke NCA 2.0 as part of that workflow.
This combination of service orchestration and unattended network automation is what made member self-service possible. Members can request supported changes through the LINX Portal, while OMS coordinates the workflow and NCA 2.0 performs the required network changes in the background.
When Automation Needs a Human
Not everything can, or should be, fully automated. Some service workflows need to pause while a member or network operator completes an external action.
Quarantine testing is one example. If a peering service requires quarantine testing, OMS pauses the provisioning workflow. The member first checks that their router configuration is compliant with the LINX service requirements. When they are ready, they start the quarantine test from the LINX Portal. If the test passes, OMS resumes the workflow and automation completes the peering service configuration, moving it onto the production peering LAN.
The same pause-and-resume model is also used for operational tasks that cannot be automated, such as when a network operator needs to connect physical ports or complete ODF patching before provisioning can continue.
The same automation principles, along with key architectural components such as messaging queues, have also been applied to our route servers, helping us automate the configuration and management of thousands of BGP sessions used by our members.
Ten years on, it all adds up to faster provision, more consistent and real self-service for members, with engineers on hand for moments than genuinely need them.
To add or upgrade an existing service, LINX members can head over to the LINX Portal to see our automation in action.
New to LINX? Take a look at our interconnection services to see how we can help.
< Go Back