summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2796.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2796.txt')
-rw-r--r--doc/rfc/rfc2796.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc2796.txt b/doc/rfc/rfc2796.txt
new file mode 100644
index 0000000..3e13f08
--- /dev/null
+++ b/doc/rfc/rfc2796.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group T. Bates
+Request for Comments: 2796 Cisco Systems
+Updates: 1966 R. Chandra
+Category: Standards Track E. Chen
+ Redback Networks
+ April 2000
+
+
+ BGP Route Reflection -
+ An Alternative to Full Mesh IBGP
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Abstract
+
+ The Border Gateway Protocol [1] is an inter-autonomous system routing
+ protocol designed for TCP/IP internets. Currently in the Internet BGP
+ deployments are configured such that that all BGP speakers within a
+ single AS must be fully meshed so that any external routing
+ information must be re-distributed to all other routers within that
+ AS. This represents a serious scaling problem that has been well
+ documented with several alternatives proposed [2,3].
+
+ This document describes the use and design of a method known as
+ "Route Reflection" to alleviate the the need for "full mesh" IBGP.
+
+1. Introduction
+
+ Currently in the Internet, BGP deployments are configured such that
+ that all BGP speakers within a single AS must be fully meshed and any
+ external routing information must be re-distributed to all other
+ routers within that AS. For n BGP speakers within an AS that
+ requires to maintain n*(n-1)/2 unique IBGP sessions. This "full
+ mesh" requirement clearly does not scale when there are a large
+ number of IBGP speakers each exchanging a large volume of routing
+ information, as is common in many of todays internet networks.
+
+
+
+
+
+Bates, et al. Standards Track [Page 1]
+
+RFC 2796 BGP Route Reflection April 2000
+
+
+ This scaling problem has been well documented and a number of
+ proposals have been made to alleviate this [2,3]. This document
+ represents another alternative in alleviating the need for a "full
+ mesh" and is known as "Route Reflection". This approach allows a BGP
+ speaker (known as "Route Reflector") to advertise IBGP learned routes
+ to certain IBGP peers. It represents a change in the commonly
+ understood concept of IBGP, and the addition of two new optional
+ transitive BGP attributes to prevent loops in routing updates.
+
+ This document is a revision of RFC1966 [4], and it includes editorial
+ changes, clarifications and corrections based on the deployment
+ experience with route reflection. These revisions are summarized in
+ the Appendix.
+
+2. Design Criteria
+
+ Route Reflection was designed to satisfy the following criteria.
+
+ o Simplicity
+
+ Any alternative must be both simple to configure as well as
+ understand.
+
+ o Easy Transition
+
+ It must be possible to transition from a full mesh
+ configuration without the need to change either topology or AS.
+ This is an unfortunate management overhead of the technique
+ proposed in [3].
+
+ o Compatibility
+
+ It must be possible for non compliant IBGP peers to continue be
+ part of the original AS or domain without any loss of BGP
+ routing information.
+
+ These criteria were motivated by operational experiences of a very
+ large and topology rich network with many external connections.
+
+3. Route Reflection
+
+ The basic idea of Route Reflection is very simple. Let us consider
+ the simple example depicted in Figure 1 below.
+
+
+
+
+
+
+
+
+Bates, et al. Standards Track [Page 2]
+
+RFC 2796 BGP Route Reflection April 2000
+
+
+ +-------+ +-------+
+ | | IBGP | |
+ | RTR-A |--------| RTR-B |
+ | | | |
+ +-------+ +-------+
+ \ /
+ IBGP \ ASX / IBGP
+ \ /
+ +-------+
+ | |
+ | RTR-C |
+ | |
+ +-------+
+
+ Figure 1: Full Mesh IBGP
+
+ In ASX there are three IBGP speakers (routers RTR-A, RTR-B and RTR-
+ C). With the existing BGP model, if RTR-A receives an external route
+ and it is selected as the best path it must advertise the external
+ route to both RTR-B and RTR-C. RTR-B and RTR-C (as IBGP speakers)
+ will not re-advertise these IBGP learned routes to other IBGP
+ speakers.
+
+ If this rule is relaxed and RTR-C is allowed to advertise IBGP
+ learned routes to IBGP peers, then it could re-advertise (or reflect)
+ the IBGP routes learned from RTR-A to RTR-B and vice versa. This
+ would eliminate the need for the IBGP session between RTR-A and RTR-B
+ as shown in Figure 2 below.
+
+ +-------+ +-------+
+ | | | |
+ | RTR-A | | RTR-B |
+ | | | |
+ +-------+ +-------+
+ \ /
+ IBGP \ ASX / IBGP
+ \ /
+ +-------+
+ | |
+ | RTR-C |
+ | |
+ +-------+
+
+ Figure 2: Route Reflection IBGP
+
+ The Route Reflection scheme is based upon this basic principle.
+
+
+
+
+
+Bates, et al. Standards Track [Page 3]
+
+RFC 2796 BGP Route Reflection April 2000
+
+
+4. Terminology and Concepts
+
+ We use the term "Route Reflection" to describe the operation of a BGP
+ speaker advertising an IBGP learned route to another IBGP peer. Such
+ a BGP speaker is said to be a "Route Reflector" (RR), and such a
+ route is said to be a reflected route.
+
+ The internal peers of a RR are divided into two groups:
+
+ 1) Client Peers
+
+ 2) Non-Client Peers
+
+ A RR reflects routes between these groups, and may reflect routes
+ among client peers. A RR along with its client peers form a Cluster.
+ The Non-Client peer must be fully meshed but the Client peers need
+ not be fully meshed. Figure 3 depicts a simple example outlining the
+ basic RR components using the terminology noted above.
+
+ / - - - - - - - - - - - - - -
+ | Cluster |
+ +-------+ +-------+
+ | | | | | |
+ | RTR-A | | RTR-B |
+ | |Client | |Client | |
+ +-------+ +-------+
+ | \ / |
+ IBGP \ / IBGP
+ | \ / |
+ +-------+
+ | | | |
+ | RTR-C |
+ | | RR | |
+ +-------+
+ | / \ |
+ - - - - - /- - -\- - - - - - /
+ IBGP / \ IBGP
+ +-------+ +-------+
+ | RTR-D | IBGP | RTR-E |
+ | Non- |---------| Non- |
+ |Client | |Client |
+ +-------+ +-------+
+
+ Figure 3: RR Components
+
+
+
+
+
+
+
+Bates, et al. Standards Track [Page 4]
+
+RFC 2796 BGP Route Reflection April 2000
+
+
+5. Operation
+
+ When a RR receives a route from an IBGP peer, it selects the best
+ path based on its path selection rule. After the best path is
+ selected, it must do the following depending on the type of the peer
+ it is receiving the best path from:
+
+ 1) A Route from a Non-Client IBGP peer
+
+ Reflect to all the Clients.
+
+ 2) A Route from a Client peer
+
+ Reflect to all the Non-Client peers and also to the Client
+ peers. (Hence the Client peers are not required to be fully
+ meshed.)
+
+ An Autonomous System could have many RRs. A RR treats other RRs just
+ like any other internal BGP speakers. A RR could be configured to
+ have other RRs in a Client group or Non-client group.
+
+ In a simple configuration the backbone could be divided into many
+ clusters. Each RR would be configured with other RRs as Non-Client
+ peers (thus all the RRs will be fully meshed.). The Clients will be
+ configured to maintain IBGP session only with the RR in their
+ cluster. Due to route reflection, all the IBGP speakers will receive
+ reflected routing information.
+
+ It is possible in a Autonomous System to have BGP speakers that do
+ not understand the concept of Route-Reflectors (let us call them
+ conventional BGP speakers). The Route-Reflector Scheme allows such
+ conventional BGP speakers to co-exist. Conventional BGP speakers
+ could be either members of a Non-Client group or a Client group. This
+ allows for an easy and gradual migration from the current IBGP model
+ to the Route Reflection model. One could start creating clusters by
+ configuring a single router as the designated RR and configuring
+ other RRs and their clients as normal IBGP peers. Additional clusters
+ can be created gradually.
+
+6. Redundant RRs
+
+ Usually a cluster of clients will have a single RR. In that case, the
+ cluster will be identified by the ROUTER_ID of the RR. However, this
+ represents a single point of failure so to make it possible to have
+ multiple RRs in the same cluster, all RRs in the same cluster can be
+ configured with a 4-byte CLUSTER_ID so that an RR can discard routes
+ from other RRs in the same cluster.
+
+
+
+
+Bates, et al. Standards Track [Page 5]
+
+RFC 2796 BGP Route Reflection April 2000
+
+
+7. Avoiding Routing Information Loops
+
+ When a route is reflected, it is possible through mis-configuration
+ to form route re-distribution loops. The Route Reflection method
+ defines the following attributes to detect and avoid routing
+ information loops:
+
+ ORIGINATOR_ID
+
+ ORIGINATOR_ID is a new optional, non-transitive BGP attribute of Type
+ code 9. This attribute is 4 bytes long and it will be created by a RR
+ in reflecting a route. This attribute will carry the ROUTER_ID of
+ the originator of the route in the local AS. A BGP speaker should not
+ create an ORIGINATOR_ID attribute if one already exists. A router
+ which recognizes the ORIGINATOR_ID attribute should ignore a route
+ received with its ROUTER_ID as the ORIGINATOR_ID.
+
+ CLUSTER_LIST
+
+ Cluster-list is a new optional, non-transitive BGP attribute of Type
+ code 10. It is a sequence of CLUSTER_ID values representing the
+ reflection path that the route has passed. It is encoded as follows:
+
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Attr. Flags |Attr. Type Code| Length | value ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Where Length is the number of octets.
+
+ When a RR reflects a route, it must prepend the local CLUSTER_ID to
+ the CLUSTER_LIST. If the CLUSTER_LIST is empty, it must create a new
+ one. Using this attribute an RR can identify if the routing
+ information is looped back to the same cluster due to mis-
+ configuration. If the local CLUSTER_ID is found in the cluster-list,
+ the advertisement received should be ignored.
+
+8. Implementation Considerations
+
+ Care should be taken to make sure that none of the BGP path
+ attributes defined above can be modified through configuration when
+ exchanging internal routing information between RRs and Clients and
+ Non-Clients. Their modification could potential result in routing
+ loops.
+
+ In addition, when a RR reflects a route, it should not modify the
+ following path attributes: NEXT_HOP, AS_PATH, LOCAL_PREF, and MED.
+ Their modification could potential result in routing loops.
+
+
+
+Bates, et al. Standards Track [Page 6]
+
+RFC 2796 BGP Route Reflection April 2000
+
+
+9. Configuration and Deployment Considerations
+
+ The BGP protocol provides no way for a Client to identify itself
+ dynamically as a Client of an RR. The simplest way to achieve this
+ is by manual configuration.
+
+ One of the key component of the route reflection approach in
+ addressing the scaling issue is that the RR summarizes routing
+ information and only reflects its best path.
+
+ Both MEDs and IGP metrics may impact the BGP route selection.
+ Because MEDs are not always comparable and the IGP metric may differ
+ for each router, with certain route reflection topologies the route
+ reflection approach may not yield the same route selection result as
+ that of the full IBGP mesh approach. A way to make route selection
+ the same as it would be with the full IBGP mesh approach is to make
+ sure that route reflectors are never forced to perform the BGP route
+ selection based on IGP metrics which are significantly different from
+ the IGP metrics of their clients, or based on incomparable MEDs. The
+ former can be achieved by configuring the intra-cluster IGP metrics
+ to be better than the inter-cluster IGP metrics, and maintaining full
+ mesh within the cluster. The latter can be achieved by:
+
+ o setting the local preference of a route at the border router to
+ reflect the MED values.
+
+ o or by making sure the AS-path lengths from different ASs are
+ different when the AS-path length is used as a route selection
+ criteria.
+
+ o or by configuring community based policies using which the
+ reflector can decide on the best route.
+
+ One could argue though that the latter requirement is overly
+ restrictive, and perhaps impractical in some cases. One could
+ further argue that as long as there are no routing loops, there are
+ no compelling reasons to force route selection with route reflectors
+ to be the same as it would be with the full IBGP mesh approach.
+
+ To prevent routing loops and maintain consistent routing view, it is
+ essential that the network topology be carefully considered in
+ designing a route reflection topology. In general, the route
+ reflection topology should congruent with the network topology when
+ there exist multiple paths for a prefix. One commonly used approach
+ is the POP-based reflection, in which each POP maintains its own
+ route reflectors serving clients in the POP, and all route reflectors
+ are fully meshed. In addition, clients of the reflectors in each POP
+
+
+
+
+Bates, et al. Standards Track [Page 7]
+
+RFC 2796 BGP Route Reflection April 2000
+
+
+ are often fully meshed for the purpose of optimal intra-POP routing,
+ and the intra-POP IGP metrics are configured to be better than the
+ inter-POP IGP metrics.
+
+10. Security Considerations
+
+ This extension to BGP does not change the underlying security issues
+ inherent in the existing IBGP [5].
+
+11. Acknowledgments
+
+ The authors would like to thank Dennis Ferguson, John Scudder, Paul
+ Traina and Tony Li for the many discussions resulting in this work.
+ This idea was developed from an earlier discussion between Tony Li
+ and Dimitri Haskin.
+
+ In addition, the authors would like to acknowledge valuable review
+ and suggestions from Yakov Rekhter on this document, and helpful
+ comments from Tony Li, Rohit Dube, and John Scudder on Section 9, and
+ from Bruce Cole.
+
+13. References
+
+ [1] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)",
+ RFC 1771, March 1995.
+
+ [2] Haskin, D., "A BGP/IDRP Route Server alternative to a full mesh
+ routing", RFC 1863, October 1995.
+
+ [3] Traina, P., "Limited Autonomous System Confederations for BGP",
+ RFC 1965, June 1996.
+
+ [4] Bates, T. and R. Chandra, "BGP Route Reflection An alternative
+ to full mesh IBGP", RFC 1966, June 1996.
+
+ [5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
+ Signature Option", RFC 2385, August 1998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bates, et al. Standards Track [Page 8]
+
+RFC 2796 BGP Route Reflection April 2000
+
+
+14. Authors' Addresses
+
+ Tony Bates
+ Cisco Systems, Inc.
+ 170 West Tasman Drive
+ San Jose, CA 95134
+
+ EMail: tbates@cisco.com
+
+
+ Ravi Chandra
+ Redback Networks Inc.
+ 350 Holger Way.
+ San Jose, CA 95134
+
+ EMail: rchandra@redback.com
+
+
+ Enke Chen
+ Redback Networks Inc.
+ 350 Holger Way.
+ San Jose, CA 95134
+
+ EMail: enke@redback.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bates, et al. Standards Track [Page 9]
+
+RFC 2796 BGP Route Reflection April 2000
+
+
+Appendix Comparison with RFC 1966
+
+ Several terminologies related to route reflection are clarified, and
+ the reference to EBGP routes/peers are removed.
+
+ The handling of a routing information loop (due to route reflection)
+ by a receiver is clarified and made more consistent.
+
+ The addition of a CLUSTER_ID to the CLUSTER_LIST has been changed
+ from "append" to "prepend" to reflect the deployed code.
+
+ The section on "Configuration and Deployment Considerations" has been
+ expanded to address several operational issues.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bates, et al. Standards Track [Page 10]
+
+RFC 2796 BGP Route Reflection April 2000
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bates, et al. Standards Track [Page 11]
+