
- •Table of Contents
- •About the Technical Reviewers
- •Acknowledgments
- •Introduction
- •Objectives
- •Audience
- •Organization
- •Approach
- •Features and Text Conventions
- •Command Syntax Conventions
- •Icons Used in This Book
- •Origins and Recent History of the Internet
- •Network Access Points
- •Routing Arbiter Project
- •The Very High-Speed Backbone Network Service
- •Transitioning the Regional Networks from the NSFNET
- •NSF Solicits NIS Managers
- •Other Internet Registries
- •Internet Routing Registries
- •The Once and Future Internet
- •Looking Ahead
- •Frequently Asked Questions
- •References
- •ISP Services
- •Looking Ahead
- •Frequently Asked Questions
- •History of Internet Addressing
- •IP Address Space Depletion
- •Looking Ahead
- •Frequently Asked Questions
- •References
- •Overview of Routers and Routing
- •Routing Protocol Concepts
- •Segregating the World into Autonomous Systems
- •Looking Ahead
- •Frequently Asked Questions
- •References
- •How BGP Works
- •BGP Capabilities Negotiation
- •Multiprotocol Extensions for BGP
- •TCP MD5 Signature Option
- •Looking Ahead
- •Frequently Asked Questions
- •References
- •Building Peer Sessions
- •Sources of Routing Updates
- •Overlapping Protocols: Backdoors
- •The Routing Process Simplified
- •Controlling BGP Routes
- •Route Filtering and Attribute Manipulation
- •BGP-4 Aggregation
- •Looking Ahead
- •Frequently Asked Questions
- •References
- •Redundancy
- •Symmetry
- •Load Balancing
- •Looking Ahead
- •Frequently Asked Questions
- •References
- •Interaction of Non-BGP Routers with BGP Routers
- •BGP Policies Conflicting with Internal Defaults
- •Policy Routing
- •Looking Ahead
- •Frequently Asked Questions
- •Route Reflectors
- •Confederations
- •Controlling IGP Expansion
- •Looking Ahead
- •Frequently Asked Questions
- •References
- •Route Instabilities on the Internet
- •BGP Stability Features
- •Looking Ahead
- •Frequently Asked Questions
- •Building Peering Sessions
- •Route Filtering and Attribute Manipulation
- •Peer Groups
- •Sources of Routing Updates
- •Overlapping Protocols: Backdoors
- •BGP Attributes
- •BGP-4 Aggregation
- •Looking Ahead
- •Redundancy, Symmetry, and Load Balancing
- •Following Defaults Inside an AS
- •Policy Routing
- •Route Reflectors
- •Confederations
- •Controlling Route and Cache Invalidation
- •BGP Outbound Request Filter Capability
- •Route Dampening
- •Looking Ahead
- •Interesting Organizations
- •Research and Education
- •Miscellaneous
- •Books
- •Internet Request For Comments
- •When to Use BGP ORF
- •Configuration
- •EXEC Commands
- •Closing Remarks
- •The Motivation Behind the New Command-Line Interface
- •Organizing Command Groups in the New Configuration
- •Peer Groups
- •Route Maps
- •Redistribution
- •Route Reflector
- •Aggregation
- •List of BGP Commands
- •Upgrading to the AF Style

Internet Routing Architectures, Second Edition
Figure 9-8. Full-Mesh BGP Topology
In conclusion, the route reflector concept is growing in popularity for large networks because it is both a simple and a scalable approach that does not require substantial overhead. Furthermore, migrating from a nonroute reflector to a route reflector design is easy. Only those routers intended to be route reflectors need to be modified; all other routers operate as usual. In addition, routers that do not implement the route reflector behavior, such as clients or nonclients, could be part of the AS with no loss of BGP routing information.
Confederations
A confederation[] is another way to deal with the explosion of an IBGP mesh within an AS. As with route reflection, confederations are recommended only for cases in which IBGP peering involves a large number of IBGP peering sessions per router.
TIP
See the section "Confederations" in Chapter 12.
BGP confederations are based on the concept that an AS can be broken into multiple sub-ASs. Inside each sub-AS, all the rules of IBGP apply. All BGP routers inside the sub-AS, for example, must be fully meshed. Because each sub-AS has a different AS number, external BGP must run between them. Although EBGP is used between sub-ASs, routing inside the confederation behaves like IBGP routing in a single AS. In other words, the next hop, MED,
page 242

