Route reflectors are a key component of service provider network design. You may be wondering why they are needed. I’ll be explaining the purpose of route reflectors in this article. If you want to learn how to configure a route reflector in IOS XR, check out my lab walkthrough How to Configure a BGP Route Reflector in Cisco IOS XR.
External vs Internal BGP
Understanding BGP loop prevention is the first step to understanding why we need route reflectors. Loop prevention is different for eBGP and iBGP. We will look at these differences in the following sections.
First let’s recap the difference between eBGP and iBGP. eBGP is BGP running between Autonomous Systems (AS) and iBGP is BGP running within an AS. An Autonomous System is a group of network devices that are under the same administrative domain (usually a company). Within an autonomous system a company has full control over policy like loop prevention and path selection. Between autonomous systems however, we can only rely on and trust BGP’s specifications.
How eBGP Prevents Loops (AS_PATH)
eBGP prevents loops using the AS_PATH attribute. The AS_PATH is a BGP attribute that records the autonomous systems a route has traversed.
For example, let’s say route 63.50.20.0 /24 is originating and being advertised from AS 100. AS 100 peers with AS 200. At AS 200 the AS_PATH will only show AS100, since AS200 learned it directly from AS100. However when the route gets advertised by AS200 to AS300, AS300 will have an AS_PATH of AS100, AS200.
The AS_PATH will keep growing the more hops away from the routes origin, denoting a complete path to that route on each router it reaches. You can see one clear benefit here already, which is that a router can use the AS_PATH length as a factor when determining the best route.
The other key benefit, and the point of this section, is routing information loop prevention. If a router receives a route advertisement that already contains its own AS number in the AS_PATH, it will reject that route. This prevents BGP route advertisements from circulating indefinitely between autonomous systems. Without this mechanism, routers could repeatedly advertise the same routes to one another, creating routing information loops. These loops could result in incorrect routes being installed in routing tables, potentially causing traffic blackholes, suboptimal routing, or forwarding loops.
By its nature the AS_PATH loop prevention mechanism only works with routes being advertised between Autonomous Systems (eBGP). We still need a way to prevent routing information loops within the Autonomous System (iBGP).
How iBGP Prevents Loops (Split-Horizon)
In iBGP the AS number is the same on all BGP peers, so AS_PATH isn’t an option for loop prevention. Instead, iBGP uses something called the Split-Horizon rule to prevent routing information loops. The Split-Horizon rule simply states that a router will not forward routes learned from one iBGP neighbor to another iBGP neighbor.
For example, imagine that we have three routers connected in series, like R1-R2-R3, where R1 and R3 both peer with R2 but not with each other. If R2 learns a route from R1 via iBGP, it will not advertise that route to R3. Likewise, if R2 learns a route from R3 via iBGP, it will not advertise that route to R1.
Because of the Split-Horizon rule, the only way to get all of our iBGP routers to share their routes with each other is by peering them in a full-mesh topology. This means that each iBGP router must peer with each other iBGP router.
For small numbers of iBGP peers this isn’t an issue. However when it comes to large networks, especially service providers, this adds an enormous amount of complexity and overhead to the control plane. The solution to this issue is route reflectors.
How Route Reflectors Help
A route reflector is a special router that has the sole purpose of performing BGP peering. When I say special I mean the configuration is special not the hardware. Any BGP capable router can be configured as a route reflector. Usually they exist in the control plane only and do not forward traffic. Because of this, route reflectors are excellent use cases for virtualized routers such as the IOS XRv 9000 and Juniper vMx.
A route reflector’s job is to peer with a group of BGP neighbors and aggregate / distribute their routes to each other. This replaces the mesh topology mentioned above with a hub and spoke topology. Each route reflector client shares the routes it knows with the route reflector. In turn, the route reflector advertises (reflects) all of the routes that it has learned back to each client. In this way each client can know each other’s routes without having to peer with them. This exponentially reduces complexity in networks where we have hundreds or thousands of BGP routers and it preserves BGPs loop prevention mechanisms.
Conclusion
Route reflectors are an important part of service provider networks today. They generally show up wherever iBGP is used, such as Layer 3 VPNs, EVPNs, or even internet routing within an autonomous system. Route reflectors allow certain routers to break the iBGP split-horizon rule in a controlled manner which simplifies configuration, administration, and overhead. I hope this article has been helpful. Thank you for reading.