Editing Border Gateway Protocol (section)

== Internal scalability ==
BGP is "the most scalable of all routing protocols."<ref>{{cite web |url=https://www.cisco.com/c/en/us/products/ios-nx-os-software/border-gateway-protocol-bgp/index.html |title=Border Gateway Protocol (BGP) |website=[[Cisco]].com}}</ref>

An autonomous system with internal BGP (iBGP) must have all of its iBGP peers connect to each other in a [[Complete graph|full mesh]] (where everyone speaks to everyone directly). This full-mesh configuration requires that each router maintain a session with every other router. In large networks, this number of sessions may degrade the performance of routers, due to either a lack of memory, or high CPU process requirements.

===Route reflectors===
'''Route reflectors''' (RRs) reduce the number of connections required in an AS. A single router (or two for redundancy) can be made an RR: other routers in the AS need only be configured as peers to them. An RR offers an alternative to the logical full-mesh requirement of iBGP. The purpose of the RR is concentration. Multiple BGP routers can peer with a central point, the RR{{snd}} acting as an RR server{{snd}} rather than peer with every other router in a full mesh. All the other iBGP routers become RR clients.<ref>{{cite IETF |title=BGP Route Reflection: An Alternative to Full Mesh Internal BGP (iBGP) |RFC=4456 |author=T. Bates |display-authors=etal |date=April 2006}}</ref>

This approach, similar to [[OSPF]]'s DR/BDR feature, provides large networks with added iBGP scalability. In a fully meshed iBGP network of 10 routers, 90 individual CLI statements (spread throughout all routers in the topology) are needed just to define the remote-AS of each peer: this quickly becomes a headache to manage. An RR topology can cut these 90 statements down to 18, offering a viable solution for the larger networks administered by ISPs.

An RR is a [[single point of failure]], therefore at least a second RR may be configured in order to provide redundancy. As it is an additional peer for the other 10 routers, it approximately doubles the number of CLI statements, requiring an additional {{nowrap|1=11 × 2 − 2 = 20}} statements in this case. In a BGP multipath environment the additional RR also can benefit the network by adding local routing throughput if the RRs are acting as traditional routers instead of just a dedicated RR server role.

RRs and confederations both reduce the number of iBGP peers to each router and thus reduce processing overhead. RRs are a pure performance-enhancing technique, while confederations also can be used to implement more fine-grained policy.

====Rules====
[[File:RR BGP.svg|thumbnail|300px|A typical configuration of BGP RR deployment, as proposed by Section 6, RFC 4456.]]
RR servers propagate routes inside the AS based on the following rules:
* Routes are always reflected to eBGP peers.
* Routes are never reflected to the originator of the route.
* If a route is received from a non-client peer, reflect to client peers.
* If a route is received from a client peer, reflect to client and non-client peers.

====Cluster====
An RR and its clients form a ''cluster''. The ''cluster ID'' is then attached to every route advertised by the RR to its client or nonclient peers. A cluster ID is a cumulative, non-transitive BGP attribute, and every RR must prepend the local cluster ID to the cluster list to avoid routing loops.

===Confederation===
Confederations are sets of autonomous systems. In common practice,<ref>{{cite web|url=http://www.ietf.org/rfc/rfc5065.txt |title=Info |publisher=www.ietf.org |access-date=2019-12-17}}</ref> only one of the confederation AS numbers is seen by the Internet as a whole. Confederations are used in very large networks where a large AS can be configured to encompass smaller more manageable internal ASs.

The confederated AS is composed of multiple ASs. Each confederated AS alone has iBGP fully meshed and has connections to other ASs inside the confederation. Even though these ASs have eBGP peers to ASs within the confederation, the ASs exchange routing as if they used iBGP. In this way, the confederation preserves next hop, metric, and local preference information. To the outside world, the confederation appears to be a single AS. With this solution, iBGP transit AS problems can be resolved as iBGP requires a full mesh between all BGP routers: large number of TCP sessions and unnecessary duplication of routing traffic.{{clarify|reason=My guess is this is trying to say that using eBGP within a confederation avoids scaling issues that would exist if iBGP were used instead.|date=October 2022}}

Confederations can be used in conjunction with route reflectors. Both confederations and route reflectors can be subject to persistent oscillation unless specific design rules, affecting both BGP and the interior routing protocol, are followed.<ref>{{cite web|url=http://www.ietf.org/rfc/rfc3345.txt |title=Info |publisher=www.ietf.org |access-date=2019-12-17}}</ref>

These alternatives can introduce problems of their own, including the following:
* route oscillation
* sub-optimal routing
* increase of BGP convergence time<ref>{{cite web|url=http://www.ietf.org/rfc/rfc4098.txt |title=Info |publisher=www.ietf.org |access-date=2019-12-17}}</ref>

Additionally, route reflectors and BGP confederations were not designed to ease BGP router configuration. Nevertheless, these are common tools for experienced BGP network architects. These tools may be combined, for example, as a hierarchy of route reflectors.