Of this node (e.g., a loopback address), and it may be configured on a Location is defined as a node in the IGP topology, it is identified by an IP address The core of this solution is the ability for an operator to specify the IGP locationįor which the route reflector calculates interior cost to the next hop. When, they appear in all capitals, as shown here. ¶Īre to be interpreted as described in BCP 14 This memo makes use of the terms defined in and. That would have been chosen by the client if the client had considered the same set ofĬandidate paths as the route reflector. That the best path chosen by the route reflector is not necessarily the same as the path The route reflector to select the best path from the client's perspective. This further complicates the issue and makes it less likely for In addition, there are deployment scenarios where service providers want to have moreĬontrol in choosing the exit points for clients based on other factors, such as traffic Not in the forwarding path, this difference will be even more acute. In networks where the route reflectors are The network topology than the route reflector. However, the clients are in a different place in Route is selected on the basis of an IGP tie-break, the path advertised will be the exit Its best path and only advertise that best path to its clients. Such deployments suffer from a critical drawback in the context of BGP route selection:Ī route reflector with knowledge of multiple paths for a given route will typically pick Route reflectors outside the forwarding path can be placed on the boundaries between the POP and the network core,īut they are often placed in arbitrary locations in the core of large In suchĮnvironments, a hot potato routing policy remains desirable. Services, e.g., IP VPNs however, it has been graduallyĮxtended to other BGP services, including the IPv4 and IPv6 Internet. Initially, this model was only employed for new The evolving model of intra-domain network design has enabled deployments of route InĪccordance with these design rules, route reflectors have often been deployed in theįorwarding path and carefully placed on the boundaries between the Point of Presence (POP) and the network core. Route reflection compatible with the application of a hot potato routing policy.
#Route reflector full#
Yielding the same results as the IBGP full mesh approach. Of constraints that, if satisfied, would result in the deployment of route reflection Section 11 of describes a deployment approach and a set The route reflector - not necessarily the one that is optimal for its clients. Point for a route reflector and its clients will be the exit point that is optimal for As a consequence of the route reflection method, the choice of exit Hot potato routing attempts to direct traffic to the closest AS exit point in cases where no higher-priority policyĭictates otherwise.
The ability to achieve "hot potato routing". Practical implication of this fact is that the deployment of route reflection may thwart Same route selection result as that of the full IBGP mesh approach." ("IBGP" stands for "Internal BGP".) One "the route reflection approach may not yield the asserts that, because the IGP cost to a given point in However, in some situations, this method suffers from non-optimal The most popular way to distribute BGP routes between BGP speakers belonging to the sameĪS. There are three types of BGP deployments within Autonomous Systems (ASes) today: full mesh,Ĭonfederations, and route reflection.
Restriction when the BGP Next Hop Is a BGP Route Route Selection from a Different IGP Locationģ.1.1. Reflectors based on the IGP cost from configured locations in the link-state IGP. BGP route selection is performed in the route The solution relies upon all route reflectors learning all paths thatĪre eligible for consideration. This facilitates, for example, a "best exit point" policy ("hot potato
Reflectors, where choosing the best route based on the route reflector's IGP location This solution is particularly applicable in deployments using centralized route On the scaling and precision requirements, route selection can be specific for oneĬlient, common for a set of clients, or common for all clients of a route reflector.
Of their clients, rather than from the standpoint of the route reflectors themselves. On route reflectors,īGP route selection is modified in order to choose the best route from the standpoint This document defines an extension to BGP route reflectors. Juniper Networks RFC 9107 BGP Optimal Route Reflection (BGP ORR) Abstract
0 kommentar(er)
