Changing the Attributes of the Aggregate

In some situations, it is required that the attributes of the aggregate be changed. One such situation is when the aggregate contains some unwanted attributes that it inherited from the routes it is summarizing (in case of AS-SET). An example could be a "NO-EXPORT" community attribute that the aggregate got from one of the more specific routes and that causes the aggregate not to be exported to other ASs. Another situation that calls for changing the attributes of the aggregate is to reflect a level of preference for a certain aggregate. An example would be of customer's advertising an aggregate via multiple links to a certain provider. The customer might like to have the aggregate go out with different MEDs on different links to influence the entrance point into the AS. Cisco has developed techniques to enable the user to modify the attributes of an aggregate accordingly.

---

Troubleshooting:  
Example: Ch. 10, pp. 360-362. Changing the Attributes of the Aggregate

---

Forming the Aggregate Based on a Subset of More Specific Routes

You have seen that with AS-SET the aggregate will contain a set of all attributes (including AS numbers) that exist in the individual routes being summarized. If the aggregate is summarizing routes that come from different ASs, it becomes useful to specify which routes are being included in forming the aggregate. This would help in a hub and spoke situation where each of the leaf ASs contains a separate subset of the aggregate that is originated by the hub. When forming the aggregate, the hub AS would exclude the more specific routes that belong to the leaf AS that needs to receive the aggregate. The aggregate received by the leaf AS would not contain the AS number of the leaf AS, and hence it is not discarded. Figure 5-32 gives an example of where this could be used.

Figure 5-32  Forming aggregate based on a subset of more specifics.

AS3 is a hub AS receiving routes 192.68.11.0/24 and 192.68.10.0/24 from the leaf ASs AS1 and AS2. Prefix 192.68.11.0/24 has an AS_path of 1, and 192.68.10.0/24 has an AS_path of 2. When the AS-SET aggregate is being formed by AS3 based on all the more specific routes, the AS_path information would be {1 2}. The aggregate itself, if sent back to either AS1 or AS2, would be discarded for loop prevention. AS1 will see its AS number in the AS_path information and would drop the update; the same is true for AS2. If you are able to specify which more specific routes can form the aggregate, then you could, for example, specify that the aggregate is to be formed based on 192.68.11.0/24 only. This way, the AS_path information would be 1 and would not contain AS2. The aggregate can now be sent back to AS2 with no problem. AS2 can use this aggregate to forward traffic to all destinations in AS1.

---

Troubleshooting:  
Example: Ch. 10, pp. 363-365. Forming the Aggregate Based on a Subset of More Specific Routes

---

Looking Ahead

Having mastered the basics of routing protocols and examined the particular configuration tools of BGP, you are now in a position to begin applying these tools to specific internetworking topologies. In doing so, you will be juggling a number of overarching design goals—redundancy, symmetry, and load balancing—that are of varying importance depending on a particular network's needs and that sometimes conflict with one another. The meaning of these design goals is discussed in more detail in the next chapter. The attributes covered in this chapter are used in the following chapter to achieve the desired routing design goals.

Tuning BGP capabilities to satisfy a network's needs involves looking outside the AS as well as inside. That is, the policies set by the networks to which you are interconnected, although usually outside your direct control, have practical implications for how you configure BGP at your end. All this becomes clearer in the next chapter, which covers multiple redundancy, symmetry, and balancing scenarios by presenting architectures commonly used on the current Internet.