How Route Servers Work at Internet Exchange Points

At an Internet Exchange Point (IXP), networks connect to a shared switching fabric and exchange traffic directly with each other. Without a route server, each network must establish individual bilateral BGP sessions with every other network it wants to peer with. A facility with 1,000 members would require each member to manage up to 999 separate BGP sessions — configuration that scales as O(n²). Route servers solve this by enabling multilateral peering: a single BGP session from each member to the route server reaches all other participating members simultaneously.

Bilateral vs Multilateral Peering

Most large IXPs run two or more route servers for redundancy. Members typically establish sessions with all route server instances. Large networks additionally maintain bilateral sessions with their most important peers — a top-volume content network or cloud provider they exchange significant traffic with may warrant a dedicated session with custom policy, while smaller peers are handled through the route server.

The Route Server's Unique Transparency Property

A conventional BGP router that receives a route and re-advertises it to another peer prepends its own ASN to the AS_PATH. This is the standard behavior that enables loop detection: if a prefix returns to an AS that is already in the path, it is discarded. A route server operating in transparent mode explicitly does not insert its own ASN. The route server's AS number never appears in the AS path seen by receiving members.

This matters because:

• Members see the authentic AS path from the originating network, not a path that appears to pass through the IXP's infrastructure.
• Loop detection works correctly — a member will still reject a route if its own ASN appears in the path.
• The route server's presence is invisible from a path-analysis perspective, which is the correct behavior for an exchange point whose job is to connect networks, not to appear as a transit hop.

This is specified in RFC 7947 (BGP Route Server). A route server MUST NOT modify the AS_PATH or NEXT_HOP of routes it receives before distributing them to other peers (subject to policy). The NEXT_HOP preservation means that the next hop in the route points directly to the originating network's router on the IXP fabric — packets forwarded by a member do not pass through the route server at the IP layer; the route server handles only the control plane (BGP).

Per-Peer RIBs and Route Distribution

A standard BGP router maintains a single Adj-RIB-In per neighbor, a local RIB, and a single Adj-RIB-Out. A route server maintains a separate Adj-RIB-In for each peer and a separate Adj-RIB-Out for each peer. This per-peer output RIB architecture (specified in RFC 7947) is essential because different peers may be subject to different export policies — member A may not want to share routes with member B, even though both have sessions with the route server.

The route server's processing loop is:

