BGP & Routing

Internet Exchange Points

Search and explore IXPs worldwide via PeeringDB. Find where networks peer, lookup IXPs by name or location, and check which exchanges an ASN participates in.

Search IXPs

ASN Lookup

About Internet Exchange Points

What is an Internet Exchange Point (IXP)?

An Internet Exchange Point (IXP) is a physical infrastructure through which Internet service providers (ISPs), content delivery networks (CDNs), and other network operators exchange internet traffic using Border Gateway Protocol (BGP). IXPs reduce costs by eliminating the need for traffic to traverse upstream transit providers, improve latency by keeping traffic local, and increase redundancy and resilience.

Peering vs. Transit

At an IXP, networks engage in peering — directly exchanging traffic with each other for free or low cost. This contrasts with transit, where a network pays an upstream provider to carry traffic to/from the rest of the internet. Peering at an IXP is generally preferred for high-volume bilateral traffic.

PeeringDB

PeeringDB is the authoritative registry for peering information. Networks voluntarily publish their peering policies, locations, and contact information. This tool queries PeeringDB to provide up-to-date IXP membership data for any given ASN.

Route Server: A shared BGP router at an IXP that simplifies peering by redistributing routes between members.
Open Peering: A network that will peer with any other network at the same IXP.
Selective Peering: A network that peers only with specific partners based on traffic volume or geographic criteria.
MLPA: Multilateral Peering Agreement — a framework for IXP members to peer via the route server.

Internet Exchange Points: How BGP Peering Works

Internet Exchange Points are the physical and logical hubs of the internet — locations where hundreds of networks connect to exchange traffic directly. Major IXPs such as DE-CIX (Frankfurt), AMS-IX (Amsterdam), LINX (London), and IX.br (São Paulo) handle hundreds of terabits of traffic per second. The PeeringDB database, which powers this tool, catalogs over 900 IXPs across more than 100 countries.

When an AS announces its prefixes at an IXP, it typically connects to a shared switch fabric. A route server collects BGP announcements from all members and redistributes them, eliminating the need for bilateral BGP sessions between every pair of participants. Members can filter routes, set communities, and apply routing policies to control what they accept and announce.

The economic benefits of IXP peering are substantial. By exchanging traffic directly at an IXP, networks avoid paying transit fees to upstream providers. For CDNs and large content providers, IXP peering is essential — it reduces round-trip latency, improves reliability, and allows better traffic engineering. Tools like this IXP browser help network engineers evaluate potential peering locations and understand the global IXP ecosystem.

Useful Commands

Query PeeringDB API

curl "https://www.peeringdb.com/api/net?asn=13335"
curl "https://www.peeringdb.com/api/ixlan"
curl "https://www.peeringdb.com/api/ixpfx"

Expert guide · IXP Browser

What it does

The Internet Exchange explorer reads PeeringDB, the operator-maintained database of networks, exchanges and facilities, through its public JSON API. It lists active exchange points with city, country and website, lets you filter exchanges by name, city or country code, and, given an ASN, shows every exchange connection that network has registered: the exchange name, its IPv4 and IPv6 addresses on the peering LAN and the port speed.

Why it matters

Peering planning: Seeing which exchanges a content or cloud network is present at tells you where a single port could replace paid transit for a large share of your traffic.
Session setup: The peer's IPv4 and IPv6 addresses on the exchange LAN are exactly what you type into the BGP neighbor statement, so pulling them from the registry avoids guesswork.
Latency for local users: Traffic between two networks in the same city that do not share an exchange often hairpins through another country, a long-standing problem in parts of Latin America that local IXPs were built to fix.
Capacity awareness: Port speeds show whether a peer connects at 1, 10 or 100 Gbps, which matters before you shift heavy flows to a bilateral session.
Resilience review: A network that appears at only one exchange is exposed if that fabric fails; multiple exchanges in different cities indicate real redundancy.

How to read the results

Exchange list: Up to fifty active exchanges in the order PeeringDB returns them, not a ranking by size or traffic.
Search: Filters by name, city or two-letter country code over a limited batch of PeeringDB records, so an exchange missing from the results may simply be outside that batch; search PeeringDB directly to be sure.
IPv4 and IPv6 columns in the exchange table: Values taken from the PeeringDB exchange record; a 0 means PeeringDB did not return a figure, not that the exchange has no members.
ASN lookup rows: One row per registered connection; two rows for the same exchange mean the network has two ports or two routers there, usually for redundancy.
Peering LAN addresses: The IPv4 and IPv6 addresses the network uses on that exchange fabric; a dash means it has not registered that address family there.
Speed: The port capacity registered by the network, shown in Mbps or Gbps; it is self-reported and may lag behind upgrades.

Technical background

An Internet exchange point is, at its core, a shared layer-2 switching fabric. Each participant connects a router port and receives an IPv4 and an IPv6 address from the exchange's peering LAN; from then on, any two members can bring up a BGP session across the fabric and swap traffic directly instead of paying a transit provider to carry it. Peering at an exchange is usually settlement-free: neither side pays the other, each covers its own port and cross-connect.

There are two ways to peer on the same fabric. Bilateral peering means a separate BGP session with each partner, negotiated individually. Multilateral peering goes through the exchange's route servers, described in RFC 7947 and RFC 7948: a member opens one session to each route server and receives the routes of every other member that does the same. Route servers are transparent, meaning they do not insert their own ASN into the AS_PATH and do not change the next hop, so traffic still flows directly between members. Modern route servers also filter announcements against RPKI and IRR data, but each member remains responsible for its own inbound filters.

