Content deleted Content added
BrainStack (talk | contribs) Link suggestions feature: 3 links added. |
OSPF route reflector DR/BDR cite add |
||
| (One intermediate revision by one other user not shown) | |||
Line 25:
The genesis of BGP was in 1989 when [[Kirk Lougheed]], [[Len Bosack]] and [[Yakov Rekhter]] were sharing a meal at an [[IETF]] conference. They famously sketched the outline of their new routing protocol on the back of some napkins, hence often referenced to as the “Two Napkin Protocol”.<ref>{{cite web | last=Jabloner | first=Paula | title=The Two-Napkin Protocol | website=Computer History Museum | date=2015-03-04 | url=https://computerhistory.org/blog/the-two-napkin-protocol/?key=the-two-napkin-protocol | ref={{sfnref|CHM|2015}} | access-date=2024-10-01}}</ref><ref>{{cite web | last=Jabloner | first=Paula | title=The Two-Napkin Protocol #WeAreCisco | website=Cisco | date=2020-07-02 | url=https://weare.cisco.com/c/r/weare/amazing-stories/amazing-things/two-napkin.html | access-date=2024-10-01}}</ref><ref>{{cite journal | title=BGP - A Tale of Two Napkins | journal=The Packet | publisher=Cisco Systems | volume=1 | issue=2 | year=1989 | url=https://weare.cisco.com/c/dam/r/weare/assets/files/packet-winter89.pdf | access-date=2024-10-01}}</ref>
It was
The current version of BGP is version 4 (BGP4), which was first published as {{IETF RFC|1654|link=no}} in 1994, subsequently updated by {{IETF RFC|1771 |link=no}} in 1995 and {{IETF RFC|4271|link=no}} in 2006.<ref>{{cite IETF |RFC=4271 |title=A Border Gateway Protocol 4 (BGP-4)}}</ref> RFC 4271 corrected errors, clarified ambiguities and updated the specification with common industry practices. The major enhancement of BGP4 was the support for [[Classless Inter-Domain Routing]] (CIDR) and use of [[route aggregation]] to decrease the size of [[routing table]]s. {{IETF RFC|4271|link=no}} allows BGP4 to carry a wide range of [[IPv4]] and IPv6 "address families". It is also called the Multiprotocol Extensions which is [[Multiprotocol BGP]] (MP-BGP).
Line 409:
'''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<ref>{{cite book |last=Chidester |first=Ashlan |title=Advanced OSPF & BGP |publisher=MC Inc |year=2024 |isbn=9798224952625 |url=https://www.worldcat.org/en/title/1476987548 |access-date=2025-08-29}}</ref>, 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.
| |||