Non–fully meshed iBGP

FIGURE 9 . 1
Non�"fully meshed iBGP
The following list describes the three distinct cases that a route reflector may be called upon
to handle. Each case describes what the route reflector will do in response:

Reflector receives a route from a non-client iBGP peer.
The route reflector would reflect to all clients. This behavior intentionally violates the normal
iBGP behavior, which would be to not advertise the route to any iBGP peers.

Reflector receives a route from a client peer.
The route reflector would reflect to all non-client peers and also to the client peers other
than the originator. Hence, the client peers are not required to be fully meshed. iBGP traffic
from a client to the reflector is treated the same as eBGP traffic would be.

Route from an eBGP peer.
The route reflector would send the update to all client and non-client peers. This behavior
is no different from behavior in a non-reflection environment.
Figure 9.2 depicts the use of route reflectors. When a route is sent from R1 to R2, the
sequence of events that will occur is as follows:
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.
R3 reflects the route to R4.
6.
R4 receives the route and stores it locally.
Depending on the policies in place for the AS, R4 could have sent the route to R5.


328