BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)
RFC 4456
Document | Type |
RFC - Draft Standard
(April 2006; Errata)
Updated by RFC 7606
|
|
---|---|---|---|
Authors | Enke Chen , Tony Bates , Ravi Chandra | ||
Last updated | 2018-12-20 | ||
Stream | Internent Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | WG Document | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4456 (Draft Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Bill Fenner | ||
Send notices to | yakov@juniper.net |
Network Working Group T. Bates Request for Comments: 4456 E. Chen Obsoletes: 2796, 1966 Cisco Systems Category: Standards Track R. Chandra Sonoa Systems April 2006 BGP Route Reflection: An Alternative to Full Mesh Internal BGP (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 (2006). Abstract The Border Gateway Protocol (BGP) is an inter-autonomous system routing protocol designed for TCP/IP internets. Typically, 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 Autonomous System (AS). This represents a serious scaling problem that has been well documented with several alternatives proposed. This document describes the use and design of a method known as "route reflection" to alleviate the need for "full mesh" Internal BGP (IBGP). This document obsoletes RFC 2796 and RFC 1966. Bates, et al. Standards Track [Page 1] RFC 4456 BGP Route Reflection April 2006 Table of Contents 1. Introduction ....................................................2 2. Specification of Requirements ...................................2 3. Design Criteria .................................................3 4. Route Reflection ................................................3 5. Terminology and Concepts ........................................4 6. Operation .......................................................5 7. Redundant RRs ...................................................6 8. Avoiding Routing Information Loops ..............................6 9. Impact on Route Selection .......................................7 10. Implementation Considerations ..................................7 11. Configuration and Deployment Considerations ....................7 12. Security Considerations ........................................8 13. Acknowledgements ...............................................9 14. References .....................................................9 14.1. Normative References ......................................9 14.2. Informative References ....................................9 Appendix A: Comparison with RFC 2796 ..............................10 Appendix B: Comparison with RFC 1966 ..............................10 1. Introduction Typically, 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 Internal BGP (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 today's networks. 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 a "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 non-transitive BGP attributes to prevent loops in routing updates. This document obsoletes RFC 2796 [6] and RFC 1966 [4]. 2. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [7]. Bates, et al. Standards Track [Page 2] RFC 4456 BGP Route Reflection April 2006 3. Design Criteria Route reflection was designed to satisfy the following criteria. o Simplicity Any alternative must be simple to configure and easy to understand. o Easy Transition It must be possible to transition from a full-mesh configuration without the need to change either topology or AS.Show full document text