What is a route reflector?
A route reflector is an iBGP router that spreads routes between clients and drops the full-mesh need. We cover clusters, loop prevention and route servers.
Last updated:
A route reflector (RR) is a BGP router that breaks the rule forbidding the readvertisement of iBGP-learned routes to other iBGP neighbours. This lets you scale internal BGP without building a full mesh of sessions. In classic iBGP every router must have a session with every other router (full mesh), because routes learned from one iBGP peer are not passed on. The route reflector, defined in RFC 4456, removes this limitation. A designated router (the reflector) receives routes from its clients and reflects them to the other clients and peers, so the number of required sessions drops.
The iBGP full-mesh problem
Inside a single autonomous system routers exchange routes over iBGP, and the loop-prevention rule forbids readvertising a route learned from another iBGP router. For every router to know all routes, the classic solution requires a full mesh of iBGP sessions. The session count grows quadratically: for n routers you need n*(n-1)/2 sessions. For 10 routers that is 45 sessions, for 50 routers already 1225. Such a setup is hard to maintain and strains device memory.
How route reflection and clusters work
A reflector divides its iBGP neighbours into clients and non-clients. Redistribution rules depend on where a route came from. A route from a client is reflected to all other neighbours, while a route from a non-client (an ordinary iBGP peer) is sent only to clients. The reflector together with its assigned clients forms a cluster. To prevent loops, RFC 4456 introduces two attributes, alongside common deployment patterns:
- ORIGINATOR_ID: carries the router ID of the route's origin. A router drops a route with its own ORIGINATOR_ID.
- CLUSTER_LIST: a list of cluster identifiers the route has traversed. A reflector drops a route containing its own cluster ID.
- Redundancy via multiple reflectors in one cluster or extra client-to-reflector sessions.
- Reflector hierarchy. A reflector can itself be a client of a higher-level reflector in large networks.
Route reflector versus route server
A route reflector and a route server are often confused because both mediate route exchange, but they operate in entirely different domains. A route reflector works in iBGP, inside a single autonomous system, and scales an operator's internal routing. A route server works in eBGP, at an internet exchange point (IXP), and mediates peering between different, independent autonomous systems while staying transparent in the AS_PATH (RFC 7947). A reflector preserves iBGP attributes and does not change the NEXT_HOP, but it is a purely internal tool. It has nothing to do with peering at an IXP.
Route reflectors and AS202520 SkyPass
AS202520 SkyPass uses route reflectors in its backbone between the PoPs in Warsaw and Wrocław to scale iBGP without a full mesh and keep a consistent view of routes across all edge routers. As a result, routes learned from our IP transit providers and peering partners at THINX, TPIX, WRIX and 1-IX propagate stably across the whole network. Customers buying IP transit or peering do not need to know about this layer. Route reflectors operate internally, and we handle their redundancy and correct cluster configuration.
Frequently asked questions
How does a route reflector differ from a route server?
A route reflector works in iBGP inside a single autonomous system and scales internal routing, while a route server works in eBGP at an IXP and mediates peering between different autonomous systems. They are two separate tools.
Why were route reflectors introduced?
To avoid a full mesh of iBGP sessions, whose count grows as n*(n-1)/2. A route reflector (RFC 4456) lets you redistribute iBGP routes without configuring an each-to-each session mesh.
Does a route reflector create a risk of routing loops?
RFC 4456 guards against loops with the ORIGINATOR_ID and CLUSTER_LIST attributes. A router drops a route carrying its own ORIGINATOR_ID or its own cluster ID, stopping the loop.
Do I need multiple route reflectors?
Yes, for redundancy. A single reflector is a single point of failure, so operators typically deploy at least two reflectors per cluster or add redundant client-to-reflector sessions.