When the Border Gateway Protocol 4 (BGP-4) was defined in RFC 1771, the rules of deployment specified that all routers running the protocol (BGP speakers) within a single Autonomous System (AS) had to be fully meshed. This requirement for complete internal BGP (IBGP) exchange was necessary to re-distribute external routing information to all other routers within the AS. With n*(n-1)/2 unique IBGP sessions for n BGP speakers, scaling issues quickly became evident.

Several alternates have been proposed to address the scaling problem. These solutions include BGP Route Servers (RFC 1863), BGP Confederations (RFC 3065), and BGP Route Reflection (RFC 2796).

In a fully meshed BGP configuration, any routes learned from an IBGP peer is not re-announced to other internal peers. In BGP Route Reflection, this rule has been relaxed. A BGP speaker that is configured as a "Route Reflector" (RR) can re-announce routes (under certain conditions) that are learned via IBGP to its internal peers.

Internal peers of a RR are divided into two categories:

• Client peers. Client peers along with the RR form a "Cluster". Client peers within a Cluster need not be fully meshed.
• Non-Client peers. Non-Client peers inclusive of the RR have to be fully meshed.

When a RR has selected a best path among the routes learned from it IBGP peers, it performs the following operation:

• If the route was learned from a Non-Client IBGP peer, it is re-announced (or reflected) out to all Client peers.
• If the route was received from a Client peer, it is reflected to all Client AND Non-Client peers.

NB: Please refer to (RFC 2796) for a formal discussion.

i. With the current definition of BGP tie breaking rules, the selection for best path among competing route announcements may have dissimilar outcomes when compared on different criterion (such as MULTI_EXIT_DISC value, external vs internal peering, interior cost, or BGP Identifier).

ii. In a BGP Route Reflection setup, complete visibility of every exit point is not available to all internal routers. This in turn can result in path selections that are based on incomplete route announcement information.

BGP Route Oscillations

• Type I Churn:
  • Textual discussion: rfc3345.txt
  • Graphical presentation: BGP_Route_Oscillation_Type1a_v1.0.pdf
  
  
• Variant of Type I Churn:
  • Textual discussion: draft-ESnet-bgp-route-oscillation-02.txt
  • Graphical presentation: BGP_Route_Oscillation_Type1b_v1.1.pdf

Stable Routing Loops

• Graphical presentation: BGP_Routing_Loop_v1.2.pdf