6.7 Routing Strategies

6.7 Routing Strategies

This section introduces and describes popular interior and exterior routing protocols. Section 6.7.1 describes which protocols are best for which circumstances, and Section 6.7.2 describes how to select the appropriate ones to use within each network.

Now that we have the framework for routing developed and some addressing strategies, let's consider some strategies for applying routing protocols. This section covers the characteristics of some popular routing protocols, criteria for making selections from these protocols, and where to apply and mix these protocols.

Typically, when routing protocols are evaluated, it is on the basis of characteristics that are somewhat distant from the overall architecture, such as their convergence times; their protocol overheads, in terms of capacity (bandwidth overhead), CPU utilization, and memory utilization; and their stability. Although these are important characteristics to consider, it is often difficult to relate them directly to the network architecture or design. They are, however, indirectly related to the architecture and design through two characteristics discussed several times in this book: hierarchy and interconnectivity.

From the perspective of choosing a routing protocol, the hierarchy and interconnectivity of the network helps determine the required complexity and features of the routing protocol. In determining the degrees of hierarchy and interconnectivity in the network, we are indirectly applying the two aforementioned characteristics to the network.

For example, convergence time for a routing protocol is directly related to the degree of interconnectivity in the network. When used to provide redundancy, a higher degree of interconnectivity implies a requirement for predictable or guaranteed (mission-critical) reliability. This may also be explicitly stated as a requirement from the requirements analysis. As interconnectivity increases in importance, the routing protocol will need to converge rapidly when changes in the routing topology occur. This also indicates a need for stability in the routed network.

In distributed networks (which routed networks usually are), hierarchy tends to force decision making (e.g., routing decisions) down the tree. In the case of routing protocols, this may require an abstraction of hierarchy in the routing protocol itself, such as the area abstraction in OSPF.

We can apply degrees of hierarchy and interconnectivity to our evaluation of routing protocols. In addition, in evaluating the routing protocols for your network, you will want to ensure that the network is segmented into FAs and WGs.

Other criteria to consider in routing protocols are the relative complexities of the protocols, or their ease of use, and the interoperability of the protocol. These criteria may be dependent on how the vendor implements the routing protocol, making them more difficult to assess subjectively. Some of the many trade-offs in routing protocol choices are simplicity and ease of use versus sophistication and features, and interoperability versus vendor-specific features.

Some routing protocols are relatively simple to configure and maintain. RIP, for example, is pretty much a "plug-and-play" routing protocol, as long as the network is not too large and you do not try anything complex. Easy-to-use protocols tend to not have many features or options and may not scale well to high degrees of hierarchy or interconnectivity. As routing protocols increase in features or scalability, they also become more complex, requiring greater expertise on the part of the staff that will be operating the network. The routing protocol may have some parameters that are tunable, allowing network operators to change the values of these parameters to optimize protocol performance or features. This can be a great help for networks that have extreme size, unique topology characteristics, or multitier performance requirements, but it also requires quite a bit of personnel resources in monitoring and maintenance.

Interoperability is support for operations, administration, maintenance, and provisioning (OAM&P), performance and features across multiple vendor platforms. For routing protocols, standards are the start toward interoperability. Standards are necessary, but not sufficient, for protocol interoperability. Do not assume that, when an implementation of a routing protocol supports or is based on a standard, it will interoperate with all other vendor implementations of the same protocol. To be certain of interoperability, you need to know which vendor implementations you expect to deploy in the network and then either check to see what interoperability tests have been done (there are several test labs that perform such tests and release information to the public) or test interoperability yourself, in your own test environment.

At times, it may be necessary to accept reduced interoperability to get features or performance from a particular vendor. For example, we may get a highly desirable feature with a vendor-specific routing protocol or a degree of support from the vendor that far exceeds that with a standard protocol. However, although there are times when vendor-specific routing protocols may be considered, they should always be considered with caution. If you choose a vendor-specific (proprietary), nonstandard routing protocol, you run the risk of becoming locked into using that protocol. It may prove expensive to include or change to a standard protocol later, as the network operations staff may have to learn this new protocol, including interactions with the existing protocol. Once locked into a proprietary routing protocol, you may be forced to continue to buy and deploy that vendor's equipment, even though this may not be optimal for your network.

