‚ < ‚ Free Open Study ‚ > ‚ |
Just as in managing outbound IP traffic from an AS, Cisco IOS Software offers BGP operators configuration options to manage inbound traffic in an AS. It is important that inbound traffic from other autonomous systems be managed well. If this does not happen, capacity of the network will not be fully utilized. This causes congestion in one part of the network while the other parts are underutilized . The end result of this mismanagement of inbound traffic flow is sluggish throughput, slow round-trip times, and delays in IP traffic. Therefore, it is essential that all inbound BGP policies are checked and configured correctly. Some of the most common problems in managing inbound IP traffic in an AS using BGP are as follows :
Problem: Multiple Connections Exist to an AS, but All the Traffic Comes in Through One BGP Neighbor, X, in the same AS ‚ Cause: Either BGP Neighbor at X Has a BGP Policy Configured to Make Itself Preferred over the Other Peering Points, or the Networks Are Advertised to Attract Traffic from Only XAs Figure 15-45 illustrates, AS 109 has multiple BGP connections to AS 110, and AS 109 is advertising prefix 100.100.100.0/24 to AS 110 at all locations. However, all the traffic from AS 110 to 100.100.100.0/24 comes through the connection at X. All other links between the two autonomous systems are underutilized. Figure 15-45. Two EBGP Connections Between Two Autonomous Systems, and One Link Carries Traffic There might be multiple reasons for this behavior, but two of the most common scenarios are as follows:
Figure 15-47 shows the flowchart to follow to resolve this problem. Figure 15-47. Problem-Resolution Flowchart Debugs and VerificationThis section discusses both cases of inbound traffic influence, discussed in the problem/cause presentation in the preceding section. Both necessary router configurations and show command outputs are displayed to examine the problem. Case 1This case is the one shown in Figure 15-45, in which R8 changed the LOCAL_PREFERENCE for 100.100.100.0/24. Example 15-87 shows the configuration in R8. The only significant con-figuration change is in R8, where route-map influencing_traffic is configured. Example 15-87 R8 Configuration to Change LOCAL_PREFERENCE to Affect Best-Path Calculation of BGPR8# router bgp 110 no synchronization neighbor 172.16.28.2 remote-as 109 neighbor 172.16.28.2 route-map influencing_traffic in neighbor 172.16.126.6 remote-as 110 ! access-list 1 permit 100.100.100.0 access-list 2 permit any route-map influencing_traffic permit 10 match ip address 1 set local-preference 200 ! route-map influencing_traffic permit 20 match ip address 2 set local-preference 90 In Example 15-87, R8 is configured with route-map influencing_traffic sequence 10, which changes the LOCAL_PREFERENCE to 200 for prefix 100.100.100.0/24 permitted by access list 1. The highest LOCAL_PREFERENCE wins in BGP best-path calculation, which affects all IBGP speakers in AS 110 (R6, in this example) and makes the path from R8 the best exit point to reach 100.100.100.0/24. Sequence 20 of the route map influencing traffic changes the LOCAL_PREFERENCE attribute to 90 for all other routes learned from neighbor 172.16.28.2 (R2). The output in Example 15-88 shows how BGP in R6 selects R8 as the best exit point. Notice that the first path (the best path) is an IBGP path from R6 to R8 with a LOCAL_PREFERENCE of 200. The second path is from the R1 ‚ R6 connection. The output from R8 in Example 15-88 shows that it has only a path for 100.100.100.0/24 and that is from R2. LOCAL_PREFERENCE is shown as 200, making it a best path advertised to R6. Example 15-88 show ip bgp Command Output Reveals the Best Exit PointR6# show ip bgp 100.100.100.0 BGP routing table entry for 100.100.100.0/24, version 6 Paths: (2 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: 172.16.126.1 109 172.16.28.2 (metric 20) from 172.16.28.8 (172.16.8.8) Origin IGP, metric 0, localpref 200 , valid, internal, best 109 172.16.126.1 from 172.16.126.1 (172.16.1.1) Origin IGP, metric 0, localpref 100, valid, external _____________________________________________________________________________________ R8# show ip bgp 100.100.100.0 BGP routing table entry for 100.100.100.0/24, version 2 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 109 172.16.28.2 from 172.16.28.2 (172.16.2.2) Origin IGP, metric 0, localpref 200 , valid, external, best Case 2This case is the one shown in Figure 15-46, in which R1 and R2 advertise different MEDs for 100.100.100.0/24 to R6 and R8, respectively. Example 15-89 details the configuration needed in R1 and R2. R6 and R8 have the standard BGP configuration for a simple neighbor relationship, so it is not shown. R1 and R2 have route-map MED_advertisement that advertises MEDs to their EBGP neighbors R6 and R8, respectively. Example 15-89 MED Advertisement from R1 and R2 to Influence Inbound Traffic for 100.100.100.0/24R1# router bgp 109 no synchronization bgp log-neighbor-changes network 100.100.100.0 mask 255.255.255.0 network 200.100.100.0 neighbor 172.16.126.2 remote-as 109 neighbor 172.16.126.6 remote-as 110 neighbor 172.16.126.6 route-map MED_advertisement out access-list 1 permit 100.100.100.0 access-list 2 permit any ! route-map MED_advertisement permit 10 match ip address 1 set metric 20 ! route-map MED_advertisement permit 20 match ip address 2 set metric 100 _____________________________________________________________________________________ R2# router bgp 109 no synchronization network 100.100.100.0 mask 255.255.255.0 neighbor 172.16.28.8 remote-as 110 neighbor 172.16.28.8 route-map MED_advertisement out neighbor 172.16.126.1 remote-as 109 ! ! access-list 1 permit 100.100.100.0 access-list 2 permit any route-map MED_advertisement permit 10 match ip address 1 set metric 1 ! route-map MED_advertisement permit 20 match ip address 2 set metric 200 In Example 15-89, R1 and R2 have route-map MED_advertisement configured with neighbors R6 and R8, respectively. In the case of R1, sequence 10 of the route map sets MED of 20 for 100.100.100.0/24 by access list 1 and sets the rest of the prefix MED to 100 by sequence 20 of the route map. R2 is configured in a similar manner to R1, but the MED of 1 is sent to R8 for 100.100.100.0/24 and a MED of 200 is sent for rest of the prefixes. The output in Example 15-90 shows the BGP output of prefix 100.100.100.0/24. The MED value of 1 is learned from R2 at R8, making this route the best route in AS 110. All traffic from AS 110 to prefix 100.100.100.0/24 will exit from X at R8. Notice the output in R6, which prefers the IBGP update from R8 because of a lower MED for prefix 100.100.100.0/24. Example 15-90 BGP Output for Prefix 100.100.100.0/24 Reveals the Best RouteR8# show ip bgp 100.100.100.0 BGP routing table entry for 100.100.100.0/24, version 12 Paths: (1 available, best #1, table Default-IP-Routing-Table) Advertised to non peer-group peers: 172.16.126.6 109 172.16.28.2 from 172.16.28.2 (172.16.2.2) Origin IGP, metric 1 , localpref 100, valid, external, best _____________________________________________________________________________________ R6# show ip bgp 100.100.100.0 BGP routing table entry for 100.100.100.0/24, version 13 Paths: (2 available, best #2, table Default-IP-Routing-Table) Advertised to non peer-group peers: 172.16.126.1 109 172.16.126.1 from 172.16.126.1 (172.16.1.1) Origin IGP, metric 20, localpref 100, valid, external 109 172.16.28.2 (metric 20) from 172.16.28.8 (172.16.8.8) Origin IGP, metric 1 , localpref 100, valid, internal, best SolutionReturn traffic influence can be desired as in Case 2, or it might happen as in Case 1. AS 109 BGP operators must understand what is causing this influence. In Case 1, in which AS 110 changed its BGP policy by altering the LOCAL_PREFERENCE, BGP does not offer any commands for AS 109 to influence the AS 110 policy. Each AS can force its own policy, and the outside AS cannot change that. The solution for the Case 1 problem lies with the AS 109 administrator requesting AS 110 to remove any policy that affects AS 109. In Case 2, AS 109 announced a MED and AS 110 was not configured to change LOCAL_PREFERENCE (as in Case 1). If the MED announcement is not producing the desired behavior for AS 109 inbound traffic management, these MEDs should be removed, and the normal BGP policies of AS 110 should decide on the best entry into AS 109. In larger BGP networks with numerous exit points and multiple BGP AS connections, traffic balance could become a challenge. Therefore, careful BGP policies and peering agreements must be created between BGP speakers, and traffic flow must be carefully observed . Problem: Multiple Connections Exist to Several BGP Neighbors, but Most of the Traffic from Internet to 100.100.100.0/24 Always Comes in Through One BGP Neighbor from AS 110 ‚ Cause: Route Advertisements for 100.100.100.0/24 in AS 109 Attract Internet Traffic Through That BGP Neighbor in AS 110When a BGP prefix is observed from a global Internet point-of-view , few BGP attributes stay intact from the originator of that prefix. For example, AS_PATH, ORIGIN_CODE and AGGREGATOR are the most common BGP attributes that get carried no matter how many autonomous systems a BGP update crosses. The most popular attributes, LOCAL_PREFERENCE and MED, do not cross an AS boundary. Therefore, they do not play any role in influencing return traffic from sources multiple autonomous systems away. As discussed in Chapter 14, the most common BGP attributes that get used in the BGP best-path algorithm are LOCAL_PREFERENCE, AS_PATH and MED. Out of these, AS_PATH is the only attribute that stays intact from the originator of the prefix to any Internet BGP speaker. Figure 15-48 shows the BGP update flow from AS 109 and also shows BGP best-path selection at each intermediate AS. AS 109 is originating AS 100.100.100.0/24, and its goal is to receive traffic from the Internet for 100.100.100.0/24 only through AS 110, not through AS 111. Figure 15-48. BGP Update Flow from AS 109/Best-Path Selection at Intermediate Autonomous Systems SolutionThe following are two common practices that BGP administrators use to achieve the previously mentioned goal:
|
‚ < ‚ Free Open Study ‚ > ‚ |