Testing IXP Configurations Without Breaking Production: A Digital Twin Approach

Validating route server configurations and onboarding new customers at an Internet Exchange Point carries inherent risk. A misconfigured filter, an overlooked prefix limit, or an untested policy change can propagate across the fabric and affect dozens of networks in seconds. Yet most IXP operators still push changes directly to production because, until now, there was no practical way to test them in an isolated environment that faithfully mirrors the real thing.

The IXP Digital Twin project - developed in collaboration with NAMEX - addresses exactly this gap. We introduced the project in a previous RIPE Labs article. Since then, we have built a dashboard-driven workflow that makes it straightforward for any IXP operator to spin up a digital replica of their exchange, verify routing state, and run quarantine checks on new members. All without touching the production fabric.

This post walks through the key ideas and capabilities. A full step-by-step tutorial is available in the project wiki.

What the digital twin does

At its core, our digital twin is a lightweight network emulation (powered by Kathará) that reconstructs the IXP’s peering LAN, route servers, and customer sessions from three inputs:

1. A peering list: the set of connected members with their AS numbers, peering addresses, and MAC addresses. This can be exported directly from IXP Manager or created as a simple JSON file.
2. The route server configuration: the production bird.conf or openbgpd.conf, exactly as it runs on the real route server.
3. A RIB dump: the current routing state, obtained from BIRD or OpenBGPD.

From these three artefacts, the digital twin builds an emulated environment where every customer is represented, every BGP session is established, and every route is announced, replicating the production routing state in a sandbox you can break without consequences.

Scope and focus: route server validation and customer onboarding

It is important to note that the digital twin does not mirror the IXP’s physical fabric interconnections - the switches, VLANs, trunk links, and vendor-specific switching configurations that form the underlying infrastructure. Emulating the complete switching fabric would require running proprietary, resource-intensive virtual appliances, managing complex multi-vendor configurations, and building an environment that replicates every detail of the layer-2 topology. Such an approach would shift the focus entirely, transforming the digital twin from a lightweight routing validation tool into a full-scale data centre infrastructure replica.

That is not the goal of this project. The digital twin is purpose-built to validate routing behaviour - BGP sessions, route filtering, prefix announcements, and policy enforcement at the route server level. The emulated peering LAN is a simple shared layer-2 segment, sufficient to establish BGP sessions and exchange routes, not a replica of production switching hardware. This design choice keeps the environment lightweight, fast to deploy, and focused on the operational risks that matter most to IXP operators - i.e. misconfigurations in route server policy, incorrect filters, and problematic customer announcements.

A dashboard for IXP operators

We designed the tooling with IXP operations teams in mind. The IXP Digital Twin Dashboard provides a web interface to:

• Configure the digital twin: define the peering LAN prefix, upload peering data and RIB dumps, specify route server images and AS numbers, and optionally attach RPKI validators.

• Launch and monitor the emulation: start the digital twin with a single click, view device statistics (CPU, memory, network counters), and inspect the state of each emulated router.

• Compare RIBs: run an automated comparison between the routes in the emulated route server and the uploaded dump. Any discrepancy (a missing route, an unexpected announcement) is flagged immediately. When the configuration is correct, the comparison reports zero differences, confirming that the digital twin is a faithful replica.

• Configure quarantine checks: define which onboarding tests to run for new members and tune validation thresholds (for example, maximum prefix counts, traffic capture duration, and probe targets) before granting production access.

Quarantine checks: validating new members before they go live

One of the most compelling use cases is customer onboarding. Before a new member is connected to the production fabric, they can be pointed at the digital twin instead. A dedicated Quarantine Dashboard then executes a battery of automated checks:

• Connectivity: layer-3 reachability (ping), path MTU verification (ensuring 1500-byte frames pass end-to-end), and proxy ARP validation.
• BGP: session establishment with the route server and RIB validation, confirming that the prefixes announced by the customer match expectations.
• Security: scanning for unauthorised services on the customer’s port and monitoring traffic patterns for policy violations.

The operator selects which checks to enable and configures thresholds (maximum prefix counts, traffic capture duration, probe addresses). The quarantine dashboard then presents a clear pass/fail result for each check. Only when all checks pass is the customer cleared for production.

This approach shifts the risk of misconfigured routers, unexpected announcements, or non-compliant setups from the live fabric to the sandbox, catching problems before they can affect other members.

Keeping it in sync

A digital twin is only useful if it reflects reality. We recommend a daily synchronisation procedure that refreshes the three core inputs:

1. Pull the latest peering list from IXP Manager (a single API call).
2. Retrieve the current route server configuration from your configuration management system or directly from the production router.
3. Dump the RIB from the live route server.

Once the updated files are in place, a reload (triggered from the dashboard or via a script) brings the digital twin back into alignment with production. This can be easily automated as part of a daily maintenance routine.

Getting started

The project is open source and available on GitHub:

• IXP Digital Twin: the core emulation engine
• IXP Digital Twin Dashboard: the configuration and monitoring interface
• IXP Quarantine Dashboard: the customer onboarding and validation tool

We ship ready-to-use container images for BIRD v2, BIRD v3, and OpenBGPD route servers, so you can choose the implementation that matches your production environment.

The only prerequisite is Docker. The dashboards ship as containerised applications: a single docker compose up brings up both the backend and frontend.

The full tutorial includes a ready-made Kathará lab with a three-member IXP so you can try the entire workflow end-to-end in minutes.

Conclusion

Every IXP operator knows the tension between needing to evolve configurations and the fear of breaking a running exchange. The digital twin removes that tension by providing a safe, automated environment to validate changes, test new member setups, and verify routing state, all before anything touches production.

We believe this approach can meaningfully reduce operational incidents at IXPs of any size. We would love to hear from operators who try it. If you have questions, feedback, or would like help setting up a digital twin for your exchange, please get in touch.