Would eliminate the need for the IBGP session between RTR-A and RTR-B The IBGP routes learned from RTR-A to RTR-B and vice versa. Learned routes to IBGP peers, then it could re-advertise (or reflect) If this rule is relaxed and RTR-C is allowed to advertise IBGP Speakers) will not re-advertise these IBGP learned routes to other Route and it is selected as the best path it must advertise theĮxternal route to both RTR-B and RTR-C. With the existing BGP model, if RTR-A receives an external

In ASX, there are three IBGP speakers (routers RTR-A, RTR-B, and The simple example depicted in Figure 1 below. The basic idea of route reflection is very simple. Large and topology-rich network with many external connections. These criteria were motivated by operational experiences of a very It must be possible for noncompliant IBGP peers to continue toīe part of the original AS or domain without any loss of BGP This is an unfortunate management overhead of the technique It must be possible to transition from a full-meshĬonfiguration without the need to change either topology or AS.

Route reflection was designed to satisfy the following criteria.Īny alternative must be simple to configure and easy to RFC 4456 BGP Route Reflection April 2006 3. 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in thisĭocument are to be interpreted as described in RFC 2119. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', This document obsoletes RFC 2796 and RFC 1966. Non-transitive BGP attributes to prevent loops in routing updates. Understood concept of IBGP, and the addition of two new optional

Speaker (known as a 'route reflector') to advertise IBGP learned Mesh' and is known as 'route reflection'. Represents another alternative in alleviating the need for a 'full Proposals have been made to alleviate this. This scaling problem has been well documented, and a number of Routing information, as is common in many of today's networks. Large number of IBGP speakers each exchanging a large volume of This 'full mesh' requirement clearly does not scale when there are a Requires to maintain n*(n-1)/2 unique Internal BGP (IBGP) sessions. Typically, all BGP speakers within a single AS must be fully meshedĪnd any external routing information must be re-distributed to all Configuration and Deployment Considerations. This document obsoletes RFC 2796 and RFC 1966.ġ. 'route reflection' to alleviate the need for 'full mesh' Internal BGP This document describes the use and design of a method known as Scaling problem that has been well documented with several Routing information must be re-distributed to all other routers Speakers within a single AS must be fully meshed so that any external Routing protocol designed for TCP/IP internets. The Border Gateway Protocol (BGP) is an inter-autonomous system Distribution of this memo is unlimited.Ĭopyright (C) The Internet Society (2006). Official Protocol Standards' (STD 1) for the standardization stateĪnd status of this protocol. Please refer to the current edition of the 'Internet Internet community, and requests discussion and suggestions for This document specifies an Internet standards track protocol for the BatesīGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) Updated by: 7606 Errata Exist Network Working Group T. RFC 4456: BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)

Bgp full mesh