PeeringDB is where operators publish all of this. It models organizations, networks (net), exchanges (ix), their peering LANs (ixlan and ixpfx), each network's connection to a LAN (netixlan) and colocation facilities (fac). Networks also declare their peering policy, which is usually Open, Selective or Restrictive, and the recommended maximum number of IPv4 and IPv6 prefixes peers should accept, which many automation tools use to set max-prefix limits. Because the data is entered by the networks themselves, it is authoritative when maintained and stale when not; many exchanges now publish IX-F member export JSON so PeeringDB can flag mismatches between what the exchange sees and what a member claims.

The practical gains are lower latency, lower cost and more control. Domestic traffic that previously crossed an ocean to meet in Miami or Frankfurt can stay in-country. Latin America illustrates this well: the IX.br system in Brazil, with São Paulo as one of the largest exchanges in the world by number of participants, the CABASE exchanges in Argentina and the PIT Chile platform keep regional traffic local and attract content caches close to users.

Operational details matter on a shared fabric. Exchanges allow a limited number of MAC addresses per port and quarantine ports that leak spanning-tree frames, proxy-ARP replies or IPv6 router advertisements. Peering LAN prefixes should never be announced into the global table, and the next hop of every route learned at the exchange must stay on that LAN.

Common errors and how to fix them

Problem The PeeringDB record still lists an old peering IP after a port migration, so peers configure sessions to an address that no longer answers.: Fix Update the netixlan entries the same day the port changes, or enable IX-F import so PeeringDB can sync from the exchange's member list.
Problem Peer sessions drop when a partner announces a few more prefixes than expected.: Fix Set max-prefix limits from the peer's published info_prefixes4 and info_prefixes6 values plus a margin, use warning-only or restart timers instead of permanent shutdown, and refresh the values periodically.
Problem An exchange port is shut down by the IXP shortly after connection.: Fix Disable spanning tree, CDP and LLDP toward the fabric, turn off proxy-ARP and IPv6 router advertisements on the interface, and present a single MAC address as the exchange requires.
Problem Accepting everything the route servers send without your own filters.: Fix Filter inbound routes at the exchange like any other eBGP session: reject martians, RPKI-invalid routes and prefixes longer than /24 or /48, and cap the number of prefixes per session.
Problem Announcing the exchange peering LAN prefix to transit providers.: Fix Keep the peering LAN in your IGP or as a connected route only and exclude it from export policies; leaking it lets outsiders reach the fabric and breaks the exchange's security model.

Do it from the command line

macOS

# Network record for an ASN: name, policy and max-prefix hints
curl -s "https://www.peeringdb.com/api/net?asn=15169" | python3 -m json.tool | grep -E '"name"|policy_general|info_prefixes'
# All exchange connections for that ASN
curl -s "https://www.peeringdb.com/api/netixlan?asn=15169" | python3 -m json.tool | grep -E 'ix_id|ipaddr4|speed'

Windows

# Exchanges in Brazil from PeeringDB
(Invoke-RestMethod "https://www.peeringdb.com/api/ix?country=BR").data | Select-Object id,name,city
# Ports of one network
(Invoke-RestMethod "https://www.peeringdb.com/api/netixlan?asn=13335").data | Select-Object ix_id,ipaddr4,ipaddr6,speed

Linux

# Exchanges in Argentina with jq
curl -s "https://www.peeringdb.com/api/ix?country=AR" | jq -r '.data[] | "\(.id) \(.name) \(.city)"'
# Peering LAN prefixes of an exchange (replace 171 with the ix id you need)
curl -s "https://www.peeringdb.com/api/ixpfx?ixlan_id=171" | jq -r '.data[].prefix'

Frequently asked questions

What is an Internet exchange point (IXP)?

An IXP is a shared switching platform, usually in a data center, where many networks connect a port and exchange traffic directly with each other using BGP. Instead of sending local traffic through paid transit providers, sometimes via another country, members hand it straight to the destination network. That reduces cost and latency and keeps domestic traffic inside the region.

What is the difference between a route server and bilateral peering?

With bilateral peering you configure a separate BGP session with each partner network and agree on it individually. With a route server, you open one session to the exchange's route server and automatically receive routes from every member that also uses it. Traffic still flows directly between members. Most networks combine both: route servers for breadth, bilateral sessions with their largest partners.

Is PeeringDB data reliable?

It is as reliable as the operators who maintain it. Large networks and exchanges keep their records accurate because peers depend on them for automation. Smaller entries can be outdated, especially IP addresses after migrations and port speeds after upgrades. Exchanges that publish IX-F member exports let PeeringDB detect mismatches. Always confirm addresses with the peer before bringing up a session.

How do I join an IXP?

You need a public ASN, your own or provider-independent address space, and a router in a facility where the exchange has a presence or a circuit to reach it. You sign the exchange's agreement, order a port and cross-connect, receive addresses on the peering LAN, then set up sessions with the route servers and any bilateral peers. Register the connection in PeeringDB so others can find you.

Does peering at an IXP replace transit?

Only partially. An exchange gives you direct paths to the networks that are members and peer with you, often the large content, cloud and local access networks that make up a big share of traffic. You still need transit to reach the rest of the Internet. Many regional ISPs in Latin America move a large portion of their traffic over local exchanges and buy much less transit as a result.