Implementing and Tuning BGP for Use in Large Networks

14 Mar

This chapter covers the following topics, which you need to understand to pass the CCNP/CCDP/CCIP BSCI exam:
■ Building a network using internal BGP
■ Understanding iBGP requirements
■ Designing and configuring a scalable iBGP network
■ Verifying the iBGP configuration
■ Controlling BGP traffic
■ Connecting to the Internet with BGP
■ Determining the BGP path by tuning the attributes
■ Redistribution between IGP and BGP

Implementing and Tuning BGP for Use in Large Networks
The topics in this chapter concern the advanced configuration of BGP. Whereas Chapter 15, “Connecting to Other Autonomous Systems—The Basics of BGP,” discussed basic concepts and configuration of BGP, this chapter delves into some of the complexities of BGP. In this chapter, you explore the uses of BGP—whether connecting to an ISP or even acting as an ISP with several connected organizations. The chapter also deals with the use of internal BGP (iBGP), which is BGP configured for systems within an autonomous system. The chapter covers how BGP can be configured to select a particular path and the design features and pitfalls of BGP. In this discussion of the advanced configuration of BGP, the explanation of the technology is coupled with configuration examples so that your conceptual understanding of BGP is reinforced by concrete implementation examples.

“Do I Know This Already?” Quiz
The purpose of the “Do I Know This Already?” quiz is to help you to decide what parts of this chapter to use. If you already intend to read the entire chapter, you do not necessarily need to answer these questions now.

The 18-question quiz, derived from the major sections in the “Foundation Topics” portion of the chapter, helps you to determine how to spend your limited study time.

Table 16-1 outlines the major topics discussed in this chapter and the “Do I Know This Already?” quiz questions that correspond to those topics.

Table 16-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping

558 Chapter 16: Implementing and Tuning BGP for Use in Large Networks
Table 16-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping (Continued)

CAUTION The goal of self-assessment is to gauge your mastery of the topics in this chapter. If you do not know the answer to a question or are only partially sure of the answer, you should mark this question wrong for purposes of the self-assessment. Giving yourself credit for an answer you correctly guess skews your self-assessment results and might provide you with a false sense of security.

1. How does the router determine whether it has received an iBGP or an eBGP update?
a. The router is configured to iBGP or eBGP; it cannot determine between the two.
b. The iBGP updates are not propagated; a received update must be from eBGP.
c. The router sees whether the received update has routes in the IGP routing table.
d. The router checks the autonomous system number in the open message that was sent.

2. Which of the following is true of iBGP neighbors?
a. iBGP does not require neighbors to be physically adjacent.
b. iBGP requires the neighbors to be physically adjacent.
c. iBGP neighbors must share the same IP subnet address.
d. iBGP neighbors must be used on a broadcast medium.

3. When is it possible to turn off the default synchronization?
a. When confederations are used
b. When route reflectors are configured
c. When the iBGP neighbors are fully meshed
d. When all the routers

4. Why is it necessary to have a fully meshed iBGP network?
a. No updates are propagated by other clients.
b. It is not possible to redistribute between the IGP and BGP.
c. To prevent routing loops.
d. BGP treats routing within the autonomous system as if it were an NBMA network.

5. Which of the following is true of route reflectors?
a. Route reflectors disallow the forwarding of attributes.
b. Route reflectors prevent the need for a fully meshed eBGP network.
c. Route reflectors are used to reflect routes to all neighbors.
d. Route reflectors forward routing updates to neighbors or within the autonomous system.

6. Which of the following is true of a route reflector client?
a. A client is a router that sends updates to the route reflector to be forwarded to other clients.
b. A client is a router that receives updates from a route reflector.
c. A client is a router that is configured and acts as a stub router.
d. A client is a router that receives routes from an IGP.

7. Select the statement that is true.
a. The routing table for IP contains the selected BGP path and the attributes.
b. BGP uses the command clear ip bgp * to clear the IP routing table.
c. By default, BGP does not store prefixes before policy application.
d. BGP sends incremental updates every 15 minutes.

8. Which of the following fields are shown in the show ip bgp neighbors command?
a. Neighbors
b. The prefixes associated with each neighbor
c. State of the BGP connections
d. The last time a message was read from a neighbor

9. What command is used to display the route reflector clients?
a. show ip ibgp neighbors
b. show ip bgp neighbor
c. show ip bgp route
d. show ip route reflector

10. Which of the following filtering techniques can be used to filter on prefixes?
a. AS_Path lists
b. Distribute lists
c. Access lists
d. Prefix lists

