What the Internet Exchange Point in Your City Actually Does

Somewhere in your city, there is likely a nondescript building that handles more internet traffic than any individual data center in the region. It might be in an industrial area, a converted office building, or a colocation facility tucked into the edge of a business park. From the outside, it looks unremarkable. Inside, hundreds or thousands of organizations have their network equipment in racks, connected to a shared switching fabric, freely exchanging internet traffic between themselves without paying transit fees. This is an Internet Exchange Point, and understanding how it works explains a lot about why the internet is structured the way it is, why your streaming video loads faster from a local cache than from a server across the country, and why the internet has been resilient to the various catastrophic failures that single points of failure would have caused.

The Problem IXPs Solve

The early internet connected academic institutions via dedicated circuits between specific nodes. As the internet grew commercial in the 1990s, organizations needed to exchange traffic with each other, and the obvious mechanism was peering: two networks (ISPs, businesses, content providers) agreeing to exchange traffic between their customers at no charge, since both benefit from the arrangement. If your customers want to reach my customers and my customers want to reach yours, we can connect directly and avoid paying a third party to transit that traffic.

The problem with bilateral peering at scale is combinatorial: if there are 100 networks that want to peer with each other, that’s potentially 4,950 bilateral connections. The physical and administrative overhead is enormous. Internet Exchange Points solve this by providing a shared infrastructure — usually a large layer 2 switching fabric — where any member can peer with any other member through a single physical connection to the exchange. Instead of 4,950 connections, each network needs one connection to the IXP, and it can peer with all other members at that location.

The economics are compelling. Transit traffic — routing your packets through a third party’s network — costs money, billed per megabit or gigabit. Peering traffic at an IXP costs the port fee to connect to the exchange and the colocation cost for your equipment. For high-volume traffic between networks with compatible interests, peering is dramatically cheaper than transit. The largest internet companies — Google, Meta, Amazon, Netflix, Akamai, Cloudflare — have their own global networks and peer extensively at IXPs worldwide, which is why traffic to their services typically travels fewer hops and with better latency than traffic to less well-connected providers.

How Peering Actually Works: BGP and Route Servers

The routing protocol that makes IXP peering work is BGP — the Border Gateway Protocol. BGP is how autonomous systems (AS numbers — the unique identifiers assigned to organizations operating their own networks) advertise which IP address ranges they can reach and negotiate with other networks about how to route traffic. At an IXP, each member connects their router to the shared switching fabric and establishes BGP sessions with other members to exchange routing information.

In the early IXP model, every member had to establish a bilateral BGP session with every other member it wanted to peer with. At a large IXP with hundreds of members, this is still a combinatorial problem. Route servers solve it: a route server is a BGP speaker operated by the IXP that maintains BGP sessions with all members and distributes their routes to all other members who opt in. Instead of establishing 500 bilateral BGP sessions, a member establishes one BGP session with the route server and gets the routing information for all other participating members.

The traffic doesn’t flow through the route server — that’s just route distribution. Actual packets travel directly between member networks across the shared switching fabric. The route server is a control-plane component; the data plane is the IXP’s Ethernet switching infrastructure.

IXP members also negotiate bilateral peering agreements directly, outside the route server. These allow for more specific terms — traffic ratio requirements, filtering of specific prefixes, geographic scope of the peering relationship. Large networks often have detailed peering policies (some are public, documented on PeeringDB) that specify exactly what’s required to establish a private interconnection with them.

The Major IXPs and Their Scale

The largest IXPs in the world handle staggering traffic volumes. DE-CIX in Frankfurt is consistently at or near the top, routinely handling peak traffic above 15 Tbps (terabits per second) and connecting thousands of member networks. AMS-IX in Amsterdam, LINX in London, NYIIX and Equinix IX in New York, and the various SIX locations in Seattle are among the most significant globally. But there are hundreds of IXPs worldwide, in cities large and small — the Euro-IX association tracks over 1,000 IXPs globally.

What’s happening at these facilities is the efficient routing of enormous fractions of global internet traffic. When you load a YouTube video, the traffic typically passes through an IXP where Google has peered with your ISP (or through a Google cache server colocated at a data center connected to the IXP) rather than transiting multiple networks across the country. This is why video loads faster in well-peered cities than in poorly-served ones — proximity to content providers’ networks at IXPs matters for latency and throughput even more than raw bandwidth.

The Impact on Your Internet Experience

The presence and quality of IXPs near you affects your internet experience in ways that are largely invisible but measurable. In cities with well-developed IXP ecosystems — Frankfurt, Amsterdam, London, New York, Seattle, Tokyo, Singapore — content providers typically have local nodes or peering connections that minimize the distance your traffic travels. A traceroute from a Frankfurt address to Google typically shows two or three hops to Google’s network; a traceroute from a smaller European city without strong local IXP presence may show the traffic routing to Frankfurt or Amsterdam before reaching Google, adding 15–30ms of latency.

For most internet applications, this latency difference is imperceptible. For real-time applications — video calls, online gaming, financial trading systems, some industrial control applications — it’s meaningful. The latency difference between traffic that exchanges at a local IXP versus traffic that transits multiple networks across continents can be 50–100ms, which is noticeable in interactive applications even if it’s invisible loading a web page.

CDN placement follows IXP locations closely. When Cloudflare, Akamai, or Fastly describe their “edge” nodes, they’re largely describing servers colocated at or near major IXPs, where they can exchange traffic with local ISPs at low latency. The same content served from a CDN edge node 10ms away arrives faster than from an origin server 80ms away, and the difference compounds under load when network congestion increases. Peering quality is why CDNs work, and IXPs are why peering works at scale.

IXPs and Internet Resilience

The distributed nature of the IXP ecosystem is one of the reasons the internet is more resilient than a centralized architecture would be. When a large transit provider experiences an outage — BGP route leaks, cable cuts, hardware failures — traffic can often reroute through peering connections at IXPs that bypass the failed transit path. The 2021 Facebook outage (a BGP misconfiguration that withdrew Facebook’s own routes from the global routing table) affected Facebook’s services completely but didn’t significantly affect the broader internet precisely because the rest of the internet’s peering fabric continued to function without depending on Facebook’s routes.

This resilience isn’t automatic or guaranteed. Regions that depend heavily on a small number of transit providers with limited local peering options are more vulnerable to single points of failure. Parts of Africa, Southeast Asia, and parts of Latin America have historically had limited IXP infrastructure, which meant that traffic between two cities in the same country would sometimes route through Europe or North America — a phenomenon called tromboning that adds latency and creates unnecessary vulnerability to intercontinental links. Growing local IXP ecosystems has been a priority in digital development programs in these regions, and the results are measurable in latency improvements and reduced transit costs for local ISPs.

What You Can Look Up About Your Local IXP

PeeringDB (peeringdb.com) is the public registry of networks and IXPs worldwide. You can search for your city and find what IXPs exist there, how many members they have, what their traffic volumes are, and which networks are present. For any organization’s AS number, you can see their peering policy, which IXPs they’re present at, and in many cases what traffic exchanges they’re willing to establish. Hurricane Electric’s BGP toolkit and RIPE’s tools let you trace routes and see how traffic actually flows between networks from your location.

These aren’t tools most users ever need — the IXP infrastructure works transparently and well enough that you only notice it when something goes wrong. But for anyone trying to understand why their connection to a specific service has different latency or reliability than connections to others, understanding the peering and transit landscape between your ISP and that service’s network is often where the answer lives. The internet is not a cloud. It’s a specific set of interconnected autonomous systems, and the quality of their interconnections at IXPs is a fundamental determinant of what your internet experience actually feels like.