The Basics of BGP Route Reflection
A BGP speaker will not advertise a route learned via another IBGP speaker to a third
IBGP speaker. By relaxing this restriction a bit and by providing additional control,
we can allow a router to advertise (reflect) IBGP learned routes to other IBGP
speakers. This will reduce the number of IBGP peers within an AS.
The rule states: that any route received from an iBGP neighbor must not be advertised
to any other iBGP neighbor.
Configuring Border Gateway Protocol (BGP) can be quite onerous, particularly with
large numbers of peering sessions that must be configured manually. In fact, in a
large network, the full-mesh requirement for IBGP can be a provisioning nightmare.
BGP’s answer to the IBGP pairing configuration nightmare that is the full mesh is
called route reflection. Route reflection allows sharing of routing information among
a group of routers without having to send the exact same information to each of them
individually. It’s sort of like giving information to one person and having them
distribute it to all their peers.
IBGP comes with a significant restriction: IBGP peers should not re-advertise IBGP–
learned routes to other IBGP speakers, which is why they all need to be fully meshed.
If you can’t re-advertise IBGP routes, you must be directly connected to the originator
of the route, hence the full mesh requirement. Remember, IBGP has no dedicated loop
prevention mechanism, and this is why you need route reflectors for large networks.
The concept of route reflection allows you to designate one or more of your routers as
route reflectors. BGP relaxes the re-advertising restriction on these route reflectors,
allowing them to accept and propagate IBGP routes to their clients.
As the IBGP learned routes are reflected, it is possible to have the routing information
loop. The Route Reflector scheme has a few methods to avoid this:
Originator−id: this is an optional, non transitive BGP attribute that is four bytes long
and is created by a RR. This attribute will carry the router−id (RID) of the originator of
the route in the local AS. Thus, due to poor configuration, if the routing information
comes back to the originator, it will be ignored.
neighbor 6.6.6.6 route−reflector−client
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.