11. When using a prefix list, what is the match criterion used?
a. The first match
b. The attribute name
c. The match between ge and le
d. All matches

12. Which command is used to configure a prefix list?
a. ip bgp prefix list
b. ip prefix-list
c. access-list (200-299)
d. bgp prefix list (200-299)

13. What are the most common forms of multihoming?
a. ISPs send default routes into the autonomous system.
b. Complete routing tables are sent into the IGP.
c. Default and some selected routes are sent by the ISP into the autonomous system.
d. All routes known by ISP are sent into the autonomous system.

14. In the command show ip bgp , the origin field is placed at the end of each line in the table. It can be which of the following values?
a. Entry originated from IGP and was advertised with a network router configuration command.
b. Entry originated from an EGP.
c. Origin of the path is not clear. Usually, this is a router that is redistributed into BGP from an IGP.
d. The IP address of the originating router.

15. Which command shows the local preference and weight attribute values?
a. show bgp attributes
b. show ip bgp
c. show ip bgp path
d. show ip bgp attributes

16. Give the command that would change the weight attribute for the path to the next hop 192.10.5.3.
a. set weight 192.10.5.3 48
b. neighbor 192.10.5.3 weight 48
c. set attribute weight 48
d. ip bgp neighbor 192.10.0.0 remote-as 300 weight 48

17. Which are the ways to advertise routes into BGP?
a. They are automatically redistributed
b. The network command
c. Redistribute static routes
d. Redistribute dynamically learned routes from the IGP

18. What is the concern when advertising routes from BGP into an IGP?
a. BGP will receive too many routes and increase the size of the Internet routing tables.
b. Private addresses will be propagated into the Internet.
c. Routing loops will occur.
d. The IGP will be overwhelmed.

The answers to the “Do I Know This Already?” quiz are found in Appendix A, “Answers to Chapter ‘Do I Know This Already?’ Quizzes and Q&A Sections.” The suggested choices for your next step are as follows:

■ 9 or less overall score—Read the entire chapter. This includes the “Foundation Topics” and “Foundation Summary” sections, the “Q&A” section, and the “Scenarios” at the end of the chapter.
■ 10–14 overall score —Begin with the “Foundation Summary” section, and then go to the “Q&A” section and the “Scenarios” at the end of the chapter. If you have trouble with these exercises, read the appropriate sections in “Foundation Topics.”
■ 15 or more overall score —If you want more review on these topics, skip to the “Foundation Summary” section, and then go to the “Q&A” section and the “Scenarios” at the end of the chapter. Otherwise, move to the next chapter.

Foundation Topics
Building a Network Using Internal BGP

Though BGP is an exterior routing protocol, it comes in two flavors: internal BGP (iBGP) and external BGP (eBGP). The difference depends on the function of the routing protocol. The router will determine whether the peer BGP router is going to be an eBGP peer or an iBGP peer by checking the autonomous system number in the open message that was sent.

eBGP complies with the common perception of an external routing protocol; it sends routing information between different autonomous systems. Therefore, the border router between different autonomous systems is the eBGP router.

iBGP is used within an autonomous system. It conveys information to all BGP routers within the domain and ensures that they have a consistent understanding of the networks available.

iBGP is used by an ISP or a large organization when it is necessary to convey external BGP information about other autonomous systems across a transit autonomous system; that is, iBGP is used between eBGP speakers in the same autonomous system. In Figure 16-1, eBGP is used between AS 50 and AS 100, but in order to connect to AS 200, the BGP routing information must traverse AS 100. Once the routing protocol has traveled through AS 100, it returns to its more natural form of eBGP to connect to AS 200.

Understanding iBGP Network Requirements
To design and implement BGP correctly, there are a few characteristics about iBGP that are important to understand. The first of these rules, discussed in the next section, states that iBGP routers do not need to be directly connected, whereas eBGP routers must be physically connected (unless they are running multihop eBGP). You then learn about how synchronization and fully meshed networks factor into BGP network design.

Physical versus Logical Connections
Unlike Internal Gateway Protocols (IGPs), such as RIP, OSPF, and IPv6, that carry information about the autonomous system, the iBGP routers are not required to be physical neighbors on the same medium. In fact, they often sit at the edges of the autonomous system. Another routing protocol, an IGP such as OSPF, routes the BGP packets between the iBGP routers. In Figure 16-1, you see the iBGP routers are not directly connected, but that they have a TCP connection using TCP port number 179. This means that the internal protocol has topology independence.

Figure 16-1 iBGP and eBGP