1. Receive UPDATE from Member A (stored in A's Adj-RIB-In).
2. Apply import policy for Member A (filter bogons, check IRR authorization, reject RPKI invalids).
3. For each other member X: apply export policy (check if A has opted out of exporting to X, apply community-based filtering).
4. Compute Adj-RIB-Out for X and send UPDATE to X with A's route, A's next-hop, and A's AS path (unchanged).

At a large IXP with 1,000 members each advertising a few hundred prefixes, the route server processes and stores hundreds of thousands of per-peer RIB entries. This is computationally intensive — purpose-built route server software (BIRD, OpenBGPD) is designed to handle this scale efficiently.

Filtering at Route Servers

Route servers are a critical enforcement point for routing hygiene. The two primary filtering mechanisms are:

IRR-based prefix filters — The Internet Routing Registry (IRR) contains route objects and AS-SET objects that members register to document their routing policy. A route server can query IRR to build a per-member prefix filter: "Member A (AS 64500) may only advertise the prefixes in its registered route objects." Any route A announces that isn't registered in IRR will be rejected. The route server operator typically builds these filters nightly from IRR data using tools like bgpq4.

RPKI validation — The route server checks each received route against the RPKI repository (via an RTR feed from a local validator). Routes with a status of RPKI Invalid — where the origin AS is explicitly not authorized by the prefix holder's ROA — are rejected. Routes that are RPKI Unknown (no ROA exists) are typically still accepted, though some IXPs apply more conservative policies. See RPKI for how Route Origin Validation works.

Many IXPs also filter:

• Prefixes longer than /24 (IPv4) or /48 (IPv6) — too specific, likely deaggregation abuse
• Bogon prefixes — unallocated or reserved address space (RFC 1918, documentation prefixes, etc.)
• Routes with private ASNs in the path (64512–65534, 4200000000–4294967294)
• Routes with the route server's own ASN in the path (loop detection)

Opt-In and Opt-Out Communities

Route servers at major IXPs expose BGP community values that members use to control route distribution without bilateral configuration changes. Common patterns:

Opt-out of a specific peer — A member tags a route with a community like IXPASN:0:PeerASN to tell the route server "do not export this route to the peer with ASN PeerASN." This is useful when two members have a separate bilateral agreement or when a member wants to avoid announcing certain routes to competitors.

Opt-in to a specific peer only — A member uses a community to restrict distribution to a subset of peers, keeping certain routes private to bilateral relationships while sharing others broadly.

Prepend on export — A member requests that the route server prepend its ASN a specified number of times when exporting to all or specific peers, providing inbound traffic engineering via the route server without per-peer session configuration.

Blackhole signaling — The standard BLACKHOLE community (65535:666, RFC 7999) causes the route server to distribute the route as a /32 with a blackhole next-hop, enabling distributed DDoS mitigation across all IXP peers simultaneously.

Scale at Major IXPs

Route servers at the world's largest IXPs process enormous routing tables:

At DE-CIX, the route server infrastructure receives the combined routing tables of over a thousand members — a superset of the global table since many members announce their full customer cone. The route server must compute per-peer Adj-RIB-Out for every combination of member pairs subject to policy, an O(n²) computational problem that necessitates purpose-built software and significant hardware investment.

Route Server Software

The two dominant open-source route server implementations are:

BIRD (BIRD Internet Routing Daemon) — Widely used at IXPs. Its configuration language supports rich policy expressions and per-peer RIBs. BIRD2 added significant performance improvements for large-table scenarios. Most mid-to-large European IXPs run BIRD.

OpenBGPD — Originally from OpenBSD. Known for security and correctness, used at several IXPs and extensively in research environments.

Both support RFC 7947 route server semantics including AS_PATH non-modification and NEXT_HOP preservation. Configuration generators like ARouteServer automate the creation of IRR-based filters from member AS-SET registrations.

Why Not Just Use Bilateral Sessions?

For an IXP with 50 members, bilateral sessions are manageable. At 500 members, the configuration overhead becomes a significant operational burden — each new member must exchange session information and filter configurations with potentially hundreds of existing members. The route server collapses this to a single session and a single point of policy enforcement. For smaller networks that cannot afford the operational overhead of hundreds of bilateral sessions, route servers make IXP participation practical at all.

Large content networks and transit providers often maintain both: route server sessions for breadth (reach everyone with one session) and selective bilateral sessions for the peers where custom policy, higher priority handling, or maximum prefix limits differ from the route server's defaults. This hybrid model is the norm at DE-CIX, AMS-IX, and similar facilities.

Route Server Redundancy and Failover

Most IXPs operate at least two independent route server instances, typically on separate physical hardware and management networks. Members establish BGP sessions with all route server instances simultaneously. If one route server fails (hardware fault, software crash, or scheduled maintenance), the remaining instance continues distributing routes with no impact on the data plane — traffic was never flowing through the route server anyway. The member whose session to RS1 drops will temporarily lose visibility to routes that RS2 may have filtered differently, but in practice both instances run identical policy, so the effect is minimal.

Some IXPs run route server instances in different physical locations connected by the IXP fabric (e.g., DE-CIX Frankfurt has multiple buildings). A physical fault at one site only affects members homed exclusively to that location — a strong argument for members to connect at multiple points on the fabric when available.

Route Servers vs BGP Route Reflectors

A BGP route reflector (RFC 4456) is a different concept that serves a similar scaling purpose but inside an AS, not between ASes. A route reflector is an iBGP peer that redistributes routes from one cluster member to others, avoiding the O(n²) full-mesh iBGP requirement. Unlike a route server, a route reflector does modify the UPDATE by adding a CLUSTER_LIST attribute. See how route reflectors work for details.

The similarity is structural: both route servers and route reflectors are BGP hubs that allow n peers to exchange routes with O(n) sessions rather than O(n²). The key differences are scope (inter-AS vs intra-AS), transparency (route servers preserve AS_PATH, reflectors add CLUSTER_LIST), and the policy complexity they must handle (route servers manage inter-organizational policy; reflectors handle intra-AS policy).

Security Considerations

A route server is a high-value target. If compromised, an attacker could inject routes to all connected members simultaneously, redirect traffic at IXP scale, or selectively drop routes to cause outages. IXP operators harden route server infrastructure accordingly: separate management networks, strict access controls, and monitoring for anomalous route updates. The filtering pipeline (IRR + RPKI) is the first line of defense — routes that don't pass validation never reach member tables regardless of what the route server announces.

Some IXPs publish their route server configurations and filter generation scripts publicly (often on GitHub), allowing members to audit exactly what policy is being applied to their routes. This transparency is considered a best practice in the IXP operator community. Related: Internet Exchange Points, peering, RPKI, Internet Routing Registries.

Route Server Visibility and Debugging

A member troubleshooting why their routes are not being distributed to a particular peer at an IXP should look at: first, whether the route passes the route server's import filter (IRR lookup, RPKI check, bogon filter); second, whether an opt-out community is set on the route suppressing export to that peer; third, whether the destination peer has its own import policy that rejects the route after receiving it from the route server. The route server itself is typically only the first point of failure — the two-step nature of route server policy (import from advertiser, export to each peer) means troubleshooting requires checking both directions.

Most IXP route servers provide a looking glass or route query interface that shows what routes the route server currently holds from each member and what it is distributing to each peer. This is separate from and complementary to a general internet looking glass like this one — the IXP's own looking glass shows the route server's per-peer Adj-RIB-Out, giving definitive answers about what each member is receiving. If a route appears in the IXP route server's output for a peer but the peer isn't using it, the issue is on the receiving peer's side. See BGP best-path selection to understand why a received route might not become the best path.

Traffic Engineering via Route Servers

A member wanting to shift inbound traffic at an IXP can use AS path prepending communities on the route server to make their routes appear less attractive to specific peers. This achieves inbound traffic engineering across all IXP participants without requiring bilateral session changes. Prepending at the route server level is less surgical than bilateral prepending — it affects all peers receiving the route server's distribution, not just specific ones — but it is much simpler operationally.

Similarly, a member can use the route server's NO_EXPORT or peer-specific opt-out communities to selectively hide prefixes from certain IXP participants, forcing traffic from those networks to reach them via transit instead of the IXP. This is occasionally used for commercial reasons (a network may not want to peer directly with a competitor at an IXP) or operational reasons (a specific peer's traffic is causing problems and the member wants to divert it temporarily).

The combination of per-peer policies, prepend communities, and opt-out mechanisms makes a well-configured route server a powerful traffic engineering platform — often more capable than simple bilateral sessions for the broad case, while bilateral sessions remain necessary for the most sensitive peering relationships where fine-grained policy control is required.

Explore It Live

• AS13335 (Cloudflare) — observe its extensive peering relationships, many established via IXP route servers
• AS6939 (Hurricane Electric) — present at hundreds of IXPs, heavily dependent on route server multilateral peering
• AS15169 (Google) — large-scale IXP peer; trace AS paths to Google to see short direct paths via IXP connections

The BGP looking glass shows live routes from RIPE RIS collectors, many of which peer via IXP route servers — short AS paths often indicate an IXP-mediated connection.