Route Reflection and Redundancy
Reliability and redundancy are important issues when using route reflection because the
members of a cluster are not fully meshed. For example, if router Harvard in Figure 43
on page 145 goes down, all of its clients are isolated from networks outside the cluster.
Having one or more redundant route reflectors in a cluster protects against such an
occurrence.
However, you cannot rely on logical redundancy alone. Consider the cluster shown in
Figure 44 on page 146. The operator has attempted to provide redundancy in Cluster 9
by configuring two route reflectors, router Acton and router Westford. Unfortunately,
router Harvard is physically isolated if its link to router Acton goes down, or if router Acton
itself goes down. Similarly, router Plymouth is isolated if any problems develop with
router Westford.
Figure 44: Route Reflection: Logical Redundancy
In Figure 45 on page 146, the operator has added physical redundancy to the cluster
configuration. Now, loss of either one of the route reflectors does not isolate the reflector
clients.
Figure 45: Route Reflection: Physical and Logical Redundancy
Route Reflection and Looping
BGP prevents looping between ASs by evaluating the AS-path attribute to determine a
route’s origin. Border routers reject routes they receive from external neighbors if the AS
path indicates that the route originated within the border router’s AS.
Route reflection creates the possibility of looping within an AS. Routes that originate
within a cluster might be forwarded back to the cluster. Because this happens within a
given AS, the AS-path attribute is of no use in detecting a loop.
Copyright © 2010, Juniper Networks, Inc.146
JunosE 11.2.x BGP and MPLS Configuration Guide
To Next Page
Loading...
Need help?
General
