BGP-4 Aggregation
The following examples demonstrate different methods of aggregation that are seen on the Internet. The way aggregates are formed and advertised and whether they carry with them more-specific routes will influence traffic patterns and sizes of BGP routing tables. Remember that aggregation applies to routes that exist in the BGP routing table. An aggregate can be sent if at least one more-specific route of that aggregate exists in the BGP table.
Aggregate Only, Suppressing the More-Specific
This section shows how an aggregate can be generated without propagating any of the more-specific routes that fall under the aggregate. In the network illustrated in Figure 11-10, RTA is sending prefixes 172.16.220.0/24, 172.16.1.0/24, 172.16.10.0/24, and 172.16.65.0/26 toward RTC.
Figure 11-10. BGP Aggregation (Suppressing the Specific Routes)
The configuration in Example 11-51 shows how RTA can aggregate all these routes into a single prefix 172.16.0.0/16 and send it to RTC. This of course assumes that AS3 is the sole owner of the class B 172.16.0.0/16. RTF is also doing the same aggregation on its end with a configuration similar to RTA.
Example 11-51. RTA Configuration: Aggregating Routes into a Single Prefix to Send to RTC
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 172.16.0.0 255.255.0.0 summary-only 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 no auto-summary ip as-path access-list 10 permit ^$ |
RTA's configuration uses the aggregate-address command to aggregate all the more-specific routes of 172.16.0.0/16 into a single address.
RTA's BGP table (shown in Example 11-52) indicates that a new aggregate 172.16.0.0/16 has been originated by this router (NEXT_HOP is 0.0.0.0), whereas all the more-specific prefixes have been suppressed (note the s at the far left). In this case, the same result could have been achieved by using auto-summarization.
Example 11-52. RTA BGP Table
RTA#show ip bgp
BGP table version is 14, local router ID is 172.16.2.254
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.0.0 0.0.0.0 32768 i
* i 172.16.1.2 100 0 i
s> 172.16.1.0/24 0.0.0.0 0 32768 i
s> 172.16.10.0/24 172.16.1.2 20 32768 i
s> 172.16.65.0/26 172.16.1.2 20 32768 i
s> 172.16.220.0/24 0.0.0.0 0 32768 i
* 192.68.10.0 172.16.20.1 0 1 2 i
*>i 172.16.1.2 0 100 0 2 i
*> 192.68.11.0 172.16.20.1 0 0 1 i
|
The output of RTC's BGP table in Example 11-53 shows that the only prefix that was learned from RTA is the aggregate 172.16.0.0/16. Because RTF is also performing the same aggregation, RTC will also learn an aggregate that is originated from RTF (next hop RTD via AS2).
Example 11-53. RTC BGP Table
RTC#show ip bgp
BGP table version is 22, local router ID is 192.68.11.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
*> 172.16.0.0 172.16.20.2 0 3 i
* 192.68.6.1 0 2 3 i
*> 192.68.10.0 192.68.6.1 0 0 2 i
*> 192.68.11.0 0.0.0.0 0 32768 i
|
Looking at the specific 172.16.0.0/16 aggregate entry, Example 11-54 provides more information about the aggregate itself.
Example 11-54. RTC BGP Output
RTC#show ip bgp 172.16.0.0
BGP routing table entry for 172.16.0.0/16, version 22
Paths: (2 available, best #1, advertised over EBGP)
3, (aggregated by 3 172.16.2.254)
172.16.20.2 from 172.16.20.2 (172.16.2.254)
Origin IGP, valid, external, atomic-aggregate, best
2 3, (aggregated by 3 192.68.5.1)
192.68.6.1 from 192.68.6.1 (192.68.10.1)
Origin IGP, valid, external, atomic-aggregate
|
Note the presence of the ATOMIC_AGGREGATE attribute, which indicates that the prefix 172.16.0.0/16 is an aggregate. Also note the presence of the aggregated by 3 172.16.2.254 and aggregated by 3 192.68.5.1 statements, which represent the AGGREGATOR attribute. The AGGREGATOR attribute (discussed in Chapter 6) indicates the AS number and ROUTER_ID of the router that originated the aggregate—in this case, AS3 and the ROUTER_IDs of RTA and RTF.
Aggregates can also be generated by using static routes, as demonstrated by the configuration for RTA in Example 11-55 and the configuration for RTF in Example 11-56.
Example 11-55. Generating Aggregates Using Static Routes: RTA Configuration
router bgp 3 no synchronization network 172.16.0.0 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 no auto-summary ip route 172.16.0.0 255.255.0.0 null0 ip as-path access-list 10 permit ^$ |
Example 11-56. Generating Aggregates Using Static Routes: RTF Configuration
router bgp 3 no synchronization network 172.16.0.0 neighbor 172.16.2.254 remote-as 3 neighbor 172.16.2.254 next-hop-self neighbor 192.68.5.2 remote-as 2 neighbor 192.68.5.2 filter-list 10 out no auto-summary ip route 172.16.0.0 255.255.0.0 null0 ip as-path access-list 10 permit ^$ |
The configuration in Example 11-55 and Example 11-56 places a static instance of 172.16.0.0/16 in the routing table. Note that the static entry is pointing to null0 (bit bucket). If RTA or RTF has no knowledge of the more-specific routes of 172.16.0.0, traffic will be dropped. This is to prevent loops in case RTA or RTF is following defaults to its provider (see "Classless Interdomain Routing (CIDR)" in Chapter 3, "IP Addressing and Allocation Techniques").
Aggregate Plus More-Specific Routes
In some cases, more-specific routes, in addition to the aggregate, need to be passed (leaked) to a neighboring AS. This is usually done in ASs multihomed to a single provider. An AS (the provider) that gets the more-specific routes would be able to make a better decision about which way to reach the route. (You have already seen how an AS receiving different metrics can direct the traffic accordingly.) Figure 11-11 illustrates the topology for this scenario.
Figure 11-11. More BGP Scenarios
In Figure 11-11, AS3 is multihomed to a single provider, AS1. Through the configurations in Example 11-57 and Example 11-58, RTA and RTF in AS3 can send the aggregate 172.16.0.0/16 and the more-specific routes toward AS1.
Example 11-57. Multihoming to a Single Provider: 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 172.16.0.0 255.255.0.0 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 no auto-summary ip as-path access-list 10 permit ^$ |
Example 11-58. Multihoming to a Single Provider: RTF 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 172.16.0.0 255.255.0.0 neighbor 172.16.2.254 remote-as 3 neighbor 172.16.2.254 next-hop-self neighbor 192.68.5.2 remote-as 1 neighbor 192.68.5.2 filter-list 10 out no auto-summary ip as-path access-list 10 permit ^$ |
Note that the aggregate-address command in both the RTA and RTF configurations does not include the summary-only parameter, so both the aggregate and specific routes will be advertised.
RTC's BGP table, shown in Example 11-59, shows that RTC has learned the aggregate 172.16.0.0/16 in addition to the more-specific routes. RTD will also receive the same information.
Example 11-59. Multihoming to a Single Provider: RTC BGP Table
RTC#show ip bgp
BGP table version is 28, local router ID is 192.68.11.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
* i172.16.0.0 192.68.6.1 100 0 3 i
*> 172.16.20.2 0 3 i
* i172.16.1.0/24 192.68.6.1 0 100 0 3 i
*> 172.16.20.2 0 0 3 i
* i172.16.10.0/24 192.68.6.1 0 100 0 3 i
*> 172.16.20.2 20 0 3 i
* i172.16.65.0/26 192.68.6.1 0 100 0 3 i
*> 172.16.20.2 20 0 3 i
* i172.16.220.0/24 192.68.6.1 20 100 0 3 i
*> 172.16.20.2 0 0 3 i
*>i192.68.10.0 192.68.6.1 0 100 0 i
*> 192.68.11.0 0.0.0.0 0 32768 i
|
Using the community no-export attribute, RTA and RTF can instruct RTC and RTD not to export the more-specific routes and to send only the aggregate 172.16.0.0/16 toward AS4. This is very useful in controlling routing table expansion, assuming that AS4 can get by using the aggregate route only. Example 11-60 shows the required configuration on RTF to accomplish this; RTA will have the same relative configuration.
Example 11-60. Suppressing the Export of Specific Routes: RTF 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 172.16.0.0 255.255.0.0 neighbor 172.16.2.254 remote-as 3 neighbor 172.16.2.254 next-hop-self neighbor 192.68.5.2 remote-as 1 neighbor 192.68.5.2 send-community neighbor 192.68.5.2 route-map SETCOMMUNITY out neighbor 192.68.5.2 filter-list 10 out no auto-summary ip as-path access-list 10 permit ^$ access-list 101 permit ip 172.16.0.0 0.0.255.255 host 255.255.0.0 route-map SETCOMMUNITY permit 10 match ip address 101 route-map SETCOMMUNITY permit 20 set community no-export |
In Example 11-60, RTF will use multiple instances of route-map SETCOMMUNITY to assign the more-specific routes 172.16.1.0/24, 172.16.220.0/24, 172.16.10.0/24, and 172.16.65.0/26 to community no-export, which instructs RTD not to send these routes to exterior ASs such as AS4. On the other hand, the aggregate itself, 172.16.0.0/16, is passed unmodified without any community and will be sent to AS4.
Instance 10 of the route map uses access list 101, which matches on the aggregate 172.16.0.0/16 only. Note how the host 255.255.0.0 part of the access list makes sure that no other entry that starts with 172.16 matches by explicitly specifying the mask to be exactly 255.255.0.0 and nothing else. Instance 10 does not set any community values; hence, the aggregate will be passed as is.
Instance 20 will ensure that all the more-specific routes will have a community no-export.
Example 11-61 and Example 11-62 show the required configurations for RTC and RTD.
Example 11-61. RTC Configuration
router bgp 1 no synchronization network 192.68.11.0 neighbor 172.16.20.2 remote-as 3 neighbor 192.68.6.1 remote-as 1 neighbor 192.68.6.1 next-hop-self neighbor 192.68.6.1 send-community no auto-summary |
Example 11-62. RTD Configuration
router bgp 1 no synchronization network 192.68.10.0 neighbor 192.68.5.1 remote-as 3 neighbor 192.68.6.2 remote-as 1 neighbor 192.68.6.2 next-hop-self neighbor 192.68.10.2 remote-as 4 no auto-summary |
Note the send-community neighbor parameter in RTC's configuration in Example 11-61. Because RTA is also performing the same aggregation, RTD will receive the specific routes from its IBGP session with RTC. If RTC does not propagate the no-export community to RTD, RTD will advertise the specific routes to external peers.
Example 11-63 shows selected entries in RTD's BGP table. The first entry indicates that prefix 172.16.220.0/24 is not advertised to EBGP peers. This is because RTA and RTF have tagged this prefix (and all other "specific" routes) with a community value of no-export. The second entry indicates that the aggregate itself has been originated by RTA and RTF as is. The aggregate will be passed on to AS4.
Example 11-63. RTD BGP Output
RTD#show ip bgp 172.16.220.0 BGP routing table entry for 172.16.220.0/24, version 5 Paths: (2 available, best #2, not advertised to EBGP peer) 3 192.68.5.1 from 192.68.5.1 Origin IGP, metric 20, valid, external Community: no-export 3 192.68.6.2 from 192.68.6.2 (192.68.11.1) Origin IGP, metric 0, localpref 100, valid, internal, best Community: no-export RTD#show ip bgp 172.16.0.0 BGP routing table entry for 172.16.0.0/16, version 8 Paths: (2 available, best #1, advertised over IBGP, EBGP) 3, (aggregated by 3 192.68.5.1) 192.68.5.1 from 192.68.5.1 Origin IGP, valid, external, atomic-aggregate, best 3, (aggregated by 3 172.16.2.254) 192.68.6.2 from 192.68.6.2 (192.68.11.1) Origin IGP, localpref 100, valid, internal, atomic-aggregate |
Looking at RTG's BGP table in Example 11-64, you will note that only the aggregate 172.16.0.0/16 has been propagated from AS3 to AS4. All the more-specific routes do not show up.
Example 11-64. RTG BGP Routing Table
RTG#show ip bgp
BGP table version is 14, local router ID is 192.68.10.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.0.0 192.68.10.1 0 1 3 i
*> 192.68.10.0 192.68.10.1 0 0 1 i
*> 192.68.11.0 192.68.10.1 0 1 i
|
Aggregate with a Subset of the More-Specific Routes
Figure 11-12 shows how AS3 can utilize a combination of aggregation and more-specific routes to influence what link AS1 uses to reach AS3's networks.
Figure 11-12. BGP Aggregates with a Subset of Specific Routes
RTA will send over its direct link to AS1 the aggregate 172.16.0.0/16 plus the more-specific routes 172.16.1.0/24, 172.16.10.0/24, and 172.16.65.0/26. RTF will send over its direct link to AS3 the aggregate 172.16.0.0/16 plus the more-specific route 172.16.220.0/24 only. As a result, AS1 is forced to reach 172.16.220.0/24 via RTF and all the other routes in AS3 via RTA.
The suppress map is another form of route map that can be used to indicate the more-specific routes to be suppressed or the more-specific routes to be allowed. When a route is permitted through the suppress map, the route is suppressed. If the route is not permitted (denied), the route is not suppressed—in other words, it is allowed. Note that the deny logic here does not prevent the route from being advertised; rather, it prevents it from being suppressed. Example 11-65 demonstrates the use of a suppress map.
Example 11-65. Using a BGP Suppress Map
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 172.16.0.0 255.255.0.0 suppress-map SUPPRESS 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 no auto-summary ip as-path access-list 10 permit ^$ access-list 1 permit 172.16.220.0 0.0.0.255 access-list 1 deny any route-map SUPPRESS permit 10 match ip address 1 |
RTA's configuration uses a suppress map called SUPPRESS that will prevent 172.16.220.0/24 from being advertised and will enable all other routes. As a result, RTA will announce the aggregate 172.16.0.0/16, plus the more-specific routes 172.16.1.0/24, 172.16.10.0/24, and 172.16.65.0/26. Example 11-66 shows RTA's BGP table. Again, notice how the suppressed entries have the s at the far left.
Example 11-66. RTA's BGP Table
RTA#show ip bgp
BGP table version is 17, local router ID is 172.16.2.254
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
* i172.16.0.0 172.16.1.2 100 0 i
*> 0.0.0.0 32768 i
*> 172.16.1.0/24 0.0.0.0 0 32768 i
*> 172.16.10.0/24 172.16.1.2 20 32768 i
*> 172.16.65.0/26 172.16.1.2 20 32768 i
s> 172.16.220.0/24 0.0.0.0 0 32768 i
* i192.68.10.0 172.16.1.2 0 100 0 1 i
*> 172.16.20.1 0 1 i
* i192.68.11.0 172.16.1.2 0 100 0 1 i
*> 172.16.20.1 0 0 1 i
|
On the other hand, RTF will use a similar logic to advertise the aggregate, plus the more-specific route 172.16.220.0/24. Example 11-67 shows the configuration for RTF.
Example 11-67. RTF 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 172.16.0.0 255.255.0.0 suppress-map ALLOW neighbor 172.16.2.254 remote-as 3 neighbor 172.16.2.254 next-hop-self neighbor 192.68.5.2 remote-as 1 neighbor 192.68.5.2 filter-list 10 out no auto-summary ip as-path access-list 10 permit ^$ access-list 1 deny 172.16.220.0 0.0.0.255 access-list 1 permit any route-map ALLOW permit 10 match ip address 1 |
RTF's configuration in Example 11-67 includes a suppress map called ALLOW that allows the prefix 172.16.220.0/24 and suppresses everything else. As a result, AS1 will be forced to use RTF to reach 172.16.220.0/24. The naming of the suppress maps SUPPRESS and ALLOW reflects the main function of the route map. In RTA's configuration, it made more sense to suppress a specific entry and allow the rest because the number of routes to be allowed is large. In RTF's configuration, it made sense to allow a specific entry and suppress the rest because the number of routes to be suppressed is large.
The RTF configuration in Example 11-67 allows the aggregate 172.16.0.0/16 and the more-specific route 172.16.220.0/24 to be advertised; all other more-specific routes will be suppressed. Example 11-68 shows RTF's BGP table.
Example 11-68. RTF BGP Table
RTF#show ip bgp
BGP table version is 17, local router ID is 192.68.5.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
*> 172.16.0.0 0.0.0.0 32768 i
* i 172.16.2.254 100 0 i
s> 172.16.1.0/24 0.0.0.0 0 32768 i
s i 172.16.2.254 0 100 0 i
s> 172.16.10.0/24 0.0.0.0 0 32768 i
s i 172.16.2.254 20 100 0 i
s> 172.16.65.0/26 0.0.0.0 0 32768 i
s i 172.16.2.254 20 100 0 i
*> 172.16.220.0/24 172.16.1.1 20 32768 i
*> 192.68.10.0 192.68.5.2 0 0 1 i
* i 172.16.20.1 100 0 1 i
*> 192.68.11.0 192.68.5.2 0 1 i
* i 172.16.20.1 100 0 1 i
|
Given the preceding configuration of RTA and RTF in Example 11-65 and Example 11-67, AS1 will be able to reach 172.16.220.0/24 only via the RTD-RTF link and 172.16.1.0/24, 172.16.65.0/26, and 172.16.10.0/24 via the RTC-RTA link. This is illustrated in RTD's BGP table, shown in Example 11-69.
Example 11-69. RTD's BGP Table
RTD#show ip bgp
BGP table version is 19, local router ID is 192.68.10.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
* i172.16.0.0 192.68.6.2 100 0 3 i
*> 192.68.5.1 0 3 i
*>i172.16.1.0/24 192.68.6.2 0 100 0 3 i
*>i172.16.10.0/24 192.68.6.2 20 100 0 3 i
*>i172.16.65.0/26 192.68.6.2 20 100 0 3 i
*> 172.16.220.0/24 192.68.5.1 20 0 3 i
*> 192.68.10.0 0.0.0.0 0 32768 i
*>i192.68.11.0 192.68.6.2 0 100 0 i
|
RTD has only one choice to reach 172.16.220.0/24, and that is via the RTD-RTF link. In case of link failure, the aggregate is still advertised via both links, and the route will follow the aggregate.
In certain situations, administrators require that some neighbors receive some of the specific routes already suppressed. Suppression could have been done via the summary-only parameter or the neighbor command. In this case, Cisco provides a different form of route map called an unsuppress map that is applied on a per-neighbor basis. The unsuppress map allows previously suppressed routes to be advertised. For example, if you wanted RTA to prevent 172.16.220.0/24 from being suppressed toward 172.16.1.2 (RTF), you would use the RTA router configuration shown in Example 11-70.
Example 11-70. RTA Configuration
neighbor 172.16.1.2 unsuppress-map AllowSpecifics route-map AllowSpecifics permit 10 match ip address 1 access-list 1 permit 172.16.220.0 0.0.0.255 |
The configuration in Example 11-70 allows the advertisement of prefix 172.16.220.0/24 toward RTF.
Loss of Information Inside Aggregates
Aggregation causes loss of granularity. The detailed information that exists in the specific prefixes will be lost when summarized in the form of aggregates. The purpose of an AS_SET is to attempt to preserve the attributes carried in the specific routes in a mathematical SET that gives a better idea of the elements of the aggregate. Figure 11-13 illustrates the network topology for this scenario.
Figure 11-13. Dealing with Loss of Information with Aggregates
In Figure 11-13, RTA is aggregating prefixes 192.68.10.0/24 and 192.68.11.0/24 coming from AS2 and AS1, respectively. Without AS_SET, the aggregate 192.68.0.0/16 will be considered as having originated from AS3 and will lose all the specific attribute information that the individual prefixes 192.68.10.0/24 and 192.68.11.0/24 have. You will see two configuration possibilities for RTA—first without AS_SET (Example 11-71) and then with AS_SET (Example 11-73). You will see how the aggregate 192.68.0.0/16 will look in both scenarios.
Example 11-71. RTA Configuration Without AS_SET
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 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 ^$ |
The BGP table for RTK in Example 11-72 shows how the aggregate 192.68.0.0/16 will look when it is received by RTK. Note that the aggregate has lost the individual path information because the AS_PATH consists of AS number 3 only.
Example 11-72. RTK BGP Table
RTK#show ip bgp
BGP table version is 8, 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 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
|
Using the AS_SET concept demonstrated in the configuration in Example 11-73, the aggregate will be sent out from RTA with a SET of the path information.
Example 11-73. RTA Configuration with AS_SET
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 ^$ |
In the BGP routing table for RTK in Example 11-74, notice how the aggregate 192.68.0.0/16 changes to include a SET {2,1} within its path information. This indicates that the aggregate actually summarizes routes that have passed via ASs 1 or 2. The AS_SET information becomes important in avoiding routing loops because it keeps an indication of where the route has been.
Example 11-74. RTK BGP Table
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 the 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 or hundreds of routes, the aggregate will be constantly oscillating if the routes forming the aggregate are unstable.
Changing the Aggregate's Attributes
In some situations, changing the aggregate's attributes is required. The example in this section shows one scenario in which this could be useful.
As you have already seen, 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, the aggregate itself will carry the same attribute. This will prevent the aggregate from being exported. To remedy this situation, you can modify the community attribute of the aggregate by using what Cisco calls an attribute map, another form of a route map that applies only to aggregates.
In the network depicted in Figure 11-13, RTC tags 192.68.11.0/24 with a community value of no-export. If RTA aggregates 192.68.11.0/24 into 192.68.0.0/16 using AS_SET, the aggregate itself will also contain the no-export community. Example 11-75 and Example 11-76 show the configurations of RTC and RTA, which are needed to achieve this behavior.
Example 11-75. 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 |
Example 11-76. 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 performing 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). Notice how the BGP table for RTA, shown in Example 11-77, indicates that 192.68.0.0/16 is not to be advertised to EBGP peers.
Example 11-77. RTA BGP Output
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, you can manipulate the aggregate attributes. In this example, you can set the community to "none" and allow the aggregate to be advertised to EBGP peers. The configuration for RTA in Example 11-78 defines an attribute map called SET_ATTRIBUTE that sets the community attribute of the aggregate to none.
Example 11-78. 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 |
Notice how the BGP table in Example 11-79 shows that the aggregate 192.68.0.0/16 is now being advertised to EBGP peers.
Example 11-79. RTA BGP Output
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
|
Forming the Aggregate Based on a Subset of Specific Routes
Having control over which individual prefixes form the aggregate is very useful in determining which attributes the aggregate will carry. In the previous section, if you could exclude prefix 192.68.11.0/24 from being part of the prefixes that form the aggregate, the aggregate would not inherit the no-export community attribute.
The advertise map is yet another form of a route map that lets you form the aggregated route based on a limited selection of the more-specific routes. Figure 11-14 illustrates the network topology for this scenario.
Figure 11-14. Aggregation with Advertise Maps
In Figure 11-14, RTA and RTF are getting routes 192.68.11.0/24 and 192.68.10.0/24 from ASs 1 and 2, respectively. If RTA and RTF are to aggregate these routes into 192.68.0.0/16 using the as-set option, the aggregate cannot be sent back to either AS1 or AS2, because it contains {1 2} in the AS path. This is due to the normal BGP behavior in detecting loops.
Assume that the required behavior is to have the aggregate 192.68.0.0/16 sent back to AS1 and not to AS2. The solution is to have AS1 not be part of the aggregate's AS_PATH; then, AS1 will not drop the aggregate. This could be achieved by having RTA and RTF form the aggregate based on the 192.68.10.0/24 prefix only, using the advertise-map option.
To accomplish this, you would configure RTA as shown in Example 11-80. RTF would have the same relative configuration.
Example 11-80. 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 advertise-map SELECT_MORE_SPECIF_ROUTES 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 no auto-summary ip as-path access-list 10 permit ^$ access-list 1 permit 192.68.10.0 0.0.0.255 route-map SELECT_MORE_SPECIF_ROUTES permit 10 match ip address 1 |
By permitting prefix 192.68.10.0/24, the advertise map causes RTA to base its aggregate calculation on 192.68.10.0/24 only. Thus, 192.68.11.0/24 is not included in the formation of the aggregate.
The show ip bgp command output in Example 11-81 illustrates that the aggregate's path information is now 2 and not {1 2}. This means that the aggregate can now be advertised to AS1 because the AS_PATH does not include AS1. AS2 will not be able to receive the aggregate.
Example 11-81. RTA BGP Output
RTA#show ip bgp 192.68.0.0
BGP routing table entry for 192.68.0.0 255.255.0.0, version 31
Paths: (2 available, best #2, advertised over IBGP)
2 (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 (aggregated by 3 172.16.2.254)
0.0.0.0
Origin IGP, localpref 100, weight 32768, valid, aggregated,
local, atomic-aggregate, best
|