1-1 aggregate-address address mask

1-1 aggregate-address address mask

Syntax Description:

• address ” Aggregate IP address.

• mask ” Aggregate mask.

Purpose: To create an aggregate entry in the BGP table. An aggregate is created only if a more-specific route of the aggregate exists in the BGP table. This form of the aggregate- address command advertises the aggregate and all the more-specific routes that are part of the aggregate.

Cisco IOS Software Release: 10.0

Configuration Example 1: Aggregating Local Routes

For this example, we will aggregate locally sourced routes. In Figure 1-1, Router B aggregates the four networks 172.16.0.x through 172.16.3.x.

Figure 1-1. Aggregating Locally Sourced Routes

 Router A  router bgp 1   neighbor 10.1.1.2 remote-as 2   __________________________________________________________________________  Router B  interface loopback 0   ip address 172.16.0.1 255.255.255.0   !   interface loopback 1   ip address 172.16.1.1 255.255.255.0   !   interface loopback 2   ip address 172.16.2.1 255.255.255.0   !   interface loopback 3   ip address 172.16.3.1 255.255.255.0   !   router bgp 2   network 172.16.0.0 mask 255.255.255.0   network 172.16.1.0 mask 255.255.255.0   network 172.16.2.0 mask 255.255.255.0   network 172.16.3.0 mask 255.255.255.0   neighbor 10.1.1.1 remote-as 1   !  

Four loopbacks have been created on Router B to simulate the locally sourced routes that will be aggregated. A BGP router can advertise an aggregate only if at least one specific route of the aggregate is in the BGP table. The BGP network commands are necessary on Router B in order to place more-specific routes of the aggregate into the BGP table. Before aggregating the loopback prefixes, verify that the specific routes are in the BGP tables on Routers A and B:

 rtrA#  show ip bgp  BGP table version is 16, local router ID is 172.17.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 *> 172.16.0.0/24    10.1.1.2                 0             0 2 i *> 172.16.1.0/24    10.1.1.2                 0             0 2 i *> 172.16.2.0/24    10.1.1.2                 0             0 2 i *> 172.16.3.0/24    10.1.1.2                 0             0 2 i  ___________________________________________________________________________  rtrB#  show ip  bgp  BGP table version is 6, local router ID is 172.16.3.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/24    0.0.0.0                  0         32768 i *> 172.16.1.0/24    0.0.0.0                  0         32768 i *> 172.16.2.0/24    0.0.0.0                  0         32768 i *> 172.16.3.0/24    0.0.0.0                  0         32768 i 

Now modify the BGP configuration on Router B to enable the advertisement of the aggregate:

 Router B  router bgp 2   network 172.16.0.0 mask 255.255.255.0   network 172.16.1.0 mask 255.255.255.0   network 172.16.2.0 mask 255.255.255.0   network 172.16.3.0 mask 255.255.255.0    aggregate-address 172.16.0.0 255.255.252.0    neighbor 10.1.1.1 remote-as 1  

The configuration for Router B contains a network command for every prefix that is part of the aggregate. Because we need only one more-specific route in the BGP table in order to generate the prefix, we could have used only one network command. The problem with using only one network command is that if the network goes down, the more-specific route is withdrawn from the BGP table. If the only specific route in the BGP table is withdrawn, the aggregate is withdrawn as well. By using a network command for every prefix that is contained in the aggregate, the aggregate is advertised as long as one of the more-specific routes is up.

Verification

Verify that the aggregate address is in both the Router A and B BGP tables:

 rtrA#  show ip bgp  BGP table version is 18, local router ID is 172.17.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 *> 172.16.0.0/24    10.1.1.2                 0             0 2 i  *> 172.16.0.0/22    10.1.1.2                               0 2 i  *> 172.16.1.0/24    10.1.1.2                 0             0 2 i *> 172.16.2.0/24    10.1.1.2                 0             0 2 i *> 172.16.3.0/24    10.1.1.2                 0             0 2 I  ___________________________________________________________________________  rtrB#  show ip bgp  BGP table version is 8, local router ID is 172.16.3.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/24    0.0.0.0                  0         32768 i  *> 172.16.0.0/22    0.0.0.0                            32768 i  *> 172.16.1.0/24    0.0.0.0                  0         32768 i *> 172.16.2.0/24    0.0.0.0                  0         32768 i *> 172.16.3.0/24    0.0.0.0                  0         32768 i 

Examine the specific information for the aggregate on Router A:

 rtrA#  show ip bgp 172.16.0.0 255.255.252.0  BGP routing table entry for 172.16.0.0/22, version 18 Paths: (1 available, best #1, table Default-IP-Routing-Table)   Not advertised to any peer   2, (aggregated by 2 172.16.3.1)     10.1.1.2 from 10.1.1.2 (172.16.3.1)  Origin IGP, localpref 100, valid, external, atomic-aggregate, best  

