For years, an Internet Exchange Point (IXP) has been explained as a huge Ethernet switch where operators, content providers, and enterprise networks connect their routers to exchange traffic directly. This explanation remains useful, but it falls short for infrastructures like DE-CIX, LINX, or AMS-IX: behind the peering LAN, there are now distributed architectures across multiple data centers, with EVPN, MPLS, VXLAN, automation, and 100 and 400 GbE links.
The key aspects of large IXP architectures in 30 seconds
- An IXP provides a common Layer 2 infrastructure over which its members establish BGP sessions.
- Route servers facilitate multilateral peering but do not carry user traffic.
- DE-CIX completed in 2022 the migration of its Apollon platform to EVPN while keeping the service operational.
- LINX currently uses EVPN over MPLS on LON1 and EVPN over VXLAN on LON2.
- There is no single architecture: AMS-IX continues to document an MPLS/VPLS platform for its Amsterdam exchange.
This distinction is important because the Internet does not operate as a series of private circuits between each pair of operators. When two autonomous systems want to exchange traffic, they can establish peering, avoiding the need for such packets to necessarily traverse a transit provider’s network.
An IXP creates precisely the technical space for this to happen.
What really happens when a network connects to an IXP
From the member’s perspective, the operation can seem quite straightforward.
The operator connects one or more ports of its router to the IXP infrastructure. It receives IPv4 and IPv6 addresses belonging to the peering LAN and establishes eBGP sessions over that network with other organizations.
For example, a single IXP can have simultaneously connected:
| Participant | Role |
|---|---|
| ISP A | Internet access provider |
| Cloudflare | CDN and content network |
| Service and content provider | |
| ISP B | Regional provider |
| Cloud provider | Online infrastructure and services |
All can be on the same Ethernet infrastructure of the exchange, although this does not mean all are exchanging routes directly with each other.
The decision still rests with BGP.
An operator can maintain direct peering with Google and Cloudflare, use a route server to exchange routes with hundreds of other networks, and choose not to accept routes from specific participants.
The IXP provides the connectivity. Each member defines its policy.
This also corrects another widespread idea: the IXP does not decide how traffic flows between its participants.
It is the autonomous system routers that make those decisions using BGP.
Route server eliminates hundreds of BGP sessions
Route servers are one of the most important components of major exchange points.
Imagine an IXP with 800 participants. If one network wanted bilateral peering with all of them, it would need to manage hundreds of individual BGP sessions.
The route server simplifies this scenario.
The member establishes a session with one or typically two route servers. These receive routes advertised by other participants and redistribute them according to policies.
The key point is that the route server does not become the next hop of the traffic.
Its operation can be summarized as follows:
- ISP A announces its prefixes to the route server.
- Provider B also announces its routes.
- The route server shares B’s routes with ISP A.
- The ISP A router learns how to reach B.
- When traffic occurs, packets travel directly between A and B’s routers over the IXP LAN.
The route server participates in the control plane but not in the data plane.
In many IXPs, these systems are not large physical routers but use software like BIRD on Linux servers, primarily processing BGP sessions and policies.
For example, DE-CIX uses BIRD within its GlobePEER service.
The real challenge begins when the IXP spans dozens of buildings
A small exchange installed within a single data center can be built with a relatively simple architecture.
The challenge changes completely when the IXP extends across multiple data centers.
Participants can connect from data centers situated at opposite ends of a city or several kilometers apart. From both routers, the peering experience should be virtually identical.
A clearer visualization in WordPress flow could be:
Data Center A
Router of ISP A → IXP access node
Data Center B
Router of ISP B → IXP access node
Data Center C
Content provider’s router → IXP access node
All access nodes are connected via the IXP’s distributed internal network.
From the participants’ perspective, all still connect to the same peering LAN. Internally, however, the exchange operator needs to transport this service across different buildings, links, and network equipment.
Technologies like MPLS, VPLS, VXLAN, and EVPN come into play here.
DE-CIX migrated its network to EVPN with traffic running
DE-CIX offers one of the most interesting cases.
In December 2022, they announced completing the largest network upgrade in their history. Their Apollon platform evolved into Peering LAN 2.0, based on Ethernet Virtual Private Network (EVPN).
The migration is particularly notable because it was carried out with the exchanges still operational.
The process started in Phoenix and Frankfurt and later expanded to other locations using that architecture.
Before touching the physical infrastructure, DE-CIX virtually replicated peering LANs to test the new design.
One goal was to reduce issues that, while minor in small networks, can become significant with thousands of participants: ARP and Neighbor Discovery.
When a router wants to know which MAC address corresponds to an IP, it normally sends a request that can reach many devices in the Layer 2 domain.
With hundreds or thousands of routers connected, this traffic ceases to be negligible.
EVPN distributes IP-MAC information via its control plane and applies Proxy ARP and Proxy Neighbor Discovery, reducing the need to flood the LAN continuously with these requests.
DE-CIX also participated in developing RFC 9161, focusing explicitly on the operational use of Proxy ARP/ND over EVPN.
Some clients observed reductions of up to 25% in router CPU load after migration, thanks to decreased ARP and NDP traffic.
How EVPN works within an IXP
EVPN introduces a significant change compared to traditional Ethernet.
In a classical Ethernet domain, switches primarily learn which MAC addresses exist by observing traffic.
When they don’t know the destination, they resort to flooding.
EVPN incorporates a control plane based on MP-BGP that explicitly distributes this information among devices.
The simplified operation is:
| Step | What happens |
|---|---|
| 1 | A participant connects its router to the IXP access node |
| 2 | The node learns the MAC and related info |
| 3 | EVPN distributes this info to other necessary devices |
| 4 | Other nodes know where this participant is located |
| 5 | Traffic can be transported without relying on traditional flooding |
The user still perceives a LAN Ethernet environment.
The complexity is hidden within the IXP’s network infrastructure.
LINX shows EVPN can be built in different ways
Another example is LINX, the London Internet Exchange.
Its London network is divided into two major platforms, LON1 and LON2, which use different architectures.
LON1 employs EVPN over MPLS.
Its current infrastructure includes Juniper and Nokia equipment and is distributed across multiple London data centers.
LON2 uses a different combination:
EVPN + VXLAN + leaf-spine architecture.
LINX was one of the first major IXPs to adopt this disaggregated model, continuing to upgrade the platform in 2026 with Nokia IXR and SR Linux equipment.
To simplify visually:
| Platform | Overlay | Transport |
|---|---|---|
| LINX LON1 | EVPN | MPLS |
| LINX LON2 | EVPN | VXLAN |
| DE-CIX Apollon | EVPN | Distributed infrastructure |
The service offered to participants may be similar, even if the architectures internally differ.
This is especially valuable for network administrators and architects because it shows that EVPN does not require a single underlying transport type.
AMS-IX reminds us that VPLS has not disappeared yet
It would be incorrect to claim that the three major European IXPs already run entirely on EVPN.
The current documentation from AMS-IX for its Amsterdam platform still describes an architecture based on MPLS/VPLS.
AMS-IX uses Juniper MX10008, ACX7100, and Extreme SLX-9540 systems in different parts of its infrastructure, with the core also based on Juniper systems.
Members can contract interfaces of 10, 100, and 400 GbE.
There remains a common Ethernet infrastructure, with the MPLS/VPLS network carrying services across different AMS-IX locations.
This example is important because it prevents turning EVPN into a universal answer.
Operator networks evolve gradually, and existing architectures can remain valid for many years if they meet capacity, stability, automation, and security requirements.
Internal equipment is not just simple switches
Another idea worth updating is that within a large IXP, only simple Ethernet switches exist.
The service provided to participants is fundamentally Layer 2, but that does not mean the internal hardware lacks routing capabilities.
LINX, for example, uses Juniper MX10008 and Nokia 7750 SR, and AMS-IX also employs MX10008 platforms.
These systems are capable of running MPLS, BGP, EVPN, telemetry, and many features typical of carrier-grade networks.
The key difference is not what the hardware can do physically, but what role it plays within the exchange architecture.
The member’s router continues to run its BGP session.
The internal infrastructure is responsible for transporting frames to the correct participant.
EVPN reduces flooding and improves convergence
One of EVPN’s clearest advantages appears when comparing traditional MAC learning with a control plane-based model.
In a classic LAN, unknown MAC addresses can trigger discovery traffic or flooding.
With EVPN, there is distributed information about where each MAC resides and, in some designs, which IP address it is associated with.
Example:
Traditional Ethernet model
Router A needs to locate an IP → sends ARP → request may reach many devices → destination responds.
EVPN with Proxy ARP
Router A needs to locate an IP → EVPN knows the IP/MAC association → responds locally or controls the request.
The benefit grows larger with scale.
With ten participants, the impact is minimal. With hundreds or thousands of routers, control traffic differences become significant.
EVPN also provides mechanisms for multihoming, fast MAC withdrawal, and more deterministic failure management.
This explains why technologies initially linked to large provider networks and data centers are now naturally finding a place within IXPs.
What a network administrator or engineer can learn from IXPs
The architectures of these exchanges reveal a trend also emerging within data centers and provider networks.
Ethernet remains a fundamental technology.
What has changed is how a large-scale, distributed Ethernet network is built.
Instead of expanding Layer 2 domains solely using traditional mechanisms, many operators first establish a transport infrastructure and then deploy services via EVPN.
Underneath, MPLS may be used.
VXLAN may also be employed.
In other cases, VPLS is still in use.
The delivered service to the customer may look exactly the same: an Ethernet interface that can establish BGP sessions.
For those studying CCIE Service Provider or working with operator networks, this makes concepts like MP-BGP, MPLS, EVPN, VXLAN, Proxy ARP/ND, and route servers much less academic.
These technologies are running at every second on some of the most important nodes on the Internet.
A modern IXP can be summarized more precisely as:
On the outside, it’s a large Ethernet LAN; inside, it can operate as a sophisticated distributed carrier-grade network spanning dozens of data centers.
Frequently Asked Questions
What is an Internet Exchange Point?
An IXP is an infrastructure where different autonomous systems can exchange traffic directly. Participants connect their routers to a common platform and use BGP to establish peering policies.
Does the route server carry Internet traffic?
No. The route server facilitates BGP route exchange, but user packets travel directly between participants’ routers through the IXP infrastructure.
Do all major IXPs already use EVPN?
Not yet. DE-CIX and LINX use EVPN on some of their main platforms, while AMS-IX continues working with MPLS/VPLS for its Amsterdam infrastructure.
Why is EVPN useful in an IXP?
It enables Ethernet information to be distributed via a control plane, reduces certain flooding types, utilizes Proxy ARP/ND, and improves redundancy and convergence management in distributed infrastructures.
