BGP4 Aggregation

One of BGP4's main improvements over BGP3 and BGP2 is its capability to handle CIDR and supernetting. CIDR and supernetting were first discussed in Chapter 3, "Handling IP Address Depletion," with respect to controlling the growth of IP forwarding tables and the depletion of the IP address space.

Aggregation applies to routes that exist in the BGP routing table. This is in contrast to the network command, discussed earlier in this chapter, and which applies to routes that exist in the IP routing table. Aggregation can be performed if at least one more specific route of the aggregate exists in the BGP routing table.

Cisco Systems offers a variety of ways of manipulating aggregates to make sure that every need on the Internet is fulfilled. This section first examines simple aggregation techniques and then moves on to more complicated (but fun) scenarios.

Aggregate Only, Suppressing the More Specific

This scenario illustrates a case where an aggregate is advertised and all its specific routes are suppressed. This is usually done when the more specific routes do not offer any extra benefits, such as making better decisions in forwarding traffic. Figure 5-28 illustrates a situation in which all the routing updates are lumped into a single aggregate. Suppose that AS100 has the subnet ranges 172.16.0.0/24 to 172.16.15.0/24. This includes 172.16.0.X, 172.16.1.X, and so on. The list of specific attributes can be summarized into the range 172.16.0.0/20. The aggregate 172.16.0.0/20 is sent out, and all the more specific routes are suppressed.

Figure 5-28  BGP4 aggregation example suppression specific routes.

---

Troubleshooting:  
Example: Ch. 10, pp. 343-346. Aggregate Only, Suppressing the More Specific

---

Aggregate Plus More Specific Routes

A number of situations exist in which an AS will send out an aggregate and its more specific routes. This usually occurs in situations where the customer is multihomed to a single provider. The provider would use the more specific routes to make better decisions when sending traffic toward the customer. At the same time, the provider can propagate the aggregate only toward the NAP to minimize the number of routes leaked to the Internet. This is illustrated in figure 5-29.

Figure 5-29  BGP4 aggregation including specific routes.

---

Troubleshooting:  
Example: Ch. 10, pp. 346-352. Aggregate Plus More Specific Route

---

AS100 is multihomed with provider AS200 via the San Francisco and New York links. AS100 can send AS200 either the aggregate 172.16.0.0/20 only, or it can send the aggregate and all the more specific routes. If the aggregate only is sent over both the SF and NY links, then traffic from AS200 toward AS100 will always take one link or the other. This arrangement creates an unbalanced traffic load (balanced loading is discussed further in Chapter 6, "Redundancy, Symmetry, and Load Balancing"). To balance the load, AS100 sends the aggregate and all the more specific routes. Different metrics could be sent for different routes on each of the links. This way, based on the specific network number, AS200 can decide whether to use the SF or NY link when trying to reach AS100.

To avoid complicating routing tables beyond the provider level, more specific routes from customers are usually stopped at the provider level. AS200 would propagate only the aggregate 172.16.0.0/20 toward the NAP and suppress the more specific routes.

Usually providers like to minimize configuration and administration. In this situation, a dynamic approach can be used to stop all the more specific routes from being propagated to the NAP. This is done by having AS100 tag all the more specific updates with the community attribute NO-EXPORT while leaving the aggregate as is. This is illustrated in figure 5-30.

Figure 5-30  Community no-export route aggregation example.

When AS200 gets the updates from AS100, it will recognize the community as a request not to forward the updates to its external peers. The aggregate will be propagated as usual to the NAP and other peers.

Aggregate with a Subset of the More Specific Routes

In some situations, a subset of the more specific routes needs to be advertised in addition to the aggregate. Figure 5-31 illustrates a situation in which this might be useful.

Figure 5-31  Aggregation example including subset of specific routes.

In figure 5-31, AS100 is multihomed to AS200. AS100 would like the networks in the vicinity of SF to be accessed via the SF link and the networks in the vicinity of NY to be accessed via the NY link. This could be achieved in the following manner:

•  On the SF link, advertise the aggregate and the SF networks only.

•  On the NY link, advertise the aggregate and the NY networks only.

---

Troubleshooting:  
Example: Ch. 10, pp. 352-356. Aggregate with a Subset of the More Specific Routes

---

In this case, AS200 can only reach the SF networks via the SF link and the NY networks via the NY link. Networks in other locations could be sent on both links or either link. In case of a link failure, all networks can still be reached by following the aggregate route, which is advertised on both links. The no-export technique, discussed in the previous example, can be used to propagate only the aggregate to the NAP.

Loss of Information Inside Aggregates (AS-SET)

Aggregation causes loss of information due to the fact that the attributes of individual routes that form the aggregate will be lost. As already discussed in this chapter, BGP defines an AS-SET, which is a mathematical set consisting of all elements contained in all paths that are being summarized. An example of such elements are the AS_path and community attributes.

---

Troubleshooting:  
Example: Ch. 10, pp. 356-359. Loss of Information Inside Aggregates (AS-SET)

---

Using AS-SET with the aggregate will cause additional route instabilities due to the fact that changes in the attributes of the individual routes being summarized will now translate into changes of the aggregate itself and will cause the aggregate to be constantly withdrawn and updated.