Notice that the aggregate has the attribute atomic-aggregate. This indicates that the AS information for the aggregate has been lost. This does not pose any problems in this example, because the routes that comprise the aggregate and the aggregate itself originate on the same router. The next example more clearly illustrates the atomic aggregate attribute. Also notice that the aggregate for this example contains only the four prefixes 172.16.0.0/24 through 172.16.3.0/24. We could have used an aggregate with a shorter mask. For example, we could use a 16-bit mask when forming the aggregate on Router B, as shown in the following configuration. This is not recommended, though, because you are aggregating routes that might not belong to you.

 Router B  router bgp 2   network 172.16.0.0 mask 255.255.255.0   network 172.16.1.0 mask 255.255.255.0   network 172.16.2.0 mask 255.255.255.0   network 172.16.3.0 mask 255.255.255.0    aggregate-address 172.16.0.0 255.255.0.0    neighbor 10.1.1.1 remote-as 1  

Verify that the aggregate is being advertised:

 rtrB#  show ip bgp  BGP table version is 20, local router ID is 172.17.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 *> 172.16.0.0/24    10.1.1.2                 0             0 2 i  *> 172.16.0.0       10.1.1.2                               0 2 i  *> 172.16.1.0/24    10.1.1.2                 0             0 2 i *> 172.16.2.0/24    10.1.1.2                 0             0 2 i *> 172.16.3.0/24    10.1.1.2                 0             0 2 i 

Finally, examine the IP routing table on Router A:

 rtrA#  show ip route  Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2        E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default        U - per-user static route, o - ODR Gateway of last resort is not set      1.0.0.0/32 is subnetted, 1 subnets C       1.1.1.1 is directly connected, Loopback0      172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks  B       172.16.0.0/16 [200/0] via 0.0.0.0, 00:03:01, Null0  C       172.16.0.0/24 is directly connected, Loopback1 C       172.16.1.0/24 is directly connected, Loopback2 C       172.16.2.0/24 is directly connected, Loopback3 C       172.16.3.0/24 is directly connected, Loopback4      10.0.0.0/30 is subnetted, 1 subnets C       10.1.1.0 is directly connected, Serial0 

Notice that BGP automatically installs a route for the aggregate with a next hop of Null 0 into the IP routing table. Figure 1-2 illustrates the purpose of the route to Null 0.

Figure 1-2. Route to Null 0 Is Needed to Prevent Routing Loops

Assume that network 172.16.2.0/24 on Router B is down. Router B withdraws this route from the BGP table but still advertises the aggregate. Assume that Router B has a default route pointing to Router A and that there is no BGP route for 172.16.0.0/22 to Null 0 on Router B. When Router A receives an IP packet destined for 172.16.2.x, the packet is sent to Router B, because Router A has the aggregate 172.16.0.0/22 in its IP routing table. When Router B receives the packet, it inspects the IP routing table to determine how to route the packet. Because 172.16.2.0/24 is down, there is no route in the routing table. Router B sends the packet to the default route, which is toward Router A. When Router A receives the packet, it is sent back to B, and B sends it back to A. This process continues until the TTL in the IP packet goes to 0. With the Null 0 route for 172.16.0.0/22 on Router B, the packet is simply dropped if network 172.16.2.0/24 is down.

Configuration Example 2: Aggregating Redistributed Routes

Instead of using the network command to place the more-specific routes in the BGP table, we could simply redistribute the connected routes and then aggregate them, as in Example 1. Modify the BGP configuration on Router B using redistribution instead of the network command. The no auto-summary command is needed to prevent the router from generating a classful summary of the 172.16.0.0/16 network (see Chapter 2, "Auto-Summary," for more information):

 Router B  router bgp 2   aggregate-address 172.16.0.0 255.255.252.0    redistribute connected metric 20    neighbor 10.1.1.1 remote-as 1    no auto-summary   

Verification

Inspect the BGP tables on Routers A and B to verify that the summary is being advertised:

 rtrA#  show ip bgp  BGP table version is 18, local router ID is 172.16.3.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 *  10.1.1.0/30      10.1.1.1                20             0 1 ? *>                  0.0.0.0                 20           32768 ? *> 172.16.0.0/24    0.0.0.0                 20           32768 ?  *> 172.16.0.0/22    0.0.0.0                              32768 i  *> 172.16.1.0/24    0.0.0.0                 20           32768 ? *> 172.16.2.0/24    0.0.0.0                 20           32768 ? *> 172.16.3.0/24    0.0.0.0                 20           32768 ? 

Configuration Example 3: Aggregating BGP Learned Routes

In Figure 1-3, Router A is learning the prefixes 172.16.0.0/24 through 172.16.3.0/24 from Router B. Because these routes are now in the BGP table on Router A, Router A can aggregate them into the 172.16.0.0/22 prefix.