6.7.1 Evaluating Routing Protocols

We will briefly examine and compare some popular IGPs and EGPs: RIP and RIPv2, OSPF, and BGPv4. We will also consider the limited use of static routes in the network. We will not consider any proprietary routing protocols in this book.

Static routes are routes that are configured manually, by network personnel or scripts, in network devices and that do not change until manually deleted or modified. As such, they are not routing protocols but are considered in this chapter since they have an impact on the routing in a network. Many people overlook the use of static routes, yet they can be useful in some networks, primarily when a routing protocol is not needed. Some disadvantages to static routes are that they require maintenance and they require resources on routers. This can become significant with a large number of static routes.

Routing protocols are dynamic. They learn about reachability within and between networks and update that information periodically; thus, they are needed when alternative paths exist in the network (i.e., there is some degree of interconnectivity). When there is only one path into or out of an area, a routing protocol cannot adapt to changes in topology. A stub network is a network with only one path into or out of it, as in Figure 6.23.

Figure 6.23: Stub networks.

With stub networks, a static route can be applied between the stub network and the network to which it is connected. A trade-off in using static routes is not having to configure and maintain a routing protocol versus having to maintain the static routes. Since a stub network has only one path into or out of it, a default route is usually all that is needed. A static route may be used to provide this default.

Static routes can also be used to force routing along a certain path. Since a routing protocol is not used, alternative paths are not learned or used, thus forcing traffic to use the static route. This can be useful (e.g., it is sometimes used to enhance security), but it should always be used with caution.

Whenever there are multiple paths into and out of a network, a routing protocol should be considered. Popular routing protocols, such as RIP, RIPv2, and OSPF, use either a distance-vector or a link-state routing algorithm to determine reachability.

In a distance-vector routing algorithm, each router maintains the "distance" (a metric to weight each hop, or connection, between routers) between itself and possible destinations. A vector (or list) of these distances is computed from distance information received from other participating routers on that network. In a link-state routing algorithm, each router learns about itself, its links to next-hop routers (its neighbors), and the state of each link. This information is multicasted to other participating routers, and all routers build their routing information from the sum of these multicasts.

For an excellent description of routing protocol algorithms, see Interconnections, second edition (listed in Section 6.2).

RIP and RIPv2 are IGPs that are based on a distance-vector routing algorithm. This implies some characteristics of the dynamic behavior of RIP/RIPv2-routed networks. RIP and to a lesser degree RIPv2 are relatively straightforward to implement and maintain. RIP has been around for a long time (more than 30 years), having been part of the TCP/IP suite shipped with most UNIX systems, and there is a lot of experience with RIP-routed networks. Given the simplicity, longevity, and experience with RIP, interoperability between various versions of RIP should not be a problem.

Because of the nature of the distance-vector routing algorithm used in RIP/RIPv2, they can be slow to converge to a new routing topology when changes occur in the network, where "slow" is on the order of minutes. They can also form routing instabilities in networks with high degrees of hierarchy or interconnectivity, although several mechanisms have been developed to minimize the probabilities of their forming (e.g., poison reverse, hold-down timers). For these reasons, they are not optimal for areas that have high degrees of hierarchy or interconnectivity.

RIP/RIPv2 should be considered when there is low to medium hierarchy and interconnectivity in the network. Degrees of hierarchy and interconnectivity are shown in Figure 6.24.

Figure 6.24: Degrees of hierarchy and interconnectivity.

OSPF is an IGP that is based on a link-state algorithm. Like RIP/RIPv2, the choice of routing algorithm affects the characteristics of the protocol. In the case of OSPF, the use of a link-state algorithm results in a faster convergence time when changes in the routing topology occur. Convergence times can be on the order of seconds, one to two orders of magnitude faster than RIP/RIPv2. For an area with high hierarchy or interconnectivity, a fast convergence time may be the single most important feature of a routing protocol and would indicate the use of OSPF.

