Internet Exchange Point (IXP)

An Internet Exchange Point (IXP) is a physical facility. It is usually a neutral, carrier-independent data center. Many networks connect there to a shared switching fabric. They exchange traffic directly with each other through peering. An IXP is not a transit provider. It is also not a router. It takes no part in routing decisions and appears in no AS path. The IXP supplies the neutral location, the switches, the power, the cooling and the security. The connected networks decide what they exchange across it (Internet Society). Neutrality and Layer 2 operation define the category. The first thing to be called an exchange was the Commercial Internet eXchange. It would not be considered an IXP today, because it operated at Layer 3 and was run by one of its own participants (Wikipedia: Peering).

Here is the simple picture. Two networks in the same city can both connect to the local IXP. They can then hand traffic to each other over one port each. This avoids paying a backbone provider to carry it, often via another city. That is the whole value proposition. It is why almost every CDN is present at exchanges. An IXP is also called an Internet Exchange (IX). Public peering locations were historically called Network Access Points (NAPs). Being present at an IXP is not the same as peering with anyone there. An IXP guarantees no particular level of quality.

How it works

An IXP is a large Layer 2 Ethernet LAN. It can be one switch, or many switches interconnected across one or more physical buildings (Cloudflare engineering). Each participating autonomous system connects a router to that fabric. Such a system may be an ISP, mobile operator, cloud, CDN or content provider. It announces its IP prefixes over BGP, the inter-AS routing protocol specified in RFC 4271. Once two networks set up a BGP session, their routes are exchanged. Traffic can then flow directly between them. Any previous intermediary network is removed from the path.

There are two ways to interconnect at an exchange. The distinction matters:

• Public peering: many networks meet across the shared fabric. So a single physical port reaches many potential peers. That is what an IXP fundamentally sells.
• Private peering (PNI): a dedicated cross-connect between exactly two networks in the same facility. Its capacity is shared with nobody else. Most traffic between the largest networks actually moves over private interconnects, not public fabrics (Wikipedia: Peering). Vendors set thresholds for them. Cloudflare invites a PNI request from networks exchanging more than 10 Gbps of peak traffic in a single location (Cloudflare peering policy).

A full mesh of bilateral sessions scales badly. So larger exchanges typically also run route servers. A route server is a multilateral brokering system specified in RFC 7947. Each client announces its routes once to the server and receives everyone else's in return. A route server uses BGP but does not forward traffic, so it is not a router. The reach is real but partial. DE-CIX states that about 80 percent of the networks connected in Frankfurt are available at its route servers. So one session set reaches hundreds of networks without negotiating each one individually (DE-CIX Frankfurt).

Peering across the fabric is normally settlement-free. Neither party pays the other for the traffic exchanged. Each keeps the revenue from its own customers (Wikipedia: Peering). That is the opposite of transit, which is a purchased service. Settlement-free does not mean costless, though. Membership payments plus a per-connection fee keep an IXP operating. The cross-connect into the fabric is billed by the facility (Cloudflare engineering, DE-CIX Frankfurt).

Why it matters for a CDN

A CDN's job is to sit as close to end users as possible. IXPs are where the ISPs that serve those users already are. So CDNs put points of presence at or beside exchanges as a matter of design. Fastly states that its POPs are strategically placed near the highest-density Internet Exchange Points around the world (Fastly documentation). Cloudflare runs an anycast network spanning over 335 cities in more than 125 countries with an open peering policy (Cloudflare peering policy).

The payoff is in latency and in cost. The mechanism is worth stating precisely. If a user's ISP is directly connected to the CDN, the packets traverse fewer hops. The page loads faster. The ISP pays less to its transit provider and can reallocate that bandwidth (Cloudflare). The request reaches the CDN's edge server across the exchange fabric instead of across somebody else's backbone. Peering also improves resilience. If one of an ISP's transit providers fails, traffic to networks it peers with at the exchange is unaffected. The same two networks can peer at more than one exchange for diverse paths.

The scale involved is large. DE-CIX reports more than 18 Terabit per second of peak traffic in Frankfurt. It reports reach to more than 1,000 local, regional and global networks. AMS-IX Amsterdam currently reports 917 connected networks and a 15.095 Tb/s peak (DE-CIX, AMS-IX). Those two figures move constantly. Both are live operator dashboards, not fixed constants.

What CDNs do

Every major CDN peers at exchanges. But the published policies differ in ways that change how you connect to them:

• Cloudflare (AS13335): an open peering policy. It recommends sessions in all mutual locations and automates public peering through its peering portal. Notably, it recommends bilateral BGP sessions for optimal traffic delivery. This is because it advertises only a limited number of prefixes over route servers. Networks exchanging more than 10 Gbps in one location may request a PNI. Networks exchanging at least 10 Gbps may be eligible for an embedded cache (Cloudflare peering policy).
• Fastly (AS54113): a selective but generally open policy. Peers are selected on performance, capability and where traffic needs to be delivered. It asks peers to exchange traffic at all IXPs shared in common for traffic distribution and redundancy. Fastly has no backbone, so it does not announce a consistent set of prefixes across IXPs. So a peer will not see the same routing table from Fastly at every interconnection point (Fastly peering policy).
• Akamai (AS20940): will openly peer with any network at IXP locations where mutually present. It considers private interconnection case-by-case (Akamai network partnerships).

Watch out for

• Presence is not peering. Joining an exchange only makes other networks reachable. Peering is voluntary on both sides. Most large networks have a peering policy. They prioritise the networks they exchange the most data with (Cloudflare).
• Route servers do not reach everyone. About 80 percent of DE-CIX Frankfurt's connected networks are at its route servers. Cloudflare advertises only a limited set of prefixes over route servers. If you rely on route-server sessions alone, you will silently miss traffic that bilateral sessions would have carried.
• Path hiding. Per-client policy control on a route server can hide a path from a client that would otherwise have used it. RFC 7947 names this. It discusses mitigations such as multiple RIBs or advertising multiple paths, in an explicitly informational section rather than a normative requirement (RFC 7947 section 2.3).
• Remote peering can defeat the point. A network can join a distant exchange over an extended Layer 2 circuit. Its routes then look local while its packets are not. Cloudflare does not use remote peering. It tries not to peer with remotely connected networks when it has a PoP closer to them (Cloudflare engineering).
• Tromboning. Without local exchange, traffic from one city destined for another ISP in the same city can travel vast distances to be exchanged and then return again.
• One exchange is a single point of failure. Settlement-free is not free. The membership, port and cross-connect charges remain.

Best practice

• Choose exchanges from data, not reputation. PeeringDB is a user-maintained directory of IXPs, peering locations and contacts for networks willing to peer. Join where the ISPs serving your customers already are.
• Take the route-server sessions for breadth. Then add bilateral sessions to the networks that carry real volume. Move to a PNI once a peer's traffic justifies dedicated capacity.
• Peer at more than one exchange per metro. Connect to both of an exchange's route servers. That way planned maintenance on one does not remove the route service (DE-CIX route server guide).
• Register your prefixes as route and route6 objects in an IRR well before you announce them. Publish ROAs. Keep your PeeringDB record complete. This matters because route servers filter on RPKI and IRRDB data. Peers such as Fastly build their prefix lists from exactly that data (DE-CIX, Fastly).
• Never announce an exchange's peering LAN into the global routing table. Run BCP-38 filtering on the session.