Cisco Knowledge Suite Cisco SystemsCisco Press
   

   
Home
MyCKS
Cutting Edge
Certification
Core Reference
Guided Learning
   
Networking Architecture
LAN
WAN
Switching
Internet Protocols (IP)
Network Protocols
Transport and Application Protocols
Desktop Protocols
Security and Troubleshooting
Network Resources and Management
Integrated Services
 

BGP Cores and Network Scalability

   

Contents Next >

BGP Cores and Network Scalability

  

 

BGP in the Core

  

 

Scaling beyond the Core

  

 

Dividing the Network into Pieces

  

 

BGP Network Growing Pains

  

 

Case Study: Route Reflectors as Route Servers

  

 

Case Study: Troubleshooting BGP Neighbor Relationships

  

 

Case Study: Conditional Advertisement

  

 

Case Study: Dual-Homed Connections to the Internet

  

 

Case Study: Route Dampening

  

 

Review

Save to MyCKS

 
Advanced IP Network Design (CCIE Professional Development series)

From: Advanced IP Network Design (CCIE Professional Development series)
Author: Russ White; Alvaro Retana; Don Slice
Publisher: Cisco Press (53)
More Information

8. BGP Cores and Network Scalability

Border Gateway Protocol (BGP) is the routing protocol that (literally) glues the Internet together. It falls under the External Gateway Protocol (EGP) category—unlike the protocols described in previous chapters, which are Internal Gateway Protocols (IGPs). BGP4 is the current version, but throughout this chapter, it will be referred to simply as BGP.

Traditionally, BGP has been utilized to exchange routing information between different ASs. In the typical configuration, BGP is used to tie Internet service providers (ISPs) to their customers and each other. This chapter does not deal with connections to the Internet or inter-ISP operations—even though most of the experience in this area comes from the ISPs. Instead, it presents the proven, robust, and scalable BGP features that will allow your network to grow past any IGP limitations. The only portion where Internet connectivity is dealt with explicitly is in the “Case Study: Dual-Homed Connections to the Internet.”

This chapter is not about BGP itself, but how it can be used to scale your network even further. It is assumed that you are familiar with the basic operation of the protocol. If you need a quick review, read Appendix D,“BGP Fundamentals,” before continuing.

As described in previous chapters, hierarchy, addressing, summarization, and redundancy are essential components of a good network design. The way that the IGP of your choice is placed on top of these elements is equally important. However, all protocols have limitations, and as the network grows, you will unavoidably hit them. The main limitation is the amount of routing information that the protocol can handle, no matter how good your addressing scheme and summarization strategy is. On the other hand, BGP is currently deployed worldwide and carries more than 55,000 routing entries at the core of the Internet. (This number is growing at the time of this writing.) Some providers have been known to carry closer to 80,000 routes!

Policies are hard to define and enforce with an IGP because there is little flexibility—usually, only a tag is available. In the age of continuous mergers and acquisitions, it may be cumbersome and difficult to connect two networks while keeping instability isolated and managing multiple IGPs. BGP offers an extensive suite of knobs to deal with complex policies: communities, AS_PATH filters, local preference, and Multiple Exit Discriminator (MED), to name a few. BGP also counters instability by implementing a route dampening algorithm. This is when the advertisement of a route is suppressed if it is known to change regularly over a period of time. (All the parameters from the periodicity of the flaps to the type of routes suppressed are configurable.) Although you will follow the structural recommendations given in this book when building networks with the different IGPs studied, BGP is not tied to a set hierarchical model. In fact, the topology can take any form, and the protocol will adapt to it. Look at the Internet, it has no discernible hierarchical structure; it is impossible to pinpoint a core or a distribution layer (for the Internet as a whole)—and it works!

Neighbors, Routes, and Propagation Rules in BGP

