Policy Control
| ‚ < ‚ Free Open Study ‚ > ‚ |
| Policy control means that BGP provides power to control prefix filtering and manage IP traffic flow into and out of the BGP network. BGP policies can flow downstream and affect policy of those autonomous systems to which routes are being propagated. In a large BGP network that is divided into multiple regions , special requirements must be met in terms of what type and how much traffic can flow in and out of each region. BGP policy control gives network operators a highly scalable way of maintaining traffic flows. BGP policies are defined by BGP attributes that consist of the following:
Typically, ATOMIC_AGGREGATE and AGGREGATOR are not used in defining and configuring BGP policies in routers and therefore will not be discussed in detail in this chapter. The remaining attributes will be illustrated and explained in detail in this chapter. The routing table of a router dictates how traffic destined to a certain destination exits that router. If the focus of traffic flow is shifted to a region where many routers are present, the routing policy depicted in the routing tables of each router dictates how traffic exits that region. Similarly, all the regions combined can be viewed as a complete IP network. Routing policy depicted in routing tables of all the devices in the network reflects how traffic exits out the network. Figure 14-10 shows how network traffic flows across multiple regions and through multiple routers based on the BGP policy defined to influence the path that data traffic takes from source to destination. Figure 14-10. Network Designed to Take Advantage of BGP Routing Policies Single BGP AS is divided into multiple regions. Traffic flows from source to destination, crossing multiple regions based on the BGP policy defined. In Figure 14-10, it seems more logical that traffic from source to destination travels Region 1, Region 2, and Region 3, and then to the final destination because that seems to be the shortest path from source to destination. Region 2, however, is configured with a BGP policy that shifts traffic from Region 2 to Region 4 instead. Network architects design and decide on such policies when traffic takes a longer path. Factors such as bandwidth availability, congestion, router capacity, and many others play a significant role in the definition of these policies. How is a BGP policy created? Manipulation of BGP attributes defines BGP policies. Packet forwarding in a router happens from the routing table and BGP policy dictates which route of many is chosen to go in the routing table. Figure 14-11 illustrates a simple example of policy control in the case of EBGP. Figure 14-11. BGP Policy Control Example AS 109 network administrators require a BGP policy so that, as shown in Figure 14-11, traffic destined to 131.108.1.0/24 from AS 109 must use the R1 ‚ R3 link. The R1 ‚ R2 link should be used as a backup. This can happen only if routing tables in all the devices of AS 109 show R1 ‚ R3 as the exit point and if the path through R2 is present in the BGP table and not in routing table of R1. The method of choosing one path over the other is accomplished by manipulating the right BGP attribute. In Figure 14-11, R1 learns two paths to reach 131.108.1.0/24 ‚ one through R2 and the other through R3. R1 must pick the path through R3 because of the required BGP policy, and BGP attributes must be changed so that the path from R3 becomes more attractive than the path from R2. When that happens, IP traffic (after following the routing table) flows from all devices in AS 109 to exit through R3 to reach 131.108.1.0/24. The following sections explain using the BGP attributes and the methods of changing them to define BGP policies. Policy Control Using BGP AttributesBGP picks a best path for a destination IP prefix from multiple paths and then installs it in the routing table. This best path forwards IP traffic. By default, BGP does a decent job of choosing the appropriate path; however, with the huge size of router-based networks, it is essential that BGP path selection be managed by network operators to have a BGP policy that optimally uses the network. BGP attributes are often manipulated to manage BGP networks. Examples of most commonly used BGP attributes are listed here:
The sections that follow describe these BGP attributes in greater detail and describe how to manipulate them for BGP policy control, where applicable . LOCAL_PREF AttributeA 32-bit non-negative integer value of LOCAL_PREF in BGP updates defines a preference of one exit point within an AS over others to reach the originator of the route. LOCAL_PREF has no significance outside an AS; therefore, it affects only the outgoing traffic from an AS. LOCAL_PREF is not advertised to EBGP neighbors and is propagated to only IBGP neighbors. Figure 14-12 explains how LOCAL_PREF is handled in networks running BGP. Figure 14-12. LOCAL_PREF Attribute Operation in BGP Networks R1 in AS 109 is advertising 131.108.1.0/24 to its EBGP neighbors R2 and R3 in AS 110. BGP updates sent to EBGP neighbors do not contain LOCAL_PREF. In Cisco IOS Software, LOCAL_PREF is given a default value of 100 for all the prefixes learned from EBGP neighbors. Cisco IOS Software also allows the user to configure LOCAL_PREF, as shown later in this chapter. As Figure 14-12 shows, because the link between R1 and R2 is bigger than the link from R1 to R3, it is likely desired that traffic from AS 110 to AS 109 use the R1 ‚ R2 link rather than the R1 ‚ R3 link. Therefore, R2 is configured so that it changes the LOCAL_PREF to 200 for all the prefixes that it learned from R1. Because LOCAL_PREF is advertised to all IBGP neighbors, R3, R4, and R5 receive 131.108.1.0/24 with a LOCAL_PREF of 200 from R2. R3 has an additional path for 131.108.1.0/24 from R1, and its LOCAL_PREF was unchanged and is defaulted to 100. Now, R3 must decide between two paths for 131.108.1.0/24, one from R1 and the other from R2. As explained later in the discussion of best-path calculation of BGP, the path with the higher LOCAL_PREF wins; therefore, the path from R2 will win and get installed in the routing table for R3. Similarly, R4 and R5 will choose R2 to reach 131.108.1.0/24. In Figure 14-12, R4 and R5 are receiving only one path for 131.108.1.0/24, and that is from R2. If they were receiving multiple paths from multiple IBGP neighbors, they would have decided on the best path based on a higher LOCAL_PREF, just like R3 did. When R6 in AS 111 is sending traffic for 131.108.1.1, it exits AS 110 from R2 because AS 110 has preferred R2 as an exit point for 131.108.1.0/24. Figure 14-12 explains that LOCAL_PREF plays a significant role in managing outgoing traffic from AS 109 to destinations outside AS 109. Example 14-3 shows the configuration needed to manipulate the LOCAL_PREF attribute in R2, as illustrated in Figure 14-12. Example 14-3 Configuring the LOCAL_PREF AttributeR2# router bgp 110 neighbor 1.1.1.1 remote-as 109 neighbor 1.1.1.1 route-map SET_LOCAL_PREF in route-map SET_LOCAL_PREF permit 10 match ip address 1 set local-preference 200 route-map SET_LOCAL_PREF permit 20 match ip address 2 access-list 1 permit 131.108.1.0 access-list 2 permit any The IP address of R1 in AS 109 is 1.1.1.1. SET_LOCAL_PREF is the route map that is applied on an EBGP session with R1. The route map usage is defined in detail in Chapter 1, "Understanding IP Routing." The first sequence of the route map has a match statement against access-list 1 that permits 131.108.1.0/24. The set command configures the LOCAL_PREF to 200 for prefixes that pass access-list 1 . The second sequence of the route map is necessary to allow all other prefixes from this neighbor without changing the LOCAL_PREF. After this configuration in R2, the output of the BGP table for prefix 131.108.1.0/24 from R2 and R3 looks like Example 14-4. Example 14-4 BGP Output of the Prefix 131.108.1.0/24 After LOCAL_PREF ChangeR2# show ip bgp 131.108.1.0 BGP routing table entry for 131.108.1.0/24, version 8 Paths: (1 available, best #1) Advertised to non peer-group peers: 1.1.8.3 109 1.1.7.1 from 1.1.7.1 (10.1.1.1) Origin IGP, metric 0, localpref 200, valid, external, best _____________________________________________________________________________________ R3# show ip bgp 131.108.1.0 BGP routing table entry for 131.108.1.0/24, version 8 Paths: (2 available, best #1) Not advertised to any peer 109 1.1.7.1 (metric 307200) from 1.1.8.2 (10.0.0.5) Origin IGP, metric 0, localpref 200 , valid, internal, best 109 1.1.2.1 from 1.1.2.1 (10.1.1.1) Origin IGP, metric 0, localpref 100 , valid, external R3 has two updates, one from R1 and the other from R2. The path from R2 is selected as the best path because of the higher LOCAL_PREF. MULTI_EXIT_DISC (MED) AttributeA 32-bit non-negative integer value of MED in BGP updates defines a method to choose among multiple exit points in the same neighboring AS. MED is a nontransitive attribute of BGP; therefore, if it is received from an EBGP neighbor, it is sent to an IBGP neighbor, but it does not get propagated to other EBGP neighbors. Figure 14-13 explains the usage of MED. In AS 109, RI has two links to AS 110. The link between R1 and R2 has a higher bandwidth than the link between R1 and R3. Therefore, R1 might decide that all traffic destined to 131.108.1.0/24 must exit AS 110 through the R1 ‚ R2 link, not the R1 ‚ R3 link. Figure 14-13. MULTI_EXIT_DISC (MED) Attribute Operation in BGP Networks A lower MED value is preferred when comparing the two updates. In Cisco IOS Software, MED is compared only between updates from within the same AS. To compare MED values in updates from different autonomous systems, Cisco IOS Software must be configured with bgp always-compare-med in BGP subcommands. The AS 109 policy dictates that all traffic destined for 131.108.1.0/24 should come through the R1 ‚ R2 link and that the R1 ‚ R3 link should be used as a backup in case the R1 ‚ R2 link goes down. To achieve this, R1 advertises 131.108.1.0/24 to both neighbors in R2 and R3 in AS 110. However, R1 should advertise a lower MED value to R2 than to R3. Example 14-5 shows a sample configuration of R1 to achieve the goal. Example 14-5 Configuring the MED AttributeR1# router bgp 109 neighbor 1.1.7.2 remote-as 110 neighbor 1.1.7.2 route-map SEND_LOWER_MED out neighbor 1.1.2.3 remote-as 110 neighbor 1.1.2.3 route-map SEND_HIGHER_MED out route-map SEND_LOWER_MED permit 10 match ip address 1 set metric 10 ! route-map SEND_LOWER_MED permit 20 match ip address 2 route-map SEND_HIGHER_MED permit 10 match ip address 1 set metric 20 ! route-map SEND_HIGHER_MED permit 20 match ip address 2 access-list 1 permit 131.108.1.0 access-list 2 permit any 1.1.7.2 and 1.1.2.3 are two neighbors of R1. They are both configured with route maps to advertise a MED of 10 and 20, respectively, for the prefix 131.108.1.0/24. This occurs in sequence 10 of the route map. Sequence 20 permits all other prefixes, if any, advertised from R1 to R2 and R3, and no MED changes were applied to them. Example 14-6 shows the output of R3 and R2 after this configuration change in R1. Example 14-6 Output of BGP Table from R3 and R2 After the MED Advertisement from R1R3#show ip bgp 131.108.1.0 BGP routing table entry for 131.108.1.0/24, version 10 Paths: (2 available, best #2) Not advertised to any peer 109 1.1.2.1 from 1.1.2.1 (10.1.1.1) Origin IGP, metric 20, localpref 100, valid, external 109 1.1.7.1 from 1.1.8.2 (10.0.0.5) Origin IGP, metric 10, localpref 100, valid, internal, best _____________________________________________________________________________________ R2#show ip bgp 131.108.1.0 BGP routing table entry for 131.108.1.0/24, version 10 Paths: (1 available, best #1) Advertised to non peer-group peers: 1.1.8.3 109 1.1.7.1 from 1.1.7.1 (10.1.1.1) Origin IGP, metric 10, localpref 100, valid, external, best With this configuration, the prefix 131.108.1.0/24 MED field looks like the following in R2 and R3:
R2 has only one path for 131.108.1.0/24, whereas R3 has two. This is because R2 is advertising its best route to all its IBGP neighbors (R3, R4, and R5, in this example). R3's best path for 131.108.1.0/24 is from R2, so R3 will not advertise its best path back to R2 because that path originally came from R2. Because the lower MED wins in BGP best-path calculation, in R3, the path from R2 wins over the path from R1. Thus, all traffic from autonomous system 110 for 131.108.1.0/24 will exit through R2. MED is a nontransitive attribute and will not be advertised to AS 111 by AS 110. R5 and R6 might configure to advertise the same or different MED to R6 in AS 111, but the MED value originally set by R1 in AS 109 will not be kept. Because of the BGP MED policy of R1, traffic from R6 in AS 111 to 131.108.1.1 in AS 109 will exit from R2, not from R3 in AS 110. The MED attribute plays a significant role in influencing incoming traffic in case multiple connections exist between the same AS. The example in Figure 14-13 is most commonly seen in enterprise BGP networks where routers in AS 109 are dual homed to an ISP in AS 110. In Cisco IOS Software, MED is compared only between updates from within the same AS. In Example 14-5, R3 compared MEDs because 131.108.1.0/24 came from the same AS 109. To compare MED values in updates from different autonomous systems, Cisco IOS Software must be configured with bgp always-compare-med in BGP subcommands. Figure 14-14 shows a more complex example, as seen in ISP networks advertising MED to other ISP. Figure 14-14. MULTI_EXIT_DISC (MED) Attribute Operation Between ISPs AS 109 has two regional connections, east and west, with AS 110. AS 109 needs to make sure that regional traffic destined to AS 109 regions must enter through their respective regional links. This can be accomplished by defining the following:
The first task is achieved through the configuration shown later in this chapter. The second task is more of a peering agreement between AS 109 and AS 110. Honoring MED means that AS 110 must accept the MED announcements from AS 109 and will not overwrite them with its own policies. Honoring MED is typically a two-way relationship: AS 110 honors AS 109 MED only if AS 109 does the same for AS 110 MED. By honoring the MED, AS 110 carries traffic destined to AS 109 through its backbone and exits at the closest point in AS 109. If AS 110 decides not to honor AS 109 MED, it will have its own policies to carry traffic for AS 109. Instead of an optimal exit point, AS 110 might choose the closest exit point. Figure 14-15 shows how traffic flows in AS 110 when it honors the MED from AS 109. Figure 14-15. MULTI_EXIT_DISC (MED) Attribute Operation Between ISPs Traffic sourcing behind R2 destined for 140.1.1.1 will traverse AS 110 backbone routers because they have all received the proper MED announcement from AS 109 as the MED is propagated within the IBGP cloud. This traffic exits AS 110 at R5, the exit point closest to the destination, 141.1.1.1. Similarly, traffic behind R4 destined for 131.108.1.1 exits at R3. In some situations, ISPs do not honor each other's MEDs. In this case, AS 110 might dump all traffic destined to AS 109 to its closest exit point and not carry its traffic through the backbone. Such an example can arise when traffic destined to 140.1.1.1 from sources behind R2 carries over to R3 and exits to R1; AS 109 must carry that traffic across its backbone to reach R6 in the east region. Proper usage of the MED attribute can also be called cold potato routing (defined earlier in the chapter). AS_PATH AttributeThe AS_PATH attribute defines the list of autonomous systems through which a BGP update has traversed. It is a mandatory attribute that BGP updates must carry, and it is changed only when a BGP update is sent to an EBGP neighbor. Figure 14-16 explains how the AS_PATH attribute works. Figure 14-16. AS_PATH Attribute Operation in BGP Networks AS 109 is advertising 131.108.1.0/24 to its EBGP neighbor in AS 110. The BGP speaker must prepend its AS number at the left-most position in the AS_PATH attribute field, while sending an update to its EBGP neighbor. R1 prepends its AS number 109 in that field. R2 advertises this update to its IBGP speakers R3 and R4 but does not change the AS_PATH. R3 and R4 prepend their AS 110 when advertising this prefix to AS 111. When a router receives a BGP update that has an AS_PATH attribute that lists its own AS in it, that update is considered looped and is dropped. This mechanism is used in BGP to detect routing loops . A smaller AS_PATH length is preferred when comparing the two BGP updates. Refer back to the network topology in Figure 14-13. AS 109 wants to define a BGP policy so that all traffic destined to 131.108.1.0/24 from AS 110 must enter through the R2 ‚ R1 link, and the R3 ‚ R1 link should be used as a backup. Visualizing that in R2, R3, and R4 (all in AS 110), the AS_PATH field for the prefix 131.108.1.0/24 is 109. R3 has two paths for this prefix, one from R1 and the other from R2. The best-path calculation rule will tie because the AS_PATH length is identical, at 1. BGP Best-path calculation moves down to next tie-breaking criteria, per the best-path calculation rule described in this chapter. Example 14-7 demonstrates how R1 can achieve its goal of preferring the R1 ‚ R2 link over the R1 ‚ R3 link for traffic destined to 131.108.1.0/24/. One approach is to use MEDs so that R1 advertises a lower MED when advertising prefix 131.108.1.0/24 to R2 and advertises a higher MED to R3. Another approach is to make the AS_PATH length longer for the advertisement from R1 to R3 for this prefix. Because the BGP best-path calculation rule looks at AS_PATH length as the tie-breaker rule between multiple paths, the R1 ‚ R3 path will lose and the R1 ‚ R2 path will win and be installed in the routing table. Example 14-7 shows the configuration needed in R1 to achieve this. Example 14-7 Using the AS_PATH Attribute on R1 to Dictate the Best PathR1# router bgp 109 network 131.108.1.0 mask 255.255.255.0 neighbor 1.1.2.3 remote-as 110 neighbor 1.1.2.3 route-map AS_PREPEND out neighbor 1.1.7.2 remote-as 110 route-map AS_PREPEND permit 10 match ip address 1 set as-path prepend 109 109 ! route-map AS_PREPEND permit 20 match ip address 2 access-list 1 permit 131.108.1.0 access-list 2 permit any 1.1.2.3 is the R3 IP address, and route-map AS_PREPEND is configured in R1 for R3 to increase the length of the AS_PATH attribute by prepending AS 109 twice in the list. route-map AS_PREPEND sequence 10 has a match clause that makes sure that only 131.108.1.0/24 gets this prepended AS_PATH, and sequence 20 ensures that the rest of the prefixes from R1 to R3 remain unchanged. Access lists 1 and 2 are defined to achieve that. After this configuration, R3 has two updates for prefix 131.108.1.0/24, one from R2 and another from R1 with the prepended AS_PATH. R2 just has a single update from R1. Example 14-8 shows the output for R3 and R2. Example 14-8 show ip bgp Output from R3 and R2 After AS_PATH Manipulation in R1R3#show ip bgp 131.108.1.0 BGP routing table entry for 131.108.1.0/24, version 5 Paths: (2 available, best #2) Not advertised to any peer 109 109 109 1.1.2.1 from 1.1.2.1 (10.1.1.1) Origin IGP, metric 0, localpref 100, valid, external 109 1.1.7.1 from 1.1.8.2 (10.0.0.5) Origin IGP, metric 0, localpref 100, valid, internal, best _____________________________________________________________________________________ R2#show ip bgp 131.108.1.0 BGP routing table entry for 131.108.1.0/24, version 6 Paths: (1 available, best #1) Advertised to non peer-group peers: 1.1.8.3 109 1.1.7.1 from 1.1.7.1 (10.1.1.1) Origin IGP, metric 0, localpref 100, valid, external, best For prefix 131.108.1.0/24, the AS_PATH field looks like the following in R2 and R3:
Because in R3 the AS_PATH length of an update from R1 is (3) and from R2 is (1), R3 picks the path from R2 over the path from R1. This way, all traffic from AS 110 destined for 131.108.1.0/24 in AS 109 would exit through R2. R2 has only one path for 131.108.1.0/24, whereas R3 has two. This is because R2 is advertising its best route to all its IBGP neighbors (R3, R4, and R5, in this example). R3's best path for 131.108.1.0/24 is from R2, so R3 does not advertise its best path back to R2 because it originally came from R2. The AS_PATH prepend technique to influence incoming traffic is used in cases when AS 110 does not honor MEDs from AS 109, or when AS 109 is dual homed to different ISPs. Typically, Enterprise BGP networks use the AS_PATH prepend technique with their ISPs because the number of prefixes that they advertise are small and can be easily managed, as showed in Example 14-7. In ISP networks in which the number of prefixes is in the magnitude of thousands, managing AS_PATH per prefix does not scale well; therefore, ISPs rely on LOCAL_PREF, MED, and WEIGHT to manage their traffic. ISP might use AS_PATH prepend in packets to solve temporary problems but typically does not deploy this as a standard, widely used policy. By observing the AS_PATH, a BGP speaker can find out which AS originated the prefix and how many autonomous systems this prefix has traversed. The right-most AS is the originator of the prefix and the left-most is the neighboring AS that has announced the prefix. The middle autonomous systems in the AS_PATH are the intermediate autonomous systems that the prefix has traversed. Such an order of AS_PATH is called an AS_SEQUENCE, in which AS_PATH sequence is in the order that it has maintained . Another form of AS_PATH attribute, AS_SET, can be explained if AS 110 aggregates routes learned from AS 109 and other autonomous systems and announces a prefix that contains all the listings of autonomous systems, but the order of AS_PATH is not maintained. For example, AS 110 is aggregating 131.108.1.0/24 and 131.108.2.0/24 to 131.108.8.0/26 and advertised to AS 111. The /24s were learned from AS 109 and AS 108. AS 110 might choose to configure AS_PATH as AS_SET. Such an AS_PATH might look like this: The order of AS 108 and AS 109 is not preserved. AS_SEQUENCE is the default behavior of BGP, whereas AS_SET is a configurable option in Cisco IOS Software. NEXT_HOP AttributeThe IP address of the border router should be used as a next hop to reach prefixes propagated by that border router. This could be an IP address that belongs in the same AS or it could be an external IP address that shares the same subnet as that on a border router. NEXT_HOP is typically learned through an Interior Gateway Protocol (IGP), such as OSPF or IS-IS, and the cost to reach the NEXT_HOP often plays an important rule in calculating the best path. Referring back to Figure 14-16, in AS 110, the NEXT_HOP for 131.108.1.0/24 is the IP address of the R1 subnet that connects to R2. The NEXT_HOP attribute is not changed throughout the AS. Cisco IOS allows the user to change the NEXT_HOP to be the IP address of an internal border router instead of an external address, such as Loopback of R2. This is done by using the neighbor IBGP-Neighbor-IP-address next-hop-self command in BGP. By changing NEXT_HOP from an external address to the loopback, routers carry one less subnet in the routing table. Because loopback IP addresses are carried in IGP, no additional work is needed to propagate the NEXT_HOP. ORIGIN AttributeThe originator of the BGP update generates the ORIGIN attribute and defines how the original path was originated. Each prefix has an ORIGIN attribute. Routers, which receive updates with the ORIGIN attribute, should forward the ORIGIN attribute to all BGP neighbors unchanged. Table 14-1 describes the meaning of the different ORIGIN attribute codes and explains how these prefixes were originated. Table 14-1. ORIGIN Attribute Codes
WEIGHT: Cisco Systems, Inc. Proprietary AttributeWEIGHT is a 4-byte integer number and is not a BGP attribute because it is not defined in RFC 1771. It is a Cisco Systems, Inc. proprietary attribute that has priority over all other BGP attributes when doing the best-path calculation in Cisco IOS Software. WEIGHT is not shared with any BGP neighbor because it has local significance in the router and because the neighboring router might not understand Cisco's proprietary attribute. Because WEIGHT has local significance in the router, it does not affect neighboring routers' BGP policy, as in the case of LOCAL_PREF and MED that gets shared among other routers in the AS, and all the AS is affected when using those attributes. Figure 14-17 explains the use of WEIGHT. AS 109 has three exit points and connects to three different ISPs. AS 109 has low-bandwidth links in its Core, so therefore AS 109 would like to have BGP policy that makes minimal use of the Core. This can happen if each exit router chooses all the prefixes from its corresponding connected ISP as the best route. In Cisco IOS Software, if R1, R2, and R3 assign WEIGHT to all the prefixes learned from ISP1, ISP2, and ISP3, respectively, R1, R2, and R3 choose ISP1, ISP2, and ISP3, respectively, for all Internet routes. Traffic originated from the source connected to R1 always exits through ISP1, as shown in Figure 14-17. This way, the core of AS 109 never carries any Internet traffic unless a BGP session with an ISP fails anywhere . Figure 14-17. Usage WEIGHT to Avoid Using the IBGP Core Such BGP policy is also called hot Potato routing, as defined in the introductory portion of the chapter. Referring back to the network topology in Figure 14-13, AS 110 decided on a BGP policy stating that R3 should use R3 ‚ R1 link to reach 131.108.1.0/24 advertised by R1. Any policy change in R2 (LOCAL_PREF and so forth) should not affect R3 policy. The easiest way to accomplish this is to assign WEIGHT in R3 on the prefix 131.108.1.0/24 received from R1. Example 14-9 shows the configuration needed in R3 to assign WEIGHT. Example 14-9 Sample Configuration of R3 to Assign WEIGHTR3# router bgp 110 no synchronization neighbor 1.1.2.1 remote-as 109 neighbor 1.1.2.1 route-map SET_WEIGHT in neighbor 1.1.8.2 remote-as 110 route-map SET_WEIGHT permit 10 match ip address 1 set weight 2000 ! route-map SET_WEIGHT permit 20 match ip address 2 access-list 1 permit 131.108.1.0 access-list 2 permit any 1.1.2.1 is the IP address of R1 in AS 109. SET_WEIGHT is the route map that is applied on an EBGP session with R1. The route map usage is defined in detail in Chapter 1. The first sequence of route-map 10 has a match statement against access-list 1, which permits 131.108.1.0/24. The set command configures the WEIGHT to 2000 for prefixes that pass access-list 1. The second sequence of the route map is necessary to allow all other prefixes from this neighbor without changing the WEIGHT. Example 14-10 shows the output from R3 after setting the WEIGHT. Example 14-10 WEIGHT Assignment Shown in BGP OutputR3#show ip bgp 131.108.1.0 BGP routing table entry for 131.108.1.0/24, version 11 Paths: (2 available, best #1) Advertised to non peer-group peers: 1.1.8.2 109 1.1.2.1 from 1.1.2.1 (10.1.1.1) Origin IGP, metric 20 , localpref 100, weight 2000 , valid, external, best 109 1.1.7.1 from 1.1.8.2 (10.0.0.5) Origin IGP, metric 10 , localpref 100, valid, internal R3 has two paths for 131.108.1.0/24, one from R1 and the other from R2. Even though the path from R2 has a MED of 10, R3 prefers the path from R1 because of the WEIGHT assignment. In best-path calculation, WEIGHT has the highest priority over all other attributes. With WEIGHT, R3 uses the R1 ‚ R3 link for traffic destined to 131.108.1.0/24 from R3. The rest of AS 110 follows BGP policy defined in other routers to determine the path to reach 131.108.1.0/24. Reading BGP Attributes from Cisco IOS Software OutputThis section demonstrates how BGP attributes are read from the outputs of show commands in the Cisco IOS Software. Example 14-11 shows the sample output of a BGP prefix received from an EBGP peer. Example 14-11 is from route-server.cerf.net. Example 14-11 BGP Update from an EBGP Peershow ip bgp 3.0.0.0 1740 701 80 192.41.177.69 from 192.41.177.69 (134.24.127.131) Origin IGP , metric 20 , localpref 100 , valid, external , best Table 14-2 lists the BGP attributes shown in Example 14-11. Table 14-2. Explanation of BGP Attributes in Example 14-11
AS_PATH, [1740 701 80], means that prefix 3.0.0.0 was advertised by AS 80. Then it was advertised to AS 701, and, from 701, it came to 1740 and was given to the AS where this output is displayed. AS_PATH shows the AS this prefix has traversed. LOCAL_PREF 100 means that no LOCAL_PREFERENCE was sent in the update or LOCAL_PREF is set to 100 on this router. Cisco IOS Software uses a predefined LOCAL_PREF of 100 for a missing LOCAL_PREF. A MED of 20 means that neighbor 192.41.177.69 configured its BGP policy to send the MED of 20. Example 14-12 shows sample output of a BGP prefix received from an IBGP peer. Example 14-12 is from MAE-West Looking Glass of InterMedia . Example 14-12 BGP Update from an IBGP Peershow ip bgp 198.133.219.0 1 109 4.24.7.77 ( metric 90200 ) from 165.117.1.127 (165.117.1.127) Origin IGP , metric 40 , localpref 100 , valid, internal , best Community: 1:1000 2548:183 2548:234 2548:666 3706:153 Table 14-3 lists the BGP attributes shown in Example 14-12. Table 14-3. Explanation of BGP Attributes in Example 14-12
AS_PATH [1 109] means that prefix 198.133.219.0 was advertised by AS 109. Then it was advertised to AS 1 and was given to the AS where this output is displayed. AS_PATH shows the autonomous systems this prefix has traversed. LOCAL_PREF 100 means that no LOCAL_PREFERENCE was sent in the UPDATE. Cisco IOS uses a predefined LOCAL_PREF of 100 for a missing LOCAL_PREF. A MED of 40 means that either the IBGP neighbor 165.117.1.127 or the EBGP neighbor 4.24.7.77 of 165.117.1.127 configured its BGP policy to send the MED of 40. Later in this chapter, communities are discussed. Use of Route Maps in Policy ControlRoute maps are used extensively in BGP when it comes to managing policies. The route map might contain match and set statements. The match statement matches a specific value, such as an IP prefix. The set statement changes BGP attributes. The route map feature is mainly used with one of the following statements: aggregate, neighbor, network, or redistribute. Example 14-13 demonstrates a sample route map. Example 14-13 Sample Route Map Used for Policy Controlrouter bgp 2 neighbor A remote-as 1 neighbor A route-map test out route-map test permit 10 match ip address 1 set metric 20 ! route-map test permit 20 match ip address 2 access-list 1 permit 131.108.1.0 access-list 2 permit any The match ip address 1 statement examines access list 1, which allows only the prefix 131.108.1.0/24 to go to the set metric 20 command. The remaining prefixes go through without any additional modification in the route-map test permit 20 statement, which examines access-list 2, which permits all prefixes and sets no attribute. The following sections explain and demonstrate the most common match and set statement in route maps when used with BGP. Using the match ip address Command in a Route MapView the different options available for the match ip address command by entering the following: match ip address ? 1-199 IP access-list number 1300-2699 IP access-list number (expanded range) WORD IP access-list name prefix-list Match entries of prefix-lists Example 14-14 demonstrates applying the match ip address statement to a route map. Example 14-14 Using the match ip address Statement in a Route Maproute-map test permit 10 match ip address 1 access-list 1 permit 131.108.1.0 Using the match community Command in a Route MapWhen prefixes contain communities, you should use a route map with the match community command to examine the prefix that has the communities configured. View the different options available for the match community command by entering the following: match community ? 1-99 Community-list number (standard) 100-199 Community-list number (extended) exact-match Do exact matching of communities Example 14-15 demonstrates applying the match community statement to a route map. Example 14-15 Using the match community Statement in a Route Maproute-map test permit 10 match community 1 ip community-list 1 permit 1:1 match community 1 means that it will examine community-list filter 1, which permits prefixes that have community 1:1 configured. Later, this chapter describes communities in depth. Using the match as-path Command in a Route MapThe AS_PATH attribute in the BGP table is viewed as a text string; therefore, UNIX-like regular expressions can examine the beginning, end, or middle content of the string. AS_PATH filters are commonly used on Internet routers running BGP. Instead of listing each prefix in an access list, you can configure Cisco IOS Software to match against all the prefixes that came in from AS 109. Similarly, AS_PATH filter can be configured to pass only prefixes that have an AS_PATH equal to 109. View the different options available for the match as-path command by entering the following: match as-path ? 1-199 AS path access-list Example 14-16 demonstrates applying the match as-path statement to a route map. Example 14-16 Using the match as-path Statement in a Route Maproute-map test permit 10 match as-path 1 ip as-path access-list 1 permit ^109$ Here, as-path access-list 1 permits all prefixes that have the AS_PATH field equal to 109. All other prefixes are denied . Usage of regular expression is powerful and complex. You are encouraged to read the Cisco IOS Software documentation before using regular expressions in your access lists. Table 14-4 explains some commonly used regular expressions and their usage. Table 14-4. Common Regular Expressions in Access Lists
Earlier, set commands were used to manipulate BGP attributes. This section shows a few more examples of the use of the set command. set commands may or may not be used with a match statement in the route map. When set is used with match statements, only prefixes that pass the match statement are applied with set commands. A set command without a match means an unconditional set for all the prefixes. Using the set as-path prepend Command in a Route Mapset as-path prepend is used when the AS_PATH attribute is changed. This command prepends the AS number(s) listed in the SET command. Usage of AS_PATH prepends is discussed in detail earlier. View the different options available for the set as-path prepend command by entering the following: set as-path prepend ? 1-65535 AS number Using the set community Command in a Route MapCommunities are assigned to prefixes using the set community command in the route map. A match statement before set community assigns communities only to prefixes that pass the match. Without the match statement, all prefixes will be assigned with communities configured. View the different options available for the set community command by entering the following: set community ? 1-4294967295 community number aa:nn community number in aa:nn format additive Add to the existing community local-AS Do not send outside local AS (well-known community) no-advertise Do not advertise to any peer (well-known community) no-export Do not export to next AS (well-known community) none No community attribute Using the set local-preference Command in a Route MapView the different options available for the set local-preference command by entering the following: set local-preference ? 0-4294967295 Preference value Using the set metric Command in a Route MapView the different options available for the set metric command by entering the following: set metric ? +/- metric Add or subtract metric 0-4294967295 Metric value or Bandwidth in Kbits per second Using the set weight Command in a Route MapView the different options available for the set weight command by entering the following: set weight ? 0-4294967295 Weight value Policy Control Using filter-list , distribute-list, prefix-list, Communities, and Outbound Route Filtering (ORF)Cisco IOS Software offers powerful configuration tools for managing advertising and receiving prefixes in BGP. Network operators running BGP must have configuration options to filter what comes in and what goes out in BGP updates from their network. The following sections discuss the capabilities offered by Cisco IOS Software to control BGP prefixes in a scalable manner by using filter lists, distribute lists, prefix lists, communities, and ORF. Use of Filter Lists in Policy ControlFilter lists permit or deny BGP updates based on the AS_PATH attribute. Filter lists are used per the neighbor statement inbound, outbound, or both. Example 14-17 demonstrates configuring a filter list for policy control. Example 14-17 Configuring a Filter Listrouter bgp 110 neighbor 131.108.10.1 remote-as 109 neighbor 131.108.10.1 filter-list 1 in ip as-path access-list 1 permit ^109$ The ip as-path statement uses UNIX-like regular expressions, and it is examined against the AS_PATH attribute in the BGP update. In this example, all incoming updates from neighbor 131.108.10.1 are examined against as-path 1, which is configured to permit updates with the AS_PATH attribute equal to 109. AS_PATH filters are scalable because, for example, ^109$ covers all the prefixes and avoids an otherwise lengthy access list, which would involve listing all the prefixes. Use of Distribute Lists in Policy ControlLike filter lists, distribute lists are used per neighbor statement inbound, outbound, or both. They operate on IP access lists. In distribute lists, prefixes are permitted or denied based on the networks listed in the access list. Example 14-18 makes use of standard IP access list 1 used with a distribute list. In standard access lists, a router makes the filtering decision based on the prefix network, not based on its mask. Extended access lists enable not only network filtering, but also filtering based on the mask of the prefix. Example 14-18 Using Distribute Lists in a Standard IP Access ListR2# router bgp 110 neighbor 131.108.10.1 remote-as 109 neighbor 131.108.10.1 distribute-list 1 in access-list 1 permit 131.108.1.0 0.0.0.255 Example 14-18 uses standard IP access-list 1 with a distribute list configured for neighbor 131.108.10.1 inbound. All prefixes that this neighbor advertises to R2 are checked against access-list 1, which permits network 131.108.1.0. This network could have a mask of /24, /25, and so on because the standard access list offers no checking for a mask. Example 14-19 makes use of extended IP access lists. Example 14-19 Using Distribute Lists in an Extended IP Access Listrouter bgp 110 neighbor 131.108.10.1 remote-as 109 neighbor 131.108.10.1 distribute-list 101 in access-list 101 permit ip 131.108.1.0 0.0.0.0 255.255.255.0 0.0.0.0 In standard access lists (1 to 99), the wildcard mask can be applied only on the prefix, not on its mask, whereas, in extended access lists, the subnet mask of the BGP update also can be checked against the access list. When used in BGP for filtering as in this example, the syntax of extended access lists has a different meaning. Extended access lists, when used in interface packet filtering, have a source address portion and a destination address portion. When extended access lists are used with BGP distribute lists, the source address portion is the network number and the destination portion is the mask of that network. Therefore, for access-list 101, when used in BGP, the distribute list can also be read as follows:
access-list 101 in Example 14-19 permits 131.108.1.0 only with the mask of 255.255.255.0. Refer to Chapter 1 or the Cisco IOS Software documentation for a more in-depth explanation of standard and extended access lists. Use of Prefix Lists in Policy ControlPrefix lists replace distribute lists because they offer user-friendly configuration options when filtering based on IP prefixes. Instead of writing difficult prefix wildcard and mask wildcard combinations in an extended access list applied in a distribute list, prefix lists use a configuration that is easy to read and comprehend. Example 14-20 shows a sample configuration substitution for the configuration in Example 14-19, but it uses a prefix list instead of a distribute list. Example 14-19 had access-list 101 that permitted 131.108.1.0/24 only. Example 14-20 uses prefix-list to achieve that. Example 14-20 Sample Configuration to Show How Prefix Lists WorkR2#: router bgp 110 neighbor 131.108.10.1 remote-as 109 neighbor 131.108.10.1 prefix-list FILTER1 in ip prefix-list FILTER1 seq 1 permit 131.108.1.0/24 NOTE Prefix-list also has an implicit deny at the end, like distribute-list and AS_PATH list. In Example 14-20, FILTER1 is the name of the prefix list that is applied on the neighbor 131.108.10.1 on all the incoming BGP updates. prefix-list FILTER1 operation will be done in sequential ascending order; the smallest sequence number will be examined first. seq 1 permits 131.108.1.0/24. The prefix list certainly offers a simpler, yet powerful, method to achieve what distribute lists once offered. Use of Communities in Policy ControlRFC 1997 defines the BGP COMMUNITIES attribute, which describes a community as "a group of destinations which share some common property." A community is a 32-bit number that is assigned to a prefix by configuration and that is propagated to all neighbors in a BGP update. A prefix can be assigned with multiple communities, with a maximum of 255 different communities per prefix. BGP operators can group networks into communities. For example, all networks in the east region of an internetwork are assigned a community, and the networks in the west region of an internetwork are assigned a different community. Thus, community numbers act as a tag for each prefix. By looking at the community in BGP output, it becomes easy to distinguish east region prefixes from west region prefixes. Communities can be represented in two ways in Cisco IOS Software. Conventional style is a plain 32-bit number; newer style uses the format AS:nn, where AS is the autonomous system and nn is a 2-byte number. The newer format can be used after ip bgp new-format under the bgp subcommand. Figure 14-18 shows how sets of prefixes are grouped in certain communities. BGP attribute manipulation is often done on a per-community basis. Figure 14-18. Network to Show How Prefixes Are Grouped into Communities for Easier Operation in the Receiver In Figure 14-18, AS 109 and 110 are configured with EBGP. In AS 109, 131.108.1.0/24 and 131.108.2.0/24 belong to community 109:1, and 131.108.3.0/24 and 131.108.4.0/24 belong to community 109:2. Example 14-21 shows a sample configuration in R1, which assigns communities. Assume that R1 can originate 131.108.1.0/24, 131.108.2.0/24, 131.108.3.0/24, and 131.108.4.0/24. Example 14-21 Sample Configuration to Assign Communities per PrefixR1# router bgp 109 network 131.108.1.0 mask 255.255.255.0 network 131.108.2.0 mask 255.255.255.0 network 131.108.3.0 mask 255.255.255.0 network 131.108.4.0 mask 255.255.255.0 neighbor 131.108.6.2 remote-as 110 neighbor 131.108.6.2 send-community neighbor 131.108.6.2 route-map SET_COMMUNITY out ip bgp-community new-format access-list 1 permit 131.108.2.0 access-list 1 permit 131.108.1.0 access-list 2 permit 131.108.4.0 access-list 2 permit 131.108.3.0 route-map SET_COMMUNITY permit 10 match ip address 1 set community 109:1 ! route-map SET_COMMUNITY permit 20 match ip address 2 set community 109:2 R1 has configured route-map SET_COMMUNITY and applied it to neighbor 131.108.6.2 for all the outbound BGP updates that R1 advertises to R2. route-map SET_COMMUNITY has a match clause in each sequence that matches against the access list. If the prefix is per-mitted in the access list, it is assigned a community based on which access list it is permitted by. In Example 14-21, 131.108.2.0/24 is permitted by access-list 1, so it will be assigned with community 109:1. Similarly, 131.108.4.0/24 gets community 109:2. R2 receives these updates with communities and might be configured to assign LOCAL_PREF based on the communities. R2 might assign LOCAL_PREF based on individual prefix, but it would be difficult to manage if the number of prefixes grows to several thousand. Example 14-22 shows the sample configuration of R2, which assigns a LOCAL_PREF value of 200 for prefixes that belong to community 109:1, and assigns a LOCAL_PREF value of 50 for prefixes that belong to community 109:2. Example 14-22 Sample Configuration to Show Community Filter Usage in Configuring BGP PolicyR2# router bgp 110 neighbor 131.108.6.1 remote-as 109 neighbor 131.108.6.1 route-map SET_LOCAL_PREF in neighbor 131.108.6.1 send-community ip bgp-community new-format ip community-list 1 permit 109:1 ip community-list 2 permit 109:2 route-map SET_LOCAL_PREF permit 10 match community 1 set local-preference 200 ! route-map SET_LOCAL_PREF permit 20 match community 2 set local-preference 50 Route maps are configured to match against community list filters 1 and 2 that look for these communities in BGP updates. If the community is found in the update, the set operation is performed. Example 14-23 shows the BGP table for R2. All prefixes that belong to community 109:1 are assigned a LOCAL_PREF value of 200. Prefixes with community 109:2 are assigned a LOCAL_PREF value of 50. Example 14-23 Router R2 BGP Table Reflects LOCAL_PREF Assignment Along with CommunitiesR2# show ip bgp 131.108.1.0 BGP routing table entry for 131.108.1.0/24, version 4 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 109 131.108.6.1 from 131.108.6.1 (131.108.10.1) Origin IGP, metric 0, localpref 200 , valid, external, best Community: 109:1 R2# show ip bgp 131.108.3.0 BGP routing table entry for 131.108.3.0/24, version 2 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 109 131.108.6.1 from 131.108.6.1 (131.108.10.1) Origin IGP, metric 0, localpref 50 , valid, external, best Community: 109:2 The LOCAL_PREF assignment and community is listed for each prefix. Community usage gives a scalable way to manage the BGP prefix in a large BGP network. BGP policies can be configured based on a single community number that might represent thousands of prefixes. For example, Router R1 in the east region of a large network wants to assign LOCAL_PREF of 200 to all prefixes of west region routes. If west region routers assign a certain community number to all their prefixes when advertising to the east region, Router R1 will simply assign LOCAL_PREF in a route map by matching against a community that east region has set. Router R1 could have made a huge access list to permit each prefix and accomplish the same result, but, using community matching, R1 accomplished it in a scalable fashion. Not only are communities used in BGP policy control, but they also aid in troubleshooting BGP network problems. Customer BGP prefixes can be assigned with distinct and different communities from peering ISP prefixes. If a customer prefix is having an issue, just looking at the distinct community can isolate customer prefixes, and troubleshooting can be done faster. Such benefits make community usage common in BGP networks. Use of Outbound Route Filtering in Policy ControlThe document draft-chen-bgp-prefix-orf-00.txt defines the functionality of exchanging prefix list-based outbound route filter (ORF) capability. When configured with ORF, one router pushes its inbound prefix list to ORF-capable BGP neighbors. Upon receipt, the pushed prefix list is automatically configured as the outbound prefix list. Typically, when routers must deny certain prefixes from other routers, they use filter lists, distribute lists, prefix lists, and so on as inbound filters. The receiver denies the prefix after the sender has sent that prefix. ORF offers a dynamic way in which the receiver advertises its inbound filter to the sender; the sender then installs that filter on its outbound neighbor relationship to the receiver. When a neighbor relationship is formed between two routers, they exchange ORF capability that verifies whether both routers are ORF-capable. Only when both agree can the ORF feature be used. Figure 14-19 shows how BGP speakers make use of ORF. The bold numbers indicate the sequence of events in ORF, defined in the list following the figure. Figure 14-19. Outbound Route Filter (ORF) Operations
In Figure 14-19, R2 is originating 131.108.2.0/24 and 131.108.3.0/24. R1 wants to deny 131.108.2.0/24 and receive everything else. Without ORF, R1 must configure an inbound prefix list that will deny 131.108.2.0/24. Without ORF, this is achieved at the expense of receiving the update and then filtering it, thus wasting lots of resources, such as CPU processing in R2 to advertise the prefixes, link bandwidth to carry the updates that will be dropped at R1, and CPU processing in R1 to filter those updates. ORF sends an inbound prefix list filter to the neighbor. After receiving this prefix list, the neighbor applies it as an outbound prefix list. All updates then must pass by the prefix list, saving extra computation at the receiver. Example 14-24 shows how R1 can send its inbound prefix list ABC to R2. Example 14-24 Sample Configuration to Show How ORF Can Be UsedR1: router bgp 109 bgp log-neighbor-changes neighbor 131.108.6.2 remote-as 110 neighbor 131.108.6.2 ebgp-multihop 2 neighbor 131.108.6.2 capability orf prefix-list both neighbor 131.108.6.2 prefix-list ABC in ! ip prefix-list ABC seq 5 deny 131.108.2.0/24 ip prefix-list ABC seq 10 permit 0.0.0.0/0 le 32 R1#clear ip bgp 131.108.6.2 in prefix-filter R1#show ip bgp BGP table version is 2, local router ID is 1.1.1.1 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 131.108.3.0/24 131.108.6.2 0 0 110 I The neighbor 131.108.6.2 capability orf prefix-filter both enables ORF capability in R1 with the BGP neighbor, and this capability indicates that the R1 is willing to accept or send a prefix list with the neighbor R2. The neighbor 131.108.6.2 prefix-list ABC in command means that R1 has configured an inbound prefix list ABC for R2, which simply denies 131.108.2.0/24 and permits all other prefixes. The clear ip bgp 131.108.6.2 in prefix-filter in R1 pushes its inbound prefix list filter to R2. The show ip bgp command shows that R1 is only receiving 131.108.3.0/24 as R2 has accepted prefix-list ABC that denies 131.108.2.0/24. Example 14-25 shows the necessary configuration of R2 to accept the ORF from R1 configured in Example 14-24. Example 14-25 Sample Configuration of R2 to Accept ORF from R1R2: router bgp 110 network 131.108.2.0 mask 255.255.255.0 network 131.108.3.0 mask 255.255.255.0 neighbor 131.108.6.1 remote-as 109 neighbor 131.108.6.1 ebgp-multihop 2 neighbor 131.108.6.1 capability orf prefix-list both R2#show ip bgp BGP table version is 3, local router ID is 2.2.2.2 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP, ? - incomplete Network Next Hop Metric LocPrf Weight Path *> 131.108.2.0/24 0.0.0.0 0 32768 i *> 131.108.3.0/24 0.0.0.0 0 32768 I R2#show ip bgp neighbors 131.108.6.1 received prefix-filter Address family: IPv4 Unicast ip prefix-list 131.108.6.1: 2 entries seq 5 deny 131.108.2.0/24 seq 10 permit 0.0.0.0/0 le 32 The neighbor 131.108.6.1 capability orf prefix-list both command enables ORF capability in R2 with the BGP neighbor, and this capability indicates that the R2 is willing to accept or send a prefix list with the neighbor R1. The two show commands in R2 indicate that R2 is advertising the two prefixes and R2 has received the prefix list from R1 that denies 131.108.2.0/24 and permits everything else. When R2 accepts the prefix-list ABC, it installs it as an outbound prefix-list, resulting in denial of 131.108.2.0/24 and permitting 131.108.3.0/24. R2 has the option to overwrite received prefix-filter with its own. ORF is a powerful mechanism to install inbound prefix lists on the remote end, thus avoiding unnecessary routing updates on the link and saving receiver CPU time to process those updates and deny them. Route DampeningRoute dampening is the feature that reduces propagation of flapping routes in the Internet. Route flapping occurs when IP routes are removed and put back in a routing table. This can be because of physical layer failure, routing protocol failure, or router node failure, and so on. When these flaps are announced through BGP to the Internet, all of Internet routers running BGP are affected, as they have to remove and install such flapping routes. In an unstable internal network where IP routes continuously flaps, this instability is propagated through BGP throughout the Internet. Route dampening is the feature that minimizes this instability by assigning a penalty to such flapping routes. When the penalty reaches a predefined limit (suppress limit), that route is removed from the routing table and is not advertised to Internet. When the route stops flapping, the penalty decreases exponentially. When the penalty is reduced to a predefined limit (reuse limit), that route is installed again and propagated through BGP. Some of the rules and definitions regarding route dampening are as follows:
In Cisco IOS Software, dampening is configured as shown in Example 14-26. Example 14-26 Configuration of Dampening in Cisco IOS SoftwareR3# router bgp 110 bgp dampening With this configuration, the half-life, reuse limit, suppress limit, and maximum suppress time will get defaults of 15 min, 750, 2000, and 1 hour, respectively. These values can be changed with the configuration shown in Example 14-27. Example 14-27 Configuration to Change Dampening Parametersrouter bgp 110 bgp dampening 1 400 2000 4 In Example 14-27, the half-life is 1, reuse limit is 400, suppress limit is 2000, and the maximum suppress time is 4 times the half-life, so routes will be suppressed for a maximum of 4 minutes. The example that follows demonstrates how dampening works and what sequence of events the Cisco router goes through when routes are flapped. In a simple network, R1 and R3 are running EBGP. R1 is advertising 131.108.1.0/24 to R3. Example 14-28 shows the sequence of events when R3 has dampening enabled and R1 is flapping 131.108.1.0/24. R3 is running following debugs to observe the sequence of events. NOTE Debugs should be run carefully as excessive debug output can influence router performance. Example 14-28 Route Dampening ExampleR3# debug ip bgp updates 1 debug ip bgp dampening 1 access-list 1 permit 131.108.1.0 0.0.0.0 _____________________________________________________________________________________ ! First Sequence: R1 has withdrawn 131.108.1./24 R3# Jul 7:20:33.151 MDT: BGP: 1.1.2.1 rcv UPDATE about 131.108.1.0/24 withdrawn 24 1 .Jul 4 17:20:33.151 MDT: BGP: charge penalty for 131.108.1.0/24 path 109 2 with halflife-time 15 reuse/suppress 750/2000 .Jul 24 17:20:33.151 MDT: flapped 1 times since 00:00:00. New penalty is 1000 R3 #show ip bgp 131.108.1.0 BGP routing table entry for 131.108.1.0/24, version 3 Paths: (1 available, no best path) Flag: 0x88 Not advertised to any peer 109 (history entry) 1.1.2.1 from 1.1.2.1 (10.1.1.1) Origin IGP, metric 20, localpref 100, external Dampinfo: penalty 1000, flapped 1 times in 00:00:04 _____________________________________________________________________________________ ! Second Sequence: R1 announces 131.108.1.0/24 to R3. R3# Jul 24 17:21:01.214 MDT: BGP: 1.1.2.1 rcv UPDATE about 131.108.1.0/24 R3 #show ip bgp 131.108.1.0 BGP routing table entry for 131.108.1.0/24, version 4 Paths: (1 available, best #1) Flag: 0x88 Not advertised to any peer 109 1.1.2.1 from 1.1.2.1 (10.1.1.1) Origin IGP, metric 20, localpref 100, valid, external, best Dampinfo: penalty 972, flapped 1 times in 00:00:39 _____________________________________________________________________________________ ! Third Sequence: R1 has again withdrawn 131.108.1./24 R3# Jul 24 17:21:31.882 MDT: BGP: 1.1.2.1 rcv UPDATE about 131.108.1.0/24 -- withdrawn .Jul 24 17:21:31.882 MDT: BGP: charge penalty for 131.108.1.0/24 path 109 with halflife-time 15 reuse/suppress 750/2000 .Jul 24 17:21:31.882 MDT: flapped 2 times since 00:00:58. New penalty is 1960 R3 # show ip bgp 131.108.1.0 BGP routing table entry for 131.108.1.0/24, version 5 Paths: (1 available, no best path) Flag: 0x88 Not advertised to any peer 109 (history entry) 1.1.2.1 from 1.1.2.1 (10.1.1.1) Origin IGP, metric 20, localpref 100, external Dampinfo: penalty 1937, flapped 2 times in 00:01:17 _____________________________________________________________________________________ ! Fourth Sequence: R1 announces 131.108.1.0/24 to BR3. . Jul 24 17:22:13.706 MDT: BGP: 1.1.2.1 rcv UPDATE about 131.108.1.0/24 R3 # show ip bgp 131.108.1.0 BGP routing table entry for 131.108.1.0/24, version 6 Paths: (1 available, best #1) Flag: 0x88 Not advertised to any peer 109 1.1.2.1 from 1.1.2.1 (10.1.1.1) Origin IGP, metric 20, localpref 100, valid, external, best Dampinfo: penalty 1891, flapped 2 times in 00:01:52 R3#show ip route 131.108.1.0 Routing entry for 131.108.1.0/24 Known via "bgp 110", distance 20, metric 20 Tag 109, type external Last update from 1.1.2.1 00:00:13 ago Routing Descriptor Blocks: * 1.1.2.1, from 1.1.2.1, 00:00:13 ago Route metric is 20, traffic share count is 1 AS Hops 1, BGP network version 0 _____________________________________________________________________________________ Fifth Sequence: R1 has again withdrawn 131.108.1./24 R3# Jul 24 17:22:40.781 MDT: BGP: 1.1.2.1 rcv UPDATE about 131.108.1.0/24 withdrawn Jul 24 17:22:40.781 MDT: BGP: charge penalty for 131.108.1.0/24 path 109 with halflife-time 15 reuse/suppress 750/2000 .Jul 24 17:22:40.781 MDT: flapped 3 times since 00:02:07. New penalty is 2869 R3 # show ip bgp 131.108.1.0 BGP routing table entry for 131.108.1.0/24, version 7 Paths: (1 available, no best path) Not advertised to any peer 109, (suppressed due to dampening) 1.1.2.1 from 1.1.2.1 (10.1.1.1) Origin IGP, metric 20, localpref 100, valid, external Dampinfo: penalty 2802, flapped 3 times in 00:02:44, reuse in 00:28:30 R3 # show ip route 131.108.1.0 % Network not in table The significant events in the five sequences in Example 14-28 are as follows:
Dampening is commonly used because it offers a dynamic way to penalize flapping and unstable routes. |
| ‚ < ‚ Free Open Study ‚ > ‚ |
EAN: 2147483647
Pages: 260