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
|
|
|---|---|---|---|
| Last updated | 2015-10-14 | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Stream | WG state | WG Document | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 4456 (Draft Standard) | |
| 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
Show full document text