Figure 1-3. Aggregating BGP Learned Routes

 Router A  router bgp 1    aggregate-address 172.16.0.0 255.255.252.0    neighbor 10.1.1.2 remote-as 2   neighbor 172.17.1.2 remote-as 65530   ___________________________________________________________________________  Router B  interface loopback 0   ip address 172.16.0.1 255.255.255.0   !   interface loopback 1   ip address 172.16.1.1 255.255.255.0   !   interface loopback 2   ip address 172.16.2.1 255.255.255.0   !   interface loopback 3   ip address 172.16.3.1 255.255.255.0   !   router bgp 2   network 172.16.0.0 mask 255.255.255.0   network 172.16.1.0 mask 255.255.255.0   network 172.16.2.0 mask 255.255.255.0   network 172.16.3.0 mask 255.255.255.0   neighbor 10.1.1.1 remote-as 1   ________________________________________________________________________  Router C  router bgp 65530   neighbor 172.17.1.1 remote-as 1  

Verification

The BGP tables on Routers A and C should now contain the aggregate address:

 rtrA#  show ip bgp  BGP table version is 6, local router ID is 172.17.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 *> 172.16.0.0/24    10.1.1.2                 0             0 2 i  *> 172.16.0.0/22    0.0.0.0                              32768 i  *> 172.16.1.0/24    10.1.1.2                 0             0 2 i *> 172.16.2.0/24    10.1.1.2                 0             0 2 i *> 172.16.3.0/24    10.1.1.2                 0             0 2 I rtrC#  show ip bgp  BGP table version is 32, local router ID is 172.17.1.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/24    172.17.1.1                             0 1 2 i  *> 172.16.0.0/22    172.17.1.1                             0 1 i  *> 172.16.1.0/24    172.17.1.1                             0 1 2 i *> 172.16.2.0/24    172.17.1.1                             0 1 2 i *> 172.16.3.0/24    172.17.1.1                             0 1 2 i 

Notice that in the BGP table on Router C, the path information for the specific routes is different from the path for the aggregate route. Router A is forming the aggregate, so it looks as though Router A "owns" this route. If you check the specific route information for the aggregate on Router C in the following output, you can see that the route carries the atomic attribute, signifying that there has been a loss of AS path information:

 rtrC#  show ip bgp 172.16.0.0 255.255.252.0  BGP routing table entry for 172.16.0.0/22, version 28 Paths: (1 available, best #1)   Not advertised to any peer   1, (aggregated by 1 172.17.1.1)     172.17.1.1 from 172.17.1.1 (172.17.1.1)  Origin IGP, localpref 100, valid, external, atomic-aggregate, best, ref 2  

If you need to retain the AS path information for the aggregate, see section 1-3.

Configuration Example 4: Aggregating Using a Static Route

For the scenario in Figure 1-1, an aggregate could have been generated by creating a static route on Router B and then redistributing the static route into BGP:

 Router B  router bgp 2    redistribute static    neighbor 10.1.1.1 remote-as 1   no auto-summary   !    ip route 172.16.0.0 255.255.252.0 Null0   

Verification

Verify that the aggregate is being generated and advertised by checking the BGP tables on Routers A and B.

 rtrA#  show ip bgp  BGP table version is 18, local router ID is 172.17.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 *> 172.16.0.0/24    10.1.1.2                 0             0 2 i  *> 172.16.0.0/22    10.1.1.2                 0             0 2 ?  *> 172.16.1.0/24    10.1.1.2                 0             0 2 i *> 172.16.2.0/24    10.1.1.2                 0             0 2 i *> 172.16.3.0/24    10.1.1.2                 0             0 2 i  ________________________________________________________________________  rtrB#  show ip bgp  BGP table version is 6, local router ID is 172.16.3.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/24    0.0.0.0                  0         32768 i  *> 172.16.0.0/22    0.0.0.0                  0         32768 ?  *> 172.16.1.0/24    0.0.0.0                  0         32768 i *> 172.16.2.0/24    0.0.0.0                  0         32768 i *> 172.16.3.0/24    0.0.0.0                  0         32768 i 

Troubleshooting

Step 1. Verify that the BGP neighbors are in the Established state using the show ip bgp neighbors command.

If the neighbor relationship is not in the Established state, see section 8-23.

Step 2. Ensure that at least one specific route in the BGP table is contained in the range of addresses that you want to aggregate using the show ip bgp command.

Step 3. If at least one more-specific route is in the BGP table, go to Step 5.

Step 4. If at least one more-specific route is not in the BGP table, do the following:

- ” Check the syntax (address and mask) of your BGP network command. Go to Step 2.

- If you're redistributing routes (connected, static, or from an IGP), make sure you are using the no auto-summary command. Check the syntax of your redistribution command(s). Go to Step 2.

Step 5. Verify that no filters are blocking the aggregate from being advertised.