OSPF also supports an area abstraction, which provides a hierarchy for routing information. The OSPF hierarchy connects these areas via a backbone area, and routing information is internalized within each area. This reduces the size of routing information flows across the OSPF network. In addition to the area abstraction, OSPF supports equal-cost multipath, allowing multiple paths to be used to the same destination when their OSPF costs are the same.

There are trade-offs for OSPF's rapid convergence times and area abstraction. One trade-off is in complexity. OSPF can require a substantial amount (relative to RIP) of configuration during setup and possibly configuration tuning to reach an optimized steady-state routing topology. There is more information to understand, monitor, and use in an OSPF-routed network. This information can be helpful in isolating and troubleshooting routing problems, but personnel skilled in using this information are also required. In addition, interoperability between various OSPF implementations is less certain than with RIP.

OSPF should be considered when there is high hierarchy and interconnectivity in the network (see Figure 6.24).

BGPv4 (or BGP) is a path-vector-based EGP. A path-vector algorithm is similar to a distance-vector algorithm, such as that used in RIP; however, it operates on ASs or lists of ASs (paths). In addition, BGP can use policies to determine actions to be taken on paths.

BGP exchanges routing information via establishing peering connections using TCP with a user-defined list. BGP is used to enforce network transport policies for an AS, such as allowing all routes from a certain AS to use this AS as a transit route, rejecting all routes that have been learned from a certain AS, and announcing only certain routes from this AS to other peers.

The configuration of BGP depends on the complexity of your policy definitions. Once these are configured, BGP will operate within those policies in a dynamic manner. BGP is best suited as an inter-AS (interdomain) routing protocol, although there are times when it is used within an AS.

BGP operates between ASs, yet there may be a number of routers (termed border routers) that connect to external networks. As such, there needs to be a mechanism for border routers from the same AS to communicate path information so that it can be passed to multiple ASs (Figure 6.25).

Figure 6.25: Application of internal BGP (iBGP) and external BGP (eBGP).

Therefore, there are two types of BGP: external BGP (eBGP) and internal BGP (iBGP). eBGP is the "normal" operational mode of BGP—passing path information between ASs. iBGP is used to form tunnels between border routers within an AS to pass path information across that AS. Why is this necessary? BGP communicates path information and policies, which are not (as yet) recognized by IGPs. Thus, if border routers within an AS were forced to use an IGP to communicate (e.g., OSPF), the path and policy information would be lost in translating between BGP and OSPF. Therefore, tunnels are used so border routers do not need to translate BGP to an IGP.

6.7.2 Choosing and Applying Routing Protocols

This section presents some recommendations for choosing and applying routing protocols for your network. They were developed to simplify the application of routing protocols whenever possible. These recommendations are as follows:

1. Minimize the number of routing protocols used in the network. Two should be the maximum number of protocols allowed, with only one IGP.

2. Start with the simplest routing strategy and routing mechanism/protocol.

3. As the complexity in routing and choices of routing protocols increases, reevaluate the previous decisions.

Minimizing the number of routing protocols is straightforward: Do not overcomplicate the routing architecture by applying too many routing protocols. How many routing protocols is "too many" is based on the ability of the customer—specifically those responsible for OAM&P of the network—to support those protocols. It does not make sense to architect and design a complicated network that cannot be managed by the network staff. Many networks focus on a single IGP within their AS and an EGP for external communications. However, as we will see, there are times when multiple IGPs within and AS and even a mix of IGPs and EGP together within an AS can work, as long as the trade-offs in complexity and support are well understood.

We also want to start with the simplest routing strategy and work up to more complex strategies when necessary. The simplest strategy is to use static routes, and this would be considered first for stub areas. If there are no stub areas in the network, or when a routing protocol is indicated, then RIP or RIPv2 should be considered. Recall that RIP/RIPv2 are recommended for networks with low to medium hierarchy and interconnectivity. When the network increases to a high degree of hierarchy and interconnectivity, OSPF should be considered. The approach is to apply static routes first for stub areas, then RIP/RIPv2 when network hierarchy and interconnectivity are low to medium, then OSPF when network hierarchy and interconnectivity are high. BGP is applied when an EGP is required in the network.

