Information Technology Reference
In-Depth Information
the impact on path selection is more significant with a multilevel RR structure. For exam-
ple, R1 in Figure 7-11 receives two paths for the prefix, but based on the BGP attributes and
parameters local to the RR, R1 reflects the best path to R5 and R6. The same process occurs
for R3. When R5 receives two paths, it evaluates the paths based on path attributes and
parameters that are locally available. In turn, it reflects its best path to R9 and R10. If path
attributes are not modified and comparable between RRs and clients, there should be no
problems. Otherwise, suboptimal routing and route oscillation can occur. Examples of
route oscillation because of improper RR designs are provided in the following sections.
So when should you consider using hierarchical route reflection? To answer this question,
you should evaluate the following two factors:
•
Size of the top-level mesh
•
Number of alternative paths
In most cases, the primary concern is the size of the top-level iBGP mesh. If you think that
the number of full-mesh sessions is administratively unmanageable, you should probably
consider introducing RR hierarchy. As discussed in Chapter 3, “Tuning BGP Performance,”
the number of BGP peers configured on a router also has performance implications. The
exact number of full-mesh sessions might depend on your requirements. The number of
alternative paths has a direct impact on load sharing (if iBGP load sharing is enabled) and
resource use. More hierarchies reduce the number of load-shared links but require fewer
router resources.
Route Reflection Design Examples
This section presents extensive examples to demonstrate the best practices of RR designs
and provides possible solutions for each problem.
When designing route reflection architectures, adhere to the following general guidelines:
•
Keep logical and physical topologies congruent to increase redundancy and path
optimization and to prevent routing loops.
•
Use comparable metrics in route selection to avoid convergence oscillations.
•
Set proper intra- and intercluster IGP metrics to prevent convergence oscillations.
•
Use proper clustering techniques to increase RR redundancy.
•
Modify the next hop with care, and do so only to bring RRs into the forwarding path.
•
Use peer groups with RRs to reduce convergence time.
Keeping Logical and Physical Topologies Congruent
It is true that iBGP has no requirements for physical topology in building peer relations and
forwarding packets as long as the IGP provides the reachability between peers and to the
