Information Technology Reference
In-Depth Information
they are allowed to readvertise or reflect routes from one iBGP speaker to another iBGP
speaker. Under this new structure, iBGP speakers are classified into three groups:
•
Route reflectors (RRs)
•
Route reflector clients (also known as clients or client peers)
•
Regular iBGP speakers (also known as nonclients or nonclient peers)
The concept of clients and nonclients is always in the context of the RRs that serve or do
not serve them. A client of one RR can be an RR of another client. A nonclient with respect
to one RR can be an RR of another client.
NOTE
Route reflectors, although acting like regular iBGP speakers with other regular iBGP
speakers and with each other, can reflect routes between clients and nonclients. This
includes reflecting routes from one client to another client—in other words, client-to-client
reflection. With route reflection, the full iBGP mesh is required only between RRs and
between RRs and nonclients.
Consider the topology shown in Figure 7-2, which shows three interconnected autonomous
systems. Within AS 200, R5 is an RR, with R6 and R7 as its clients. Routers R3 and R4 are
nonclients and are fully meshed with R5. Clients R6 and R7 have iBGP sessions only with
R5. The total number of iBGP sessions within AS 200 is 5. Without route reflection, the
total number of iBGP sessions within AS 200 would be 10.
Route reflection provides another scalability feature—an RR reflects only the best path
of each prefix. When an RR receives multiple paths for the same destination, it first steps
through the path-selection process to determine the best path for that destination. It then
reflects the best path. Abstraction of routing information by RRs reduces the size of the
BGP RIB in the domain. Note that this abstraction is different from BGP prefix summari-
zation, although both reduce the size of the routing entries. One side effect of the RR's
abstraction of routing information, however, is that inconsistent route selection between
RRs and their peers might result in a loss of routing information or routing loops. This
chapter details how to avoid this type of problem when implementing RR designs.
To maintain consistent BGP topology, RRs do not modify certain BGP path attributes
during route reflection. These attributes include NEXT_HOP, AS_PATH, LOCAL_PREF,
and MED. Two additional attributes are introduced to help prevent routing information
loops in an RR environment, ORIGINATOR_ID and CLUSTER_LIST. Both are discussed
later. A routing information loop, also discussed later, is a phenomenon that a router
receives and accepts the routing information originated by itself.
