Mar 12 2026
How far can you go with IX Route Servers only?
On paper internet exchanges (IX) are very simple in their implementation, simply put together a bunch of routers on a shared layer 2 ethernet switch (and coordinate IP addressing for the LAN) and those routers will be able to set up BGP sessions with each other and exchange traffic directly over the switch(s).
Internet exchange points also are a good place to add extra services (aka, servers on the LAN for the benefit of the member routers) to this LAN, common services include AS112, Network Time Protocol, Route Collectors, and perhaps most importantly, the Route Servers.
IX Route servers
Route servers (RS) are special forms of BGP route reflectors that are designed to simplify interconnection on internet exchanges, they work by having members peer with the route reflector (which is just a BGP speaker), and the RS distributes the routes provided to it to the other members. This means that a single BGP session can provide routes for all of the other exchange members who have also set up BGP sessions with the route server. This means that a new network does not have to try and contact every member on the exchange to set up sessions in their router config.
Route servers themselves do not actually exchange any of the traffic because all of the members are on the same layer 2 subnet, when routes are provided with a next hop IP address, the same next hop is just passed along (since all peers are on the same LAN). This means that a route server can coordinate often terabits of traffic with the slowest port speed that IX can provide.
Another modern day advantage for using internet exchange route servers is that they are often a lot more secure than most IX member configurations, this is because there has been a lot of pressure over time to improve the route security configuration of route servers to the point where you will often find that the route servers are implementing far better bgp route security practices (IRR list generation, RPKI ROV, Peerlock, next hop checking, AS_PATH validation, etc) than is actually being applied on direct sessions, where it is distressingly common that direct (commonly known as bilateral/bi-lat) sessions are just accepting everything offered to them because there is an implicit trust because somebody actually went and configured the session, often by hand.
Route servers on internet exchanges were a target for improvement due to the fact that they were often implicated in large routing incidents, and that from a IX members perspective it is very difficult to filter these BGP sessions correctly as they are an amalgamation of all of the members in one session, to give a more direct example if you want to go and generate IRR filters for DE-CIX Frankfurt route servers, the resulting configuration will be bigger than the current size of the internet routing table itself (AS-DECIX generates to 2.2 million IPv4 prefixes (double the size of the current routing table), and 885,000 IPv6 prefixes which is quadruple the size of the current routing table)
Not everything is perfect in the land of IX route servers. Because peering with them is almost never mandatory, not every network is using them, and even if they are they may not have the same import/export policies that you would get on a direct/bilateral session.
... continue reading