Recommended Confederation Design

Choosing and connecting the sub-ASs randomly inside the confederation will lead to problems. Unnecessary processing will occur because each sub-AS will end up getting similar information from other sub-ASs. Besides, suboptimality will be introduced due to the fact that all paths inside the AS have exactly the same length, as already discussed.

Experience shows that a centralized confederation design leads to the best behavior. Centralized design means that all sub-ASs will exchange information with each other via a central sub-AS backbone.

With the example illustrated in Figure 8-10, each sub-AS will have interaction with only one other sub-AS, and routing will be more uniform as far as path length and route exchange within the confederation.

Figure 8-10  Centralizing confederation.

Confederations or Route Reflectors

Determining whether you should use route reflectors or confederations is not a simple decision. Different organizations have experienced different levels of stability with either approach. Cisco recommends the use of the route reflector technique to solve the IBGP mesh issues. Route reflectors have proven to be more flexible to deploy. On the other hand, confederations could be used to run an IGP in one sub-AS independently of IGPs in other sub-ASs, which would help in controlling the instabilities of large IGPs.

In some situations, both approaches, route reflectors and confederations, can be used in conjunction with each other. An AS can be divided into sub-ASs that are running route reflectors.

Whichever approach you use, you should always understand the restrictions and behavior of each method and design your network accordingly.

Controlling IGP Expansion

One of the ways in which administrators push their networks to the limit is by letting them grow in size in such a way that the IGP will be hard to manage. Whether the IGP is as outdated as RIP version 1 or as advanced as OSPF and ISIS, the issue of scalability will arise. So far, this chapter has discussed route reflectors and confederations as ways of managing IBGP growth. A scalable way of managing IGP expansion is to segment the AS into multiple regions, each running a single, distinct IGP. The individual regions, in turn, must be connected via BGP. With this design, the stability of one region would not affect the stability of another.

What criteria should network designers and architects follow in deciding whether their networks need segmentation? One thing is for sure: the Internet is one huge network that cannot be handled by running an IGP, and that is why it is segmented by BGP.

So what constitutes a large or small network? Is it the number of routers or the number of routes, and if so, what number? You will hear different answers based on different administrators' experiences. The general answer to this question depends mainly on how robust the IGP, what tools it can offer to control the route explosion and instability, and whether BGP segmentation represents a more beneficial, less costly (in dollars and effort) method than relying on the IGP's tools.

Protocols such as OSPF and ISIS offer certain hierarchical methods that can control route instabilities and provide means for route summarization. But even with these methods, the IGP can grow beyond control. A working guideline for today's networks is that IP routing tables having 2,000 to 3,000 IGP interior routes may have reached a limit and need a closer look to make sure that they do not grow further. It is not the number of routes that cause problems, because BGP transit routers today are carrying more than 42,000 Internet routes with no problem. What causes problems is situations, such as hardware and access line instabilities, where these routes end up bouncing and trying to converge, causing what is known as a network "meltdown."

Does this mean that networks with 3,000 IGP routes need to be segmented via BGP? The answer is, not necessarily. In most cases, a redesign of the IGP itself with more emphasis on using the IGP segmentation and summarization techniques can bring down the number of routes to a manageable level.

To understand why the decision to control growth with BGP segmentation should be approached with caution, you need to understand what is compromised when ASs are segmented. The main strength of IGPs, especially IGPs based on Link State protocols, has always been convergence; that is, their capability to quickly adapt to network changes. Another strength is their capability to develop a level of redundancy and load balancing.

BGP, on the other hand, was created to implement policies across AS boundaries, with no major emphasis on convergence. When segmenting with BGP, convergence will be enhanced within the newly created smaller segments, but might diminish when crossing sub-AS boundaries because of the dependency of BGP on TCP sessions to carry routing updates.

Another drawback is the additional user intervention needed to control and manage the BGP policies that are automatically imposed on the routing behavior. As you have seen in this book, attribute manipulation is so far the only tool to manipulate routing behaviors. With the introduction of more ASs, what used to be simple IGP routing is no longer the case. Understanding all these issues will help designers develop a realistic approach to designing their networks.

This section discusses two methods of segmenting the AS:

•  Multiple regions separated by IBGP

•  Multiple regions separated by EBGP