Route Reflection

Route Reflection
Route reflection was first defined in RFC 1966 and was later revised by RFC 2796. Route reflection
allows a BGP speaker—known as a route reflector—to advertise iBGP-learned routes to
certain other iBGP peers. This overcomes the limitation of a BGP speaker’s not being able to readvertise
iBGP learned routes to other iBGP peers, alleviating the need for a fully meshed iBGP
network. Before we dive too deeply into route reflection, there are some basic terms you need
to understand:

Route reflection
is the operation of a BGP speaker advertising an iBGP-learned route to
other iBGP peers.

Route reflector
is the BGP speaker that advertises the iBGP-learned route to other iBGP
peers.

Reflected route
is a route that has been through the route reflection operation.

Client peers
are BGP speakers, which will receive reflected routes from a route reflector and
participate in that route reflector’s cluster.

Non-client peer
is a BGP speaker that must be fully meshed and doesn’t participate in a
route reflector’s cluster.

Cluster
is a route reflector and all of its client peers.
There are three specific criteria set forth that route reflection needs to meet.
Simplicity
An alternative to fully meshed iBGP must be simple to understand and configure.
Easy transition
When transitioning from a fully meshed iBGP network, the alternative must
not cause a change to the topology or AS. This allows for easy migration from fully meshed
iBGP to route reflection.
Compatibility
A non-compliant BGP peer must continue to participate in the AS without any
loss of BGP routing information.
In order to fully understand route reflection, we must revisit what happens to an iBGP network
that is not fully meshed. Refer to Figure 9.1.
In this example, the following is what happens when a route is learned by R2 from R1:
1.
R1 sends the route to R2.
2.
R2 receives the route and stores it locally.
3.
R2 sends the route to R3.
4.
R3 receives the route and stores it locally.
5.
R4 never learns the new route.
This same scenario would hold true if a route was sent from R5 to R4. In this case, R2 would
never learn the route. That is why iBGP requires a full mesh—so that R4 would advertise R5’s routes
to both R3 and R2, in which case, all iBGP speakers synchronize on this same route information. We
will now look at how route reflection overcomes this limitation in the same type of scenario.