If there is only one route reflector in a cluster, then the CLUSTER–ID is the BGP identifier of the route reflector otherwise, a common CLUSTER–ID can be defined for use by multiple route reflectors within a cluster. Each cluster is identified by a CLUSTER–ID. While we show here just one route reflector in each cluster, for redundancy, a cluster may have multiple route reflectors. For example, in Figure 9.12(c), there are two clusters: one cluster is RR1 with R2 and R3, and another cluster is RR2 with R1 and R4.
#Reflector 2 code full
In Figure 9.12, we show iBGP session connectivity under full mesh, and when there are one, two, or three route reflectors. Note that a client is not aware that it is talking to a route reflector, and assumes that it is like a full-mesh configuration. iBGP speakers associated with a route reflector in a cluster are referred to as route reflector clients iBGP speakers that are not client peers are referred to as non-clients.
The introduction of route reflectors then creates a hierarchy among the iBGP speakers by clustering a subset of iBGP speakers with each route reflector. The idea is fairly simple: have one or more iBGP speakers act as concentration routers, commonly known as route reflectors. The concept of route reflector (, , ) has been developed to address the scalability problem of full mesh iBGP sessions.
0 kommentar(er)