Internet Routing Architectures, Second Edition
and local preference information is preserved when crossing the sub-AS boundaries. To the outside world, a confederation looks like a single AS. Figure 9-9 shows an example of a confederation.
Figure 9-9. Sample Confederation of Sub-AS Constructs
In Figure 9-9, AS100 is split into two sub-ASs: AS65050 and AS65060. The AS, as a whole, is now one large confederation, identified by a single confederation number, 100. All the subASs are shielded from the outside world and can be given any AS numbers. The numbers could be chosen from the private AS range (64512 to 65534, as designated in RFC 1930[]) in order not to use up any formal AS numbers.
As mentioned previously, inside the sub-AS an IBGP full mesh is used. EBGP is used between the sub-ASs as well as between the confederation itself and outside ASs. Confederations can easily detect routing loops inside the whole AS because EBGP is run between sub-ASs. The AS path list is a loop-avoidance mechanism used to detect routing updates leaving one sub-AS and attempting to reenter the same sub-AS. A routing update that tries to reenter a sub-AS it originated from will be detected because the sub-AS will see its own sub-AS number listed in the update's AS path.
Confederation Drawbacks
The drawback of confederations is that migration from a nonconfederation to a confederation design requires major reconfiguration of the routers and a major change in the logical topology. In addition, routing through a confederation might not take an optimal path without manually setting BGP policies. Figure 9-10 illustrates this issue.
page 243

Internet Routing Architectures, Second Edition
Figure 9-10. AS Confederation Internal and External Routing
Confederation 100 is composed of three sub-ASs: 65010, 65020, and 65030. The AS path within confederation 100 is represented by the sequence of ASs and sub-ASs the route has traversed. In standard BGP, the shortest AS path determines the best path traffic will pass through. However, in a confederation, sub-ASs do not influence the overall AS path length. For instance, one prefix composed of two equal-length AS paths that each have differentlength sub-AS paths could introduce suboptimal routing inside the AS because it is unclear which is the better path. From the point of view of sub-AS 65030, AS path (65010) is the same length as AS path (65020 65010); traffic inside the confederation may take either path. Additional policies would have to be set to affect routing behavior appropriately. For example, the local preference can be configured to make the AS path (65010) preferred over (65020 65010).
Because the confederation is a single AS, the path taken by external ASs through a confederation is unknown. This is misleading for ASs that base their routing policies on the AS path length. To reach AS200, AS300 will most likely prefer to go via confederation 100 because the path looks shorter than the path through AS400 and AS500. In actuality, of course, confederation 100 is not the shortest path because it includes a path via three sub-ASs (65030 65020 65010), whereas the alternative (AS400 AS500) includes only two. AS300 will never know of this pitfall unless the AS100 confederation design is disclosed.
Route Exchange and BGP Decisions with Confederations
Even though routes are exchanged between sub-ASs of a confederation via EBGP, all the IBGP rules still apply in order for the whole AS to still behave as a single routing domain. The EBGP NEXT_HOP is still carried within the AS, as is the MED and LOCAL_PREF values.
page 244

Internet Routing Architectures, Second Edition
As far as the BGP decision algorithm, the only changes are in the way BGP routes to outside the confederation compared to how BGP routes inside the confederation. Without confederations, EBGP routes are preferred over IBGP routes. With confederations, we have introduced a new type of EBGP route between the sub-ASs—a confederation external route. BGP prefers routes in the following manner:
EBGP routes to outside the confederation > confederation exterior routes > IBGP routes
Therefore, if BGP has a choice between two paths to the same destination—one leading outside the confederation and one leading inside the whole confederation—BGP will pick the exterior path. Furthermore, if BGP has a choice between two paths to the same destination— one inside the sub-AS and one outside the sub-AS—BGP will pick the exterior path leading out of the sub-AS. This is, of course, assuming that all other attributes are the same.
Recommended Confederation Design
Choosing and connecting the sub-ASs randomly inside the confederation will lead to problems. Unnecessary processing might occur because each sub-AS can end up getting similar information from other sub-ASs via a single path. Besides, suboptimality will be introduced because all paths inside the AS have exactly the same length, as already discussed.
Experience has proven that a centralized confederation architecture results in the most optimal routing behavior. The centralized design means that all sub-ASs exchange information with each other through a central sub-AS backbone.
In Figure 9-11, each sub-AS interacts with only one other sub-AS. The result will be more uniform routing with respect to AS path length and route exchange within the confederation.
Figure 9-11. Centralizing Confederation
Confederations Versus Route Reflectors
Determining whether to use route reflectors or confederations is not a simple decision. Although different organizations have experienced various levels of stability with these approaches, Cisco recommends the use of the route reflector technique to solve IBGP mesh scalability issues. Actual deployments have proven that route reflectors are more flexible to implement and maintain. On the other hand, confederations could be used to run an IGP in
page 245