A router using BGP exchanges routing information by forming a neighbor relationship with other routers. BGP routers can either establish internal or external peerings. BGP peers in the same AS are called iBGP peers, while peers in a different AS are called eBGP peers. An AS may have more than one external connection (on different routers); in which case, there is a need to have several BGP speakers in the network to maintain routing consistency. Unlike other protocols, the rules of when and if a prefix is advertised to a neighbor depend on the type of neighbor the prefix was learned from. There are three possible combinations:

  • Routes learned from an eBGP peer—Propagated to all peers.

  • Routes learned from an iBGP peer—Propagated only to eBGP peers.

  • Routes originated locally—Propagated to all peers.

Because routes learned from iBGP peers are not sent to other iBGP peers, it is clear that a full logical mesh is needed between them to ensure consistent routing information.

This chapter is a discussion of the use of BGP as a way to scale your network even further. The discussion starts with a description of the implementation in the core of the network (where full routing is required) and then expands the concepts to be used in the network as a whole.

BGP in the Core

The core is the place in your network where the scalability pains will be felt first. The core needs to have full knowledge of all the destinations in the network—full routes. The task is to configure BGP on all the core routers, and let it handle the routes that are external to the core. The IGP will carry only the information about local destinations. See Figure 8-1.

A simple way to shift the burden of carrying the routing information to BGP is to implement a full iBGP mesh in the core. In this case, the routing information from the distribution layer is redistributed into BGP, which carries it as internal routes. IGP routes have a lower administrative distance than iBGP and, hence, are favored. Therefore, it is necessary to filter all the IGP routes coming from the distribution layer into the core. Another solution is to use a different IGP in the core (or at least use a different instance or process). In addition, iBGP synchronization needs to be turned off. For details on synchronization, see Appendix D,“BGP Fundamentals.”

Figure 8-1. The Network Core

This approach provides an instant scalable core. In terms of migration, you should overlay BGP on the IGP that is currently in use. Once the routes have been redistributed into BGP, and its consistency is verified (in other words, make sure that all the routes are present in the BGP table), you can start filtering the IGP information at the border. If two or more distribution routers are introducing the same summary, then changing iBGP's administrative distance to favor its routes over the IGP's is a safer approach.

It is very important to highlight the fact that BGP was not conceived as an IGP; its main objective when it was designed was to carry external routes—routes learned from other ASs or routing domains. BGP cannot detect routing loops within an AS; it can detect loops only in eBGP routes.

Because of this, you cannot redistribute iBGP routes (routes originated in the local AS) into your IGP. In other words, the BGP routes cannot be passed on to the distribution layer. This leaves you with a single choice: to only carry a default pointing back to the core. If your distribution layer needs at least partial routing information from the core, then you will need to have an eBGP connection. This approach is explored in the following sections. Another advantage of using eBGP to glue your network together is the added flexibility (in filtering and decision making) that BGP provides.

Case Study: Sample Migration

Consider the network core in Figure 8-1. The first task is to overlay BGP on the existing network without any other changes taking place. The configuration is simple and can be standardized for ease of deployment:

router bgp 109
 no synchronization
 redistribute ospf 1 route-map routes-to-core
 neighbor x.x.x.x remote-as 109
 no auto-summary
!
route-map routes-to-core permit 10
 set metric-type internal

Note that synchronization and autosummary are turned off. This last action allows BGP to carry the routing information with the same granularity as the IGP does (not only the major networks). Also, the MED is set using the set metric-type internal command with the purpose of being able to choose the best exit point (shortest IGP distance) in case of multiple options. Remember: One neighbor statement is required for each of the other routers in the core.

As discussed in Chapter 5, “OSPF Network Design,” the ABRs may or may not be located at the edge of the core. The preceding configuration assumes that the ABRs are not the border routers—so redistribution of OSPF into BGP takes place. Keep in mind that the redistributed routes are the ones present in the routing table.