Through a logical, not a physical, connection, TCP routes the BGP packets across the autonomous system by routers with routing tables maintained by OSPF. For BGP to communicate the routing information, it redistributes its routing information into the IGP. The integration of these different routing protocols can be challenging.

Now that you understand the topological requirements of iBGP, you can follow the criteria by which iBGP sends updates over this topology. An iBGP router propagates a route to a BGP neighbor under the following conditions:

■ If the advertised route was generated by the transmitting router by one of the following methods:
— Via the network command
— Redistributed from an IGP
— Redistributed static routes
■ If the advertised route is a connected route

These criteria are important to understand as they necessitate some design restrictions. Essentially, if the route was learned via an update from a BGP peer within the same autonomous system, a BGP router can propagate this route only to an eBGP peer.

Because iBGP does not forward updates it learned from an iBGP peer, iBGP peers need to be connected to one another (fully meshed) to have a complete knowledge of the network. However, a fully meshed network makes it difficult to scale iBGP because every router in the autonomous system has to build a BGP session with every other router in the autonomous system.

Synchronization
A simple rule states that before iBGP can propagate a route into another autonomous system by handing it over to eBGP, the route must be known throughout the autonomous system. That is to say, the IGP or internal routing protocol must be synchronized with BGP.

This synchronization is to ensure that if traffic is sent into the autonomous system, the interior routing protocol can direct it to its destination. The synchronization rule is on by default and should be turned off only if all routers in the autonomous system are running BGP.

For example, if you have a transit autonomous system with only the edge routers running iBGP, you are relying on the IGP to carry the traffic between the iBGP routers. It is therefore important for the IGP to have the information in its routing table to fulfill this task. This example is illustrated in Figure 16-2.

As you can see, AS 400 and AS 800 are using AS 200 as a transit autonomous system. In accordance with the synchronization rule, the router sending updates into AS 800 will not propagate 56.0.0.0 advertised by AS 400 unless the IGP, in this case OSPF, has full knowledge of how to get to 56.0.0.0. Otherwise, AS 800 might send traffic to 56.0.0.0, which would get lost in AS 200, because with an incomplete IP routing table, it would not be able to direct the traffic to the appropriate destination.

The synchronization rule is beneficial for the following reasons:
■ It prevents traffic from being forwarded to unreachable destinations.
■ It reduces unnecessary traffic.
■ It ensures consistency within the autonomous system.

Figure 16-2 Synchronization Rule and BGP

On some occasions, it is useful to turn off synchronization. As with any default, it is unwise to turn off this option without a detailed understanding of the network. The occasions when it might be useful to turn off synchronization are as follows:
■ If all the routers in the autonomous system are running BGP.
■ If all the routers inside the autonomous system are meshed.
■ When the autonomous system is not a transit autonomous system.
To turn off synchronization, you can use the following command in config-router mode:

Router(config-router)#no synchronization
This allows routers to advertise routes into BGP before the IGP has a copy of the route in its routing table.

A Fully Meshed Network
The BGP split horizon rule states that though the routers do not need to be directly connected, they do need to be fully meshed. This configuration is required to ensure full connectivity. To avoid routing loops, the protocol must follow the split horizon rule that no updates learned from internal peers can be sent to other internal peers. This means that the prefixes it receives are not redistributed to other iBGP systems. The prefixes are only propagated to a BGP system in another autonomous system, otherwise known as a peer eBGP system.

Network Resources Required in Fully Meshed Networks
BGP maintains up-to-date and accurate routing information by sending incremental updates across a TCP connection. The TCP connection is an excellent way of ensuring the accuracy of the information, but it is costly in network resources. The greater the number of connections, the greater the number of required resources. A simple equation demonstrates the problem, one that is also seen in the consideration of designing fully meshed Frame Relay networks.

The equation for determining the number of sessions required is as follows:
n (n – 1) / 2

In plain English, it is the number of routers minus 1, multiplied by the number of routers, and then divided by 2. Thus, 10 routers would mean 10 (10 – 1) / 2 = 10 * 9 / 2 = 45 sessions.

This equation works well in environments that require a few connections, such as a company with multiple connections into the Internet. However, if the network is an ISP that is using BGP throughout its network, some careful design should be put in place.

Administrative Overhead in Fully Meshed Networks
There is also administrative overhead in maintaining a fully meshed network of peers. For example, each time a peer is added, the number of iBGP peering configuration statements grows as well.

To be fair to TCP, it is not simply the maintenance of the connection that eats up resources, but the amount of updates that traverse those links. If every router is connected to every other router, a great deal of the information that is being sent is duplicated. Figure 16-3 illustrates the redundancy.

