Internet Routing Architectures (CISCO):Configuring Basic BGP Functions and Attributes Previous Table of Contents Next In the following BGP routing table for RTK, note how the aggregate 192.68.0.0/16 changed to include a SET {2,1} within its path information. This indicates that the aggregate actually summarizes routes that have passed via ASs 1 and 2. The AS-SET information becomes important in avoiding routing loops because it keeps an indication of where the route has been. RTK#show ip bgp BGP table version is 12, local router ID is 172.16.220.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 *> 172.16.1.0/24 172.16.220.1 0 0 3 i *> 172.16.10.0/24 172.16.220.1 20 0 3 i *> 172.16.65.0/26 172.16.220.1 20 0 3 i *> 172.16.220.0/24 172.16.220.1 0 0 3 i *> 192.68.0.0/16 172.16.220.1 0 3 {2,1} i *> 192.68.10.0 172.16.220.1 0 3 2 i *> 192.68.11.0 172.16.220.1 0 3 1 i In case the aggregate reaches AS1 or AS2, BGP's loop detection behavior will note the set information and drop the aggregate. Given that the aggregate with the AS-SET contains information about each individual route that is summarized, changes in the individual route will cause the aggregate to be updated. In our example, if 192.68.11.0/24 goes down, the path information of the aggregate will change from 3 {2,1} to 3 2, and the aggregate will be updated. If the aggregate summarizes tens and hundreds of routes, the aggregate will be constantly flip-flopping if the routes forming the aggregate have problems. Changing the Attributes of the Aggregate In some situations, changing the attributes of the aggregate is required. This example shows one scenario where this could be useful. As you have seen already, the aggregate can carry information about its individual elements if configured with the AS-SET option. If one or more of the routes forming the AS-SET aggregate are configured with "no-export" community attribute, then the aggregate itself will carry the same attribute. This will prevent the aggregate from being exported. To remedy this situation, the community attribute of the aggregate can be modified by using what Cisco calls an "attribute-map," which is another form of a routemap that applies to aggregates only. In figure 10-13, RTC has set the community of 192.68.11.0/24 to "no-export." If RTA is aggregating 192.68.11.0/24 into 192.68.0.0/16 using AS-SET, the aggregate itself will also contain the "no-export" community. The following are the configurations of RTC and RTA, which are needed to achieve this behavior: RTC configuration: router bgp 1 network 192.68.11.0 neighbor 172.16.20.2 remote-as 3 neighbor 172.16.20.2 send-community neighbor 172.16.20.2 route-map SETCOMMUNITY out no auto-summary access-list 1 permit 192.68.11.0 0.0.0.255 route-map SETCOMMUNITY permit 10 match ip address 1 set community no-export route-map SETCOMMUNITY permit 20 RTA configuration: router bgp 3 no synchronization network 172.16.1.0 mask 255.255.255.0 network 172.16.10.0 mask 255.255.255.0 network 172.16.65.0 mask 255.255.255.192 network 172.16.220.0 mask 255.255.255.0 aggregate-address 192.68.0.0 255.255.0.0 as-set neighbor 172.16.1.2 remote-as 3 neighbor 172.16.1.2 update-source Loopback0 neighbor 172.16.20.1 remote-as 1 neighbor 172.16.20.1 filter-list 10 out neighbor 172.16.220.2 remote-as 5 no auto-summary ip as-path access-list 10 permit ^$ Because RTA is doing the aggregation using the AS-SET, the aggregate itself will contain all the elements that the individual routes have; in particular, the community "no-export" coming from prefix 192.68.11.0/24 (originated by RTC). Note how the following display indicates that 192.68.0.0/16 is not to be advertised to EBGP peers. RTA#show ip bgp 192.68.0.0 BGP routing table entry for 192.68.0.0 255.255.0.0, version 22 Paths: (2 available, best #2, not advertised to EBGP peer, advertised over IBGP) Local (aggregated by 3 192.68.5.1) 172.16.1.2 from 172.16.1.2 (192.68.5.1) Origin IGP, localpref 100, valid, internal, atomic-aggregate {2,1} (aggregated by 3 172.16.2.254) 0.0.0.0 Origin IGP, localpref 100, weight 32768, valid, aggregated, local, best Community: no-export By using the "attribute-map," we can manipulate the aggregate attributes. In this example, we can set the community to "none" and allow the aggregate to be advertised to EBGP peers. RTA configuration: router bgp 3 no synchronization network 172.16.1.0 mask 255.255.255.0 network 172.16.10.0 mask 255.255.255.0 network 172.16.65.0 mask 255.255.255.192 aggregate-address 192.68.0.0 255.255.0.0 as-set attribute-map SET_ATTRIBUTE neighbor 172.16.1.2 remote-as 3 neighbor 172.16.1.2 update-source Loopback0 neighbor 172.16.20.1 remote-as 1 neighbor 172.16.20.1 filter-list 10 out neighbor 172.16.220.2 remote-as 5 no auto-summary ip as-path access-list 10 permit ^$ route-map SET_ATTRIBUTE permit 10 set community none The preceding RTA configuration defines an "attribute-map" called SET_ATTRIBUTE that sets the community attribute of the aggregate to none. Note how the following display shows that the aggregate 192.68.0.0/16 is now being advertised to EBGP peers. RTA#show ip bgp 192.68.0.0 BGP routing table entry for 192.68.0.0 255.255.0.0, version 10 Paths: (2 available, best #2, advertised over IBGP, EBGP) Local (aggregated by 3 192.68.5.1) 172.16.1.2 from 172.16.1.2 (192.68.5.1) Origin IGP, localpref 100, valid, internal, atomic-aggregate {2,1} (aggregated by 3 172.16.2.254) 0.0.0.0 Origin IGP, localpref 100, weight 32768, valid, aggregated, local, best Previous Table of Contents Next