‚ < ‚ Free Open Study ‚ > ‚ |
Scaling IBGP in Large Networks ‚ Route Reflectors and ConfederationsIt is a common understanding that there exists a rule stating that IBGP neighbors must be fully meshed with each other. This section addresses why this is a requirement and how to avoid fully meshed IBGP. It is important to understand two rules of prefix advertisement:
This second rule requires a fully meshed IBGP neighbor relationship; otherwise , prefixes are not advertised to all routers in a single AS. IBGP full mesh can scale in networks where the number of IBGP running routers is small; however, in networks characteristic of a big ISP in which the number of routers running IBGP might reach several hundred, having an n ( n ‚ 1 ) (where n is the total number of routers in the AS) neighbor relationship and exchanging routes between all simply will not work. Figure 14-20 shows a fully meshed IBGP with only 12 routers running IBGP. Figure 14-20. Twelve-Router, Fully Meshed IBGP Network
Imagine the nightmare caused by replacing the 12-router full mesh with a 500-router full mesh of IBGP. This limitation of full-mesh IBGP was the catalyst for the development of two mechanisms that address this problem:
The sections that follow briefly describe both mechanisms. For more detailed coverage of these mechanisms, you are encouraged to read the RFCs. Route ReflectionInstead of doing full-mesh IBGP between all routers, Route-Reflection design allows router networks to have a hierarchy. Networks are divided into regions , and each region can have a multiple-layer hierarchy of Core, Aggregation, and Access routers. IBGP routing updates are propagated between levels in both directions when running Route-Reflection. Figure 14-21 replaces the fully meshed IBGP mess illustrated in Figure 14-20 by using Route-Reflection in an IBGP network. Each Access layer router connects to only regional Aggregation routers, and these Aggregation routers connect only to Core routers. The Core routers need to be fully meshed with each other. Multiple connections exist from each router for redundancy. Routers speak only IBGP with their upper-layer routers. For example, R1 peers only with R4 and R5, which peer only with R6 and R7. Core routers peer with each other and to all routers below them in the hierarchy. This way, the Core is connected to all regions. Figure 14-21. IBGP Network Using Route Reflection
The top level is a Route-Reflector (RR) for the bottom level that acts as a Route-Reflector-Client (RRC) for the top level. In Figure 14-21, the Core layer routers (R6 and R7) act as RRs for the Aggregation layer routers (R4, R5, R8, and R9); therefore, the Aggregation layer routers (R4, R5, R8, and R9) are RRCs of the Core layer routers (R6 and R7). An RR client can be a Route-Reflector for bottom-layer routers as well. Aggregation layer router R4, which is an RRC for the Core layer routers (R6 and R7), is also acting as an RR for Access layer Routers R1, R2, and R3, which are RRCs for the Aggregation layer routers (R4 and R5). Figure 14-21 gives an example of hierarchical Route-Reflection. A network that has just two layers (Core and Access) has only one level of Route-Reflection. Route-Reflection is configured only on the RR(s). Route-Reflector- Clients are unaware that they are part of any reflection; therefore, no configuration is needed to make them RRCs. The way that IBGP routing updates flow in an RR network is defined by the following rules:
In Figure 14-21, suppose that an EBGP neighbor is connected to Core Router R6 to advertise an update for 131.108.1.0/24. R6 passes that update to all neighbors because of rule 1 just mentioned, and the Aggregation layer (R4 and R5) will pass that to the Access layer (R1, R2, and R3) because of rule 2. Similarly, the east region will also propagate the update. This way, 131.108.1.0/24 will be propagated throughout the region without having a full mesh of IBGP. Now, imagine that Access layer Router R1 receives the prefix 140.1.1.0/24 from its EBGP neighbor. R1 propagates that to the Aggregation layer (R4 and R5) because of rule 1. R4 and R5 reflect the update to the Aaccess layer (R2 and R3) and to the Core layer (R6 and R7) because of rule 3. The Core layer (R6 and R7) reflects that update to the east region Aggregation layer (R8 and R9) because of rule 3. This way, 140.1.1.0/24 will be propagated from the lower layers to the upper layers in a hierarchical network. Hierarchical Route-Reflection networks make more sense when they are viewed as a group of RRs and their clients. Following are the definition of a few important and key concepts in understand hierarchical Route-Reflection.
Figure 14-22 shows cluster definition as configured on all RRs. Figure 14-22. Route Reflection Using Clusters
Example 14-29 shows how RR and cluster definitions are done in Cisco IOS Software. Specifically, this example looks at the configuration of R4, the RR in the Aggregation layer. Example 14-29 Sample Configuration of RR and Cluster in R4router bgp 109 neighbor 1.1.1.1 remote-as 109 neighbor 1.1.1.1 route-reflector-client neighbor 2.2.2.2 remote-as 109 neighbor 2.2.2.2 route-reflector-client neighbor 3.3.3.3 remote-as 109 neighbor 3.3.3.3 route-reflector-client neighbor 6.6.6.6 remote-as 109 neighbor 7.7.7.7 remote-as 109 bgp cluster-id 1.1.1.1 R4 has three clients ‚ R1 (1.1.1.1), R2 (2.2.2.2), and R3 (3.3.3.3) ‚ and two normal IBGP neighbors ‚ R6 (6.6.6.6) and R7 (7.7.7.7). No configuration in R4 shows that it is an RRC of R6 and R7. Assume that Access layer Router R1 in the west region advertises a prefix of 140.1.1.0/24. Example 14-30 provides show ip bgp output to display how this update would affect Access layer Router R12 in the east region. Example 14-30 show ip bgp Output to Show ClustersR12> show ip bgp 140.1.1.0 BGP routing table entry for 140.1.1.0/24 1.1.1.1 from 1.1.1.1 (1.1.1.1) Origin IGP, metric 0, localpref 100, valid, internal, best Originator : 1.1.1.1 Cluster list: 2.2.2.2 1.1.1.1 In Example 14-30, the originator is 1.1.1.1, which is the RID of R1. The cluster list shows the two clusters that this update has traversed. Route-Reflection solves the full IBGP mesh problem very elegantly and offers great flexibility for BGP networks to grow to much bigger IBGP networks. Almost all large BGP networks make use of Route-Reflection to scale their IBGP. AS ConfederationsIn an AS Confederation, an AS is divided into smaller Sub-autonomous systems, which are connected through EBGP to each other. Each Sub-AS acts as an independent BGP AS and runs normal IBGP internally within the Sub-AS. A single IGP is run in a complete AS and each Sub-AS has IGP routing information about all other Sub-autonomous systems. Most BGP attributes, such as LOCAL_PREF, MED, and NEXT_HOP, are preserved when updates go across a Sub-AS. The AS_PATH attribute adds the Sub-autonomous systems in the AS_PATH. To the outside world, the AS running AS Confederation appears as a single AS. To better understand AS Confederations, you need to know about how the AS_PATH attribute operates within an AS Confederation network. Just as the AS_PATH attribute carries information about autonomous systems the updates have traversed, AS_PATH in Confederation carries Sub-AS information. Just as with the AS_PATH attribute, when a router running Confederation receives an update whose AS_PATH contains its own Sub-AS, the router drops that update to avoid loops . The two BGP attributes associated with AS Confederations are described as follows :
Figure 14-23 shows an AS 109 divided into an AS Confederation of three small Sub-AS: 65001, 65002, and 65003. Each Sub-AS runs EBGP with the other Sub-autonomous systems. Notice that the Sub-autonomous systems do not have a full mesh of EBGP. This is similar to the real world of BGP where all EBGP speakers are not fully meshed. Each Sub-AS treats the other Sub-autonomous systems as EBGP neighbors, thus forwarding all updates from one Sub-AS to other Sub-autonomous systems. Figure 14-23. AS Confederations Using Sub-Autonomous Systems
Figure 14-23 shows that R1 in Sub-AS 65003 is running EBGP with autonomous system 110, which is advertising 140.1.1.0/24 to R1. When R1 receives the update from autonomous system 110, the prefix 140.1.1.0/24 will have the AS_PATH as 110. Sub-AS 65003 propagates this path to Sub-AS 65002 with the AS_PATH attribute as (65003) 110 . In BGP output, (65003) means that this autonomous system represents a Sub-AS of an AS Confederation. When this update leaves subautonomous system 65002, the AS_PATH looks like (65002 65003) 110 . When R12 in Sub-AS 65001 advertises 140.1.1.0/24 to the outside world, the AS_PATH field is stripped from the Confederation Sub-AS numbers , and the outside world is presented with AS_PATH as 109 110 for prefix 140.1.1.0/24 as if there were no Confederation in AS 109. Example 14-31 shows a sample BGP configuration in Router R4 in Sub-AS 65003. Example 14-31 Sample Confederation Sub-AS ConfigurationR4# router bgp 65003 confederation identifier 109 bgp confederation peers 65002 neighbor 1.1.1.1 remote-as 65003 neighbor 2.2.2.2 remote-as 65003 neighbor 3.3.3.3 remote-as 65003 neighbor 6.6.6.6 remote-as 65002 neighbor 7.7.7.7 remote-as 65002 In Example 14-31, confederation identifier represents the real AS assigned to this network, and 109 is the AS that the outside world sees. The bgp confederation peers command lists all the Confederation Sub-autonomous systems with which this router is peering. In this example, R4 is peering with Sub-AS 65002 (R6 and R7). R4 is also peering with three internal IBGP peers, R1, R2, and R3, at the 1.1.1.1, 2.2.2.2, and 3.3.3.3 addresses, respectively, in Sub-AS 65003. Although an AS Confederation offers a mechanism to avoid fully meshed IBGP in a large AS, a full mesh of IBGP is still a requirement within a Sub-AS. This presents a challenge of scaling IBGP within each Sub-AS. Each Sub-AS could then have a full mesh of IBGP or it could run Route-Reflection within each Sub-AS. In the quest to eliminate fully meshed IBGP using Route-Reflection or AS Confederations, BGP operators look at various reasons to prefer one to the other. It depends on, among other things, how the physical network is laid out, which method requires less configuration change, and which method offers ease in managing IBGP. |
‚ < ‚ Free Open Study ‚ > ‚ |