Designing and Configuring a Scalable iBGP Network
The problem of scalability presented by a fully meshed iBGP network can be solved by design. Configuration solutions allow you to overcome the rule that all iBGP peers must be fully meshed. These new commands allow you to develop a hub-and-spoke network to streamline the TCP connections. This is a good thing, but it does require some additional design and configuration. The solution is the implementation of route reflectors and the network design that they support.

Figure 16-3 iBGP and a Fully Meshed Network

The following section covers the use of route reflectors that reflect the updates from one connected client to other clients connected to the route reflector. The other topics discussed the next sections include route refresh, which resets the TCP connections and thus affects the change in configuration, and the use of peer groups. To streamline not only the configuration, but also the BGP traffic necessary to maintain full and accurate tables, peer groups are formed to allow one update to be sent to an identified group.

Route Reflectors
A route reflector is a router configured to forward routing updates to neighbors or peers within the same autonomous system. These iBGP peers need to be identified as clients in the configuration. When a client sends an update to the route reflector, it is forwarded or reflected to the other clients. Essentially, the route reflector defies the split horizon rule that states that the iBGP router will not propagate a route that was learned from a peer within the same autonomous system (an iBGP peer).

A client is a router that receives updates from a route reflector that a route reflector has forwarded from another client. It requires no configuration and has no idea that it is anything other than a peer.

The route reflector and the client require a full peer relationship because the route reflector forwards updates from other clients, but peering between the clients is not needed.

In all probability, a route reflector is connected to peers for which it is not forwarding routes. From the route reflector’s view, these neighbors or peers are nonclients. Nonclients must be fully meshed with the route reflector and each other.

When a router has been configured as a route reflector, it forwards paths learned from iBGP peers only to route reflector clients and to iBGP/eBGP neighbors. This means that a logical hub-and-spoke design can be implemented within an autonomous system between iBGP peers, thus reducing the number of peering sessions required.

Both a route reflector and its clients form a unit that shares information. This unit is called a cluster. The autonomous system can be divided into clusters, and the router reflectors identified and configured. There must be at least one route reflector per cluster. If a route reflector connects to other route reflectors, the route reflectors should be fully meshed. This is to ensure that the iBGP routing tables are complete.

When the route reflector forwards an update, the Originator-ID attribute is set. This is the BGP router ID of the router that originated the path. If this router receives back the update, it will see its own ID and will ignore the packet. This prevents the possibility of routing loops. If there are multiple route reflectors in the cluster to provide redundancy, the originating router is identified by the Cluster-ID attribute. This serves the same purpose as the Originator-ID in preventing routing loops.

The route reflector concept means that there is more overhead on the route reflector, and if it is configured incorrectly, it can cause serious routing loops. The design to avoid a fully meshed iBGP network can become quite complicated, but multiple route reflectors afford redundancy, which is always reassuring. Multiple levels of route reflectors can even be configured, creating a hierarchical design.

Nonroute reflector routers are not affected by the change in design and routing update propagation. Indeed, they are blissfully unaware of any changes because they still receive the updates that they need. The updates are also unchanged because no changes are made to the attribute values. This makes migration to a network design incorporating route reflectors very straightforward.
An important design suggestion is for the iBGP route reflectors to be fully meshed to ensure the correct propagation of updates. As mentioned earlier, it is possible to create a hierarchical design where route reflectors are clients of other route reflectors. This is a complex design and requires great care, because as soon as the route reflector is configured and split horizon disabled, there is no protection against a routing loop. A fully meshed route reflector design is therefore advised, as illustrated in Figure 16-4.

Figure 16-4 Design of iBGP Network Using Route Reflectors

The benefits of route reflectors include the following:
■ The capability to scale the network
■ A strong hierarchical design
■ A reduction of traffic on the network
■ A reduction in the memory and CPU needed to maintain TCP sessions on the client iBGP peers
■ Faster convergence and a simpler network because two routing protocols are implemented:
— iBGP for external routing information traversing the autonomous system
— IGP for routes internal to the autonomous system
The solution provided by route reflectors is used in large iBGP environments such as ISP networks, where a fully meshed iBGP network could result in a large number of TCP sessions. Figure 16-5 illustrates the relationship between route reflectors, clients, and other clusters.

The next sections examine how route reflectors operate, how the clients of route reflectors operate, and introduces the concept of a cluster in BGP.

570 Chapter 16: Implementing and Tuning BGP for Use in Large Networks
Figure 16-5 Clusters and Route Reflector Meshing

