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 conﬁguring a scalable iBGP network
■ Verifying the iBGP conﬁguration
■ Controlling BGP trafﬁc
■ 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 conﬁguration of BGP. Whereas Chapter 15, “Connecting to Other Autonomous Systems—The Basics of BGP,” discussed basic concepts and conﬁguration 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 conﬁgured for systems within an autonomous system. The chapter covers how BGP can be conﬁgured to select a particular path and the design features and pitfalls of BGP. In this discussion of the advanced conﬁguration of BGP, the explanation of the technology is coupled with conﬁguration 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 conﬁgured 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 reﬂectors are conﬁgured
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 reﬂectors?
a. Route reﬂectors disallow the forwarding of attributes.
b. Route reﬂectors prevent the need for a fully meshed eBGP network.
c. Route reﬂectors are used to reﬂect routes to all neighbors.
d. Route reﬂectors forward routing updates to neighbors or within the autonomous system.
6. Which of the following is true of a route reﬂector client?
a. A client is a router that sends updates to the route reﬂector to be forwarded to other clients.
b. A client is a router that receives updates from a route reﬂector.
c. A client is a router that is conﬁgured 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 preﬁxes before policy application.
d. BGP sends incremental updates every 15 minutes.
8. Which of the following ﬁelds are shown in the show ip bgp neighbors command?
b. The preﬁxes 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 reﬂector 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 ﬁltering techniques can be used to ﬁlter on preﬁxes?
a. AS_Path lists
b. Distribute lists
c. Access lists
d. Preﬁx lists
11. When using a preﬁx list, what is the match criterion used?
a. The ﬁrst match
b. The attribute name
c. The match between ge and le
d. All matches
12. Which command is used to conﬁgure a preﬁx 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 ﬁeld 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 conﬁguration 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 18.104.22.168.
a. set weight 22.214.171.124 48
b. neighbor 126.96.36.199 weight 48
c. set attribute weight 48
d. ip bgp neighbor 188.8.131.52 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.
Building a Network Using Internal BGP
Though BGP is an exterior routing protocol, it comes in two ﬂavors: 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 ﬁrst 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 difﬁcult to scale iBGP because every router in the autonomous system has to build a BGP session with every other router in the autonomous system.
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 trafﬁc 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 trafﬁc between the iBGP routers. It is therefore important for the IGP to have the information in its routing table to fulﬁll 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 184.108.40.206 advertised by AS 400 unless the IGP, in this case OSPF, has full knowledge of how to get to 220.127.116.11. Otherwise, AS 800 might send trafﬁc to 18.104.22.168, which would get lost in AS 200, because with an incomplete IP routing table, it would not be able to direct the trafﬁc to the appropriate destination.
The synchronization rule is beneﬁcial for the following reasons:
■ It prevents trafﬁc from being forwarded to unreachable destinations.
■ It reduces unnecessary trafﬁc.
■ 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 conﬁg-router mode:
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 conﬁguration 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 preﬁxes it receives are not redistributed to other iBGP systems. The preﬁxes 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 conﬁguration 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. Conﬁguration 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 conﬁguration. The solution is the implementation of route reﬂectors and the network design that they support.
Figure 16-3 iBGP and a Fully Meshed Network
The following section covers the use of route reﬂectors that reﬂect the updates from one connected client to other clients connected to the route reﬂector. The other topics discussed the next sections include route refresh, which resets the TCP connections and thus affects the change in conﬁguration, and the use of peer groups. To streamline not only the conﬁguration, but also the BGP trafﬁc necessary to maintain full and accurate tables, peer groups are formed to allow one update to be sent to an identiﬁed group.
A route reflector is a router conﬁgured to forward routing updates to neighbors or peers within the same autonomous system. These iBGP peers need to be identiﬁed as clients in the conﬁguration. When a client sends an update to the route reﬂector, it is forwarded or reﬂected to the other clients. Essentially, the route reﬂector deﬁes 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 reﬂector that a route reﬂector has forwarded from another client. It requires no conﬁguration and has no idea that it is anything other than a peer.
The route reﬂector and the client require a full peer relationship because the route reﬂector forwards updates from other clients, but peering between the clients is not needed.
In all probability, a route reﬂector is connected to peers for which it is not forwarding routes. From the route reﬂector’s view, these neighbors or peers are nonclients. Nonclients must be fully meshed with the route reﬂector and each other.
When a router has been conﬁgured as a route reﬂector, it forwards paths learned from iBGP peers only to route reﬂector 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 reﬂector 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 reﬂectors identiﬁed and conﬁgured. There must be at least one route reﬂector per cluster. If a route reﬂector connects to other route reﬂectors, the route reﬂectors should be fully meshed. This is to ensure that the iBGP routing tables are complete.
When the route reﬂector 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 reﬂectors in the cluster to provide redundancy, the originating router is identiﬁed by the Cluster-ID attribute. This serves the same purpose as the Originator-ID in preventing routing loops.
The route reﬂector concept means that there is more overhead on the route reﬂector, and if it is conﬁgured incorrectly, it can cause serious routing loops. The design to avoid a fully meshed iBGP network can become quite complicated, but multiple route reﬂectors afford redundancy, which is always reassuring. Multiple levels of route reﬂectors can even be conﬁgured, creating a hierarchical design.
Nonroute reﬂector 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 reﬂectors very straightforward.
An important design suggestion is for the iBGP route reﬂectors to be fully meshed to ensure the correct propagation of updates. As mentioned earlier, it is possible to create a hierarchical design where route reﬂectors are clients of other route reﬂectors. This is a complex design and requires great care, because as soon as the route reﬂector is conﬁgured and split horizon disabled, there is no protection against a routing loop. A fully meshed route reﬂector design is therefore advised, as illustrated in Figure 16-4.
Figure 16-4 Design of iBGP Network Using Route Reflectors
The beneﬁts of route reﬂectors include the following:
■ The capability to scale the network
■ A strong hierarchical design
■ A reduction of trafﬁc 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 reﬂectors 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 reﬂectors, clients, and other clusters.
The next sections examine how route reﬂectors operate, how the clients of route reﬂectors 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 reﬂectors. These characteristics determine how route reﬂectors operate. A route reﬂector is simply a mirror that reﬂects updates from clients to other clients without requiring a fully meshed network.
The following list shows what happens when a route reﬂector receives an update:
■ The client forwards an update to its peer, in this case, the route reﬂector.
■ An update from a client is received by the route reﬂector, 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 reﬂector, the best path is chosen by the route reﬂector.
■ 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 reﬂector.
■ The route reﬂector receives an update from a nonclient, and the update is forwarded only to clients.
■ An eBGP peer sends an update to the route reﬂector.
■ The route reﬂector reﬂects the update to both clients and nonclients.
Configuring Route Reflectors
The command for conﬁguring a route reﬂector is very straightforward. It is explained in the following syntax:
Remember that if all clients are removed, the route reﬂector 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 conﬁgure a route reﬂector 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)
After any BGP conﬁguration, it is necessary to reset the TCP session so that the changes can take effect. This is because the BGP process stores only preﬁxes that apply to the stated policy. If the policy changes, which means after any conﬁguration, 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 conﬁgure the BGP process to store the preﬁxes before the policy application. This obviously requires greater memory, but it allows new conﬁgurations to be implemented without tearing down peering sessions.
The conﬁguration 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 conﬁguration change has been made, issue the following command from the executive level:
Router# clear ip bgp neighbor-address soft [in|out]
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 conﬁgured, every router within the peer group has the same outbound policy, while allowing different inbound policies to be conﬁgured on each system. This means that one update can be generated for the group, resulting in the following beneﬁts:
■ The administrative overhead is reduced, because the conﬁguration 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 deﬁne 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 conﬁguration is working. Example 16-3 demonstrates the command that veriﬁes the conﬁguration of router 22.214.171.124 and its neighbors and that inbound soft reconﬁguration was conﬁgured and works.
Example 16-3 Example of the show ip bgp neighbors Command
Table 16-3 describes the ﬁelds 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 reﬂectors, select the route reﬂector carefully in accordance with the physical topology of the network. Keep the design simple, placing one route reﬂector in a cluster. When the logical cluster design is in place, conﬁgure one cluster at a time and one route reﬂector at a time. After the route reﬂector in the cluster is conﬁgured, remove the BGP conﬁguration that has the BGP sessions between the clients.