Since we are starting with the simplest routing mechanism (static routes) and working our way up to more complex mechanisms, we usually start with the outer edges of the network, where hierarchy and interconnectivity is lowest, and work our way toward the center, or backbone, of the network, where hierarchy and interconnectivity are highest (Figure 6.26).

Figure 6.26: Example application of static routes, IGPs, and EGPs in a network.

The idea is to start simple and add a more complex routing protocol only when needed. When a more complex routing protocol is needed, however, we need to reevaluate previous choices, not just add the protocol to the network. As a result of reevaluating previous choices, we may decide to keep them and just add the new routing protocol to the network, or we may decide to replace the previous routing protocol with the new one. The intent is to keep the number of routing protocols to a minimum and to avoid having multiple instances of the same routing protocol in different areas of the network. With this in mind, the third recommendation may be extended as follows:

3a.	When static routes have previously been chosen and RIP/RIPv2 has been chosen as the routing protocol for another area of the network, RIP/RIPv2 replaces static routes for those areas where static routes were chosen.
3b.	When RIP/RIPv2 has previously been chosen and OSPF has been chosen as the routing protocol for another area of the network, OSPF replaces RIP/RIPv2 for those areas where RIP/RIPv2 was chosen.
3c.	BGP, when required for a backbone network, may replace OSPF or RIP/RIPv2 if they were previously chosen for the backbone.

Although keeping the number of routing protocols in the network to a minimum is recommended, there are times when the benefits of having more than one IGP may out-weigh the costs of their support and maintenance. When the network hierarchy and interconnectivity is high enough to warrant changing the routing protocol from RIP/RIPv2 to OSPF, the areas where RIP/RIPv2 or static routes are already assigned are then reevaluated. There may be areas where OSPF is beneficial and other areas where it does not offer any additional benefits and may increase support or maintenance costs.

There may also be times when applying BGP within the network, with either RIP/RIPv2 or OSPF, is appropriate. Applying BGP within the network may be considered when the network is so large that it should be fragmented into multiple ASs or when the organizations within the network want administrative, management, or security autonomy. In such cases, the boundary between the organizations could be treated as a hard boundary.

One thing to consider when mixing routing protocols is how information is to be translated between routing protocols. Information such as network masks, protocol metrics, policies, or AS information can easily be lost or misrepresented when translating between routing protocols. There is currently no standard metric translation between dissimilar routing protocols.

In applying routing protocols, we start by evaluating the degrees of hierarchy and interconnectivity of each FA and considering any other factors for that FA, or features of the routing protocols that may apply. When a change is made in the choice of routing protocol, such as from static routes to RIP/RIPv2, from RIP/RIPv2 to OSPF, or from RIP/RIPv2/OSPF to BGP, reevaluate FAs where routing protocols or static routes have already been chosen. In general, RIP/RIPv2 supersedes static routes, and OSPF supersedes RIP/RIPv2, but remember that you can also consider combining the protocols within the network. Figure 6.27 illustrates the process of applying routing protocols.

Figure 6.27: Iterative evaluation of routing protocols.

FAs that contain only backbone networks should be considered last because they are usually the most complex. It is therefore likely that the backbone networks will require the most complex routing protocols. This is where BGP may be considered. In general, for the backbone network:

1. If all FAs are using the same routing protocol, that protocol should be considered first for the backbone.

2. When multiple routing protocols are chosen for the network, consider the more complex protocol for the backbone first.

3. When the backbone interconnects ASs, or when organizations require autonomy in interfacing to the backbone, consider BGP as the routing protocol for the backbone.

The decisions developed in choosing and applying routing protocols should be documented as part of the addressing and routing architecture. Showing the decisions for each area of the network, as in Figures 6.26 and 6.27, is a start toward this documentation.