How Route Reflectors Operate
The previous section summarized of some of the characteristics of route reflectors. These characteristics determine how route reflectors operate. A route reflector is simply a mirror that reflects updates from clients to other clients without requiring a fully meshed network.

The following list shows what happens when a route reflector receives an update:
■ The client forwards an update to its peer, in this case, the route reflector.
■ An update from a client is received by the route reflector, and the update is forwarded to other clients as well as nonclients (both iBGP and eBGP peers). The originator ID is excluded from the update.
■ If multiple paths are received by the route reflector, the best path is chosen by the route reflector.

■ The only router that does have the update forwarded to it is the originator of the route.
■ A nonclient forwards an update to its peer, which happens to be a route reflector.
■ The route reflector receives an update from a nonclient, and the update is forwarded only to clients.
■ An eBGP peer sends an update to the route reflector.
■ The route reflector reflects the update to both clients and nonclients.

Configuring Route Reflectors
The command for configuring a route reflector is very straightforward. It is explained in the following syntax:

Remember that if all clients are removed, the route reflector loses its status and becomes a standard iBGP router. If this happens, the iBGP routers need to be fully meshed. Table 16-2 breaks down the syntax of the command to configure a route reflector and identify the clients.

Table 16-2 Explanation of the Route Reflector Configuration Command

Example 16-1 illustrates the concepts explained in this section. For simplicity, the connection to the eBGP router in AS 400 has not been included in the example. Use this example in conjunction with the network displayed in Figure 16-6.

572 Chapter 16: Implementing and Tuning BGP for Use in Large Networks
Figure 16-6 Network Topology Configured in Example 16-1

Example 16-1 Configuration of a Route Reflector (Continued)

Route Refresh
After any BGP configuration, it is necessary to reset the TCP session so that the changes can take effect. This is because the BGP process stores only prefixes that apply to the stated policy. If the policy changes, which means after any configuration, the peer session is torn down and rebuilt with the new characteristics.
It is now possible to issue a soft process reboot, which still destroys and rebuilds the peering sessions, but without a hard reboot of the BGP process.

The command to reboot all sessions is as follows:
Router#clear ip bgp *
The command to tell the peer to resend a full BGP update to a particular neighbor follows:
Router#clear ip bgp neighbor-address in
The command to tell the process to send a full BGP update to the peer follows:
Router# clear ip bgp neighbor-address oouutt

The clear ip bgp command is described in detail in Chapter 15.

It is also possible to configure the BGP process to store the prefixes before the policy application. This obviously requires greater memory, but it allows new configurations to be implemented without tearing down peering sessions.

The configuration is applied on a per-neighbor basis and only needs to be applied to the inbound updates. The syntax is as follows:

Router(config-router)#neighbor neighbor-address soft-configuration inbound
After a configuration change has been made, issue the following command from the executive level:
Router# clear ip bgp neighbor-address soft [in|out]

Peer Groups
Without peer groups, every iBGP peer—being fully meshed—receives the same update. This means every iBGP router performs the same calculations, wasting CPU and restricting the ability of iBGP to scale.

Once peer groups are configured, every router within the peer group has the same outbound policy, while allowing different inbound policies to be configured on each system. This means that one update can be generated for the group, resulting in the following benefits:

■ The administrative overhead is reduced, because the configuration is simpler, reducing the possibility of errors.
■ Less CPU is required, speeding up the network responsiveness. When a network converges quickly, it becomes more stable and reliable.

To define a peer group, use the following:

Router(config-router)#neighbor peer-group-name peer-group

Example 16-2 shows how the peer group IBGP-peergp is created and applied to iBGP neighbors.
Example 16-2 Configuration of a Peer Group to iBGP Neighbors

Verifying the iBGP Configuration
It is also important to verify that a configuration is working. Example 16-3 demonstrates the command that verifies the configuration of router 167.55.44.3 and its neighbors and that inbound soft reconfiguration was configured and works.

Example 16-3 Example of the show ip bgp neighbors Command

Table 16-3 describes the fields shown in Example 16-3.
Table 16-3 Explanation of the show ip bgp neighbors Command

Table 16-3 Explanation of the show ip bgp neighbors Command (Continued)

NOTE When implementing clusters and route reflectors, select the route reflector carefully in accordance with the physical topology of the network. Keep the design simple, placing one route reflector in a cluster. When the logical cluster design is in place, configure one cluster at a time and one route reflector at a time. After the route reflector in the cluster is configured, remove the BGP configuration that has the BGP sessions between the clients.

No comments yet

Leave a Reply

You must be logged in to post a comment.