Scalability Issues with Internal BGP


Before exploring the scalability issues of internal BGP, you should make certain that you have valid reasons for even implementing the BGP routing protocol in the first place. Your router's hardware capacity and the bandwidth between the ISP's AS and your AS is a key consideration for implementing BGP. Because of the system overhead involved in handling Internet routing updates, you should make sure that the prospective BGP router has sufficient CPU and memory resources. In addition, adequate bandwidth must be in place between your AS and the ISP's AS to handle the traffic loads created by BGP. Without ample bandwidth, the link between the ASs may get clogged up, and the subsequent routing updates may produce out-of-date routing tables. Also, you do not need to deploy BGP when your internetwork AS has only one route to the ISP's AS. Taking advantage of a simpler static route configuration between ASs is a more logical choice because the local AS has only one route to the ISP's AS. BGP is most suitable to put into service when an AS has several connections to other ASs. When operating in this capacity, BGP can effectively be used to influence inbound and outbound route update traffic between the local and remote ASs.

Before implementing BGP, revisit Chapter 8 to make sure that you adequately understand the BGP path selection process. Proper path election involves cautious management and well- chosen route filtering techniques because BGP routing updates from ISPs can quickly devastate your local AS boundary routers. Your local AS may not be adequately outfitted to handle the 80,000+ routes that exist on the current Internet.


Just to refresh your memory, BGP speakers that exchange routing information and belong to the same AS are known as IBGP peers. BGP speakers that belong to different ASs and exchange routing information are called Exterior BGP (EBGP) peers. EBGP peers, as opposed to IBGP peers, are most often directly connected to each another. Both IBGP peers and EBGP peers, however, use reliable TCP session connections to launch and maintain neighbor (peer) relationships. The BGP split horizon rule dictates that IBGP-learned routes never get sent to neighbors. The BGP split horizon rule assuages the number of routing loops that would occur if non-meshed IBGP peers sent routing information to all connected peers. A full-mesh topology between IBGP peers is necessary because the rule prevents IBGP routers from propagating their derived routing table to other IBGP peers within an AS. In Figure 9.1, the BGP split horizon rule prevents RouterB from forwarding information learned from RouterA to RouterC. Instead, RouterA should be directly connected to RouterC, creating a full mesh.

Figure 9.1. RouterB will not forward routes learned from RouterA to RouterC because of the BGP split horizon rule.

As explained in Chapter 8, IBGP peer relationships need a connection-oriented TCP session to operate . As an IBGP network increases in size, so will the number of TCP sessions required. Therefore, a full mesh IBGP topology will maximize, not minimize, the number of TCP sessions required in the AS. This is a scalability issue. The number of BGP sessions can be determined by the following formula:

 N * (n-1)  2 = connections needed 

If you only had 10 routers, then the number of connections would be 45 or 10(10 “1) ·2. To carry this example one step further, 1,000 routers would demand roughly 500,000 BGP sessions to fulfill the full mesh requirement. Because BGP uses TCP, another problem arises. A large amount of replication traffic and bandwidth consumption results in a large BGP autonomous system. Route reflectors can be used to decrease the number of TCP sessions and routing update traffic created in an IBGP full mesh AS.



Cisco BSCI Exam Cram 2 (Exam Cram 642-801)
CCNP BSCI Exam Cram 2 (Exam Cram 642-801)
ISBN: 0789730170
EAN: 2147483647
Year: 2003
Pages: 170

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net