If the border routers are ABRs, then summarization takes place at these routers. The summarized routes, however, are not present in the routing table at the ABRs. It is necessary to manually create the summaries and then redistribute them. The sample configuration changes to something like this:

router bgp 109
 no synchronization
 neighbor x.x.x.x remote-as 109
 redistribute static route-map routes-to-core
 no auto-summary
!
router ospf 109
 area 0 range y.y.y.y y.y.y.y
 area 0 range t.t.t.t t.t.t.t
!
ip route y.y.y.y y.y.y.y null0
ip route t.t.t.t t.t.t.t null0
!
route-map routes-to-core permit 10
 set metric 20

An advantage of this method is that the routes are “nailed” to the null0 interface (which means it never flaps and never goes down), which will ensure stability in the core regardless of the state of any of the areas. One major difference in the approach is the use of the metric; in this case, the metric may be set either with a route map, or on each route at the time that they are defined.

To verify the consistency of the information in the BGP table, a comparison must be made between the data in the routing table (learned via OSPF, in this case) and the one in the BGP table. The following configuration presents an example of what you need to see (for network 20.1.1.0/24, in this case):

rtrC#show ip route 20.1.1.0
Routing entry for 20.1.1.0/24
 Known via "ospf 109", distance 110, metric 65, type intra area
 Redistributing via ospf 109
 Last update from 140.10.50.6 on Serial0, 00:00:28 ago
 Routing Descriptor Blocks:
 * 140.10.50.6, from 20.1.1.1, 00:00:28 ago, via Serial0
   Route metric is 65, traffic share count is 1

rtrC#show ip bgp 20.1.1.0
BGP routing table entry for 20.1.1.0/24, version 47
Paths: (1 available, best #1)
 Local
  140.10.50.6 from 140.10.50.6 (20.1.1.1)
   Origin incomplete, metric 20, localpref 100, valid, internal, best

If these two tables are not uniform, then you will need to revisit your redistribution points and check your filters (if any). Because LSA filtering can be tricky (at best) or impossible, changing the administrative distance for the iBGP routes will be explored next. To achieve the change, the following command is used:

router bgp 109
 distance bgp 20 20 20

This command sets the administrative distance for internal, external, and local BGP routes to 20. In Cisco routers, the default administrative distance for OSPF routes is 110—and the lowest value is preferred. To verify the effectiveness of the change, take a look at the routes again:

rtrC#show ip route 20.1.1.0
Routing entry for 20.1.1.0/24
 Known via "bgp 109", distance 20, metric 20, type internal
 Last update from 140.10.50.6 00:00:09 ago
 Routing Descriptor Blocks:
 * 140.10.50.6, from 140.10.50.6, 00:00:09 ago
   Route metric is 20, traffic share count is 1
   AS Hops 0

rtrC#show ip bgp 20.1.1.0
BGP routing table entry for 20.1.1.0/24, version 47
Paths: (1 available, best #1)
 Local
  140.10.50.6 from 140.10.50.6 (20.1.1.1)
   Origin incomplete, metric 20, localpref 100, valid, internal, best

Now, the BGP route is the one in the routing table.

   

Contents Next >

Save to MyCKS

 

Breaking News

One of the primary architects of OpenCable, Michael Adams, explains the key concepts of this initiative in his book OpenCable Architecture.

Expert Advice

Ralph Droms, Ph.D., author of The DHCP Handbook and chair of the IETF Dynamic Host Configuration Working Group, guides you to his top picks for reliable DHCP-related information.

Just Published

Residential Broadband, Second Edition
by George Abe

Introduces the topics surrounding high-speed networks to the home. It is written for anyone seeking a broad-based familiarity with the issues of residential broadband (RBB) including product developers, engineers, network designers, business people, professionals in legal and regulatory positions, and industry analysts.

             
     

From the Brains at InformIT

|

Contact Us

|

Copyright, Terms & Conditions

|

Privacy Policy

 

© Copyright 2000 InformIT. All rights reserved.