BGP Route Reflector Basics
Everyone who ever studied BGP knows that BGP has strong rules to prevent routing and updates loops. In this post I will focus on iBGP loop prevention and specifically route reflectors as a result.
The rule states: that any route received from an iBGP neighbor must not be advertised to any other iBGP neighbor.
This loop prevention mechanism induces a requirement that all iBGP routers in the network should be connected in logical full mesh topology to allow for routing information propagation through out the network. However, full mesh connectivity has never been a scalable solution specially in large networks.
Two mechanisms were introduced to solve the scalability problem, by eliminating the need for the full mesh and in the same time keep the network loop free. The first solution is BGP confederations and the second one is BGP route reflectors, Which is going to be out topic for this post.
BGP route reflectors:
A route reflector is BGP router that is allowed to break the iBGP loop avoidance rule. Route reflectors can advertise updates received from an iBGP peer to another iBGP peer under specific conditions.
By breaking the rules, route reflectors are used to eliminate the full mesh requirement and allow for building iBGP networks that scale easily and cleanly.
How is this accomplished?
BGP Route Reflector follows the below listed rules to achieve this goal:
- iBGP routers are divided into Route Reflectors, Route Reflector clients and non-client Peers.
- Routes received from a Route-Reflector-client is reflected to other clients and non-client neighbors.
- Routes received from non-client neighbors are reflected to Route-Reflector-client neighbors only.
- Setting the Originator-ID attribute in the reflected update if it is not already set.
- Adding the Cluster-ID to the Cluster-list attribute in the reflected update.
- A Route Reflector reflects routes considered as best routes only. If more than one update is received for the same destination, only the BGP best route is reflected.
- A Route Reflector is not allowed to change any attributes of the reflected routes including the next-hop attribute.
Route Reflectors and Loop Prevention:
The following rules are used to detect and avoid routing loops caused by route reflection:
- If a router received an iBGP route with the Originator-ID attribute set to its own router-id, the route is discarded.
- If a route reflector receives a route with a cluster-list attribute containing its cluster-id, the route is discarded.
For more information about route reflectors check RFC 2796.
I hope it was simple enough, now lets get to see the configuration and verification section. Watch the video below:
I hope I have been informative in this post, please let me know if any questions, ideas or corrections.
No related posts.
You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
November 24th, 2009 at 7:11 am
It’s a good explanation.
April 9th, 2010 at 10:29 pm
Very concise and clear.
August 30th, 2010 at 3:37 pm
[...] control plane routers like (Route Reflectors) from being used accidentally in the forwarding [...]
September 2nd, 2010 at 9:19 pm
Good explanation thanks a lot
April 7th, 2011 at 11:35 am
Thank you. Its loud and clear
April 10th, 2011 at 10:12 pm
Let’s say a 3-router AS contains a single RR. The other 2 routers are clients of the RR. What happens if the RR fails? Will the 2 clients of the RR eventually realize the failure, and revert to full-mesh IBGP with each other?
May 15th, 2011 at 4:55 pm
Nice explaination
May 27th, 2011 at 1:12 pm
Very good explanation…!!!
June 1st, 2011 at 7:46 am
This is very informative. Thank you
June 7th, 2011 at 5:00 pm
Kevin: the only neighbor that RR Client is configured to see is the RR as a regular iBGP neighbor (route reflector clients don’t know they are the clients; all the RR specific configuration is on the RR).
Therefore, in your example the RR is a single point of failure. You may want to configure cluster with two RRs to avoid this.
July 19th, 2011 at 11:03 am
Let’s say your route-reflector client has an EBGP peer.
Does the route-reflector client advertise prefixes received from Route-Reflector automatically to it’s EBGP peer without any network statement?
July 27th, 2011 at 5:41 am
Good Explanation. Just curious, if there is any involvement of AS-PATH during RR operation.
August 19th, 2011 at 8:50 am
Dear all,
It’s a good and simple way of explaning RR and operation of RR.
I have a question..
If a RR received a ASN X route from two different clients than is RR reflect route received from one client to other.
I considered, 1st client route is best.
September 11th, 2011 at 5:56 pm
Brute-Force – Yes, the route reflector client will advertise a route received from the RR to its EBGP peer. No network statement required.
Sagar – No AS-Path change during IBGP or IBGP RR operation. It will only be prepending when leaving the AS when advertised to an EBGP peer.