Previous Table of Contents Next

Routers also combine various methods for learning routes. These methods should be designed to work together to establish the most efficient routing throughout the network. In addition to the technical considerations, designers should also consider cost in defining efficiency.

The router may obtain route information from any or all of the following sources:

  Connected interfaces
  Static routing entries
  Information learned from dynamic routing protocols
  Redistribution between routing protocols
  ARP, Inverse ARP, and ICMP redirects
  Manipulation of the previous methods via access lists and other filters

Designers should also consider what methods are available to trigger failure updates. Local interfaces can be detected via keepalives, including ATM OAM (operation, administration, and maintenance) cells, and the carrier-detect lead.

Network Design with Static Routing

Before presenting the dynamic routing protocols, it is appropriate to provide an overview of static routes. Static routes refer in the generic to those routes that are manually entered by the network administrator into the router’s configuration file. These routes may be used in at least one of three typical situations.

  The administrator needs to define a default route for packets to leave the network.
  The administrator requires a route that takes effect upon failure of the dynamic routing process. This is called a floating-static route.
  A dynamic routing protocol is not available or desirable. This may be for security, bandwidth, or compatibility concerns. Frequently, static routes are used to reduce overhead on single-point, low-bandwidth circuits.

There are a couple of deficits with static routes, however. First, the routes are static—as the name suggests. This means that failures in the network topology cannot be detected and circumvented automatically. Second, the administrator must manually populate the routing table and maintain the entries whenever a change to the network is made.

Cisco routers automatically support proxy ARP on most interfaces. The proxy ARP function will spoof off-network resources with the router’s MAC (Media Access Control) address, and the router will take the responsibility of forwarding packets to the final end node. This behavior permits the establishment of routes based on interfaces as opposed to the IP address. For example, the route may be through router, but the administrator can reference the route as being out interface Ethernet 0/0.

Because of security, diagnostic, and performance concerns, it is recommended that administrators not use the proxy ARP function and that it be disabled on all interfaces. While it is possible to find network administrators with little or no experience with one of the more advanced dynamic routing protocols, it is very unlikely that an administrator will not have experience with static routes. This static route experience may be to define a default route off the network or to define routes in areas where a dynamic routing protocol would be undesirable, including those in secure arenas and between companies.

Static routes offer the administrator a high degree of control over the network and consume no bandwidth for routing updates, making them advantageous on limited-bandwidth or low-reliability links. So, given the benefits of static routes—familiarity, controllability, and efficiency—why would a designer choose to not use static routes?

The answer typically is that designers do use static routes and, in fact, may use them quite often in the overall network design. However, the scalability of the network is greatly limited if the entire network is designed using static routes. This chapter will address the benefits of the dynamic routing protocols later, but for now will define these benefits as load balancing, redundancy, and scalability.

Network Design in the Real World: A Production Design Consideration

Before addressing the details of each routing protocol, it is important to establish a context that brings us back to design. The specifics of each routing protocol could easily consume an entire text on their own, and there are many solid treatments on each. However, for the exam objectives, it is only necessary to have a cursory understanding of each protocol—a level of detail that would be insufficient in production networks.

Therefore, this sidebar includes a scenario to illustrate a simple design challenge related to the selection of a routing protocol. The deployed solution is provided, so do not consider this to be a test. Rather, review this at a high level—the specific details of each protocol are provided only as a matrix for this solution set. In your network designs, you will likely add much more detail in terms of cost, complexity, supportability, and availability.

A large financial institution recently deployed a 70+-router network using all static routes. Clearly, it is possible to route a large number of networks using static routes; however, the design is severely limited, particularly in terms of administrative overhead. The network is a hub-and-spoke design with limited bandwidth and single routes throughout. The institution also desired that the network support different subnet masks, although the initial design was based on two hosts per subnet (a /30 mask). Given these conditions, consider the choices available to the designers and whether you would agree with the solution deployed. The routing options for a hub-and-spoke network are as follows:

No support for VLSM. Efficient, but consumes bandwidth.
RIP v2
Supports VLSM and is efficient, but is unfamiliar to this organization and consumes bandwidth.
While a strong choice from a number of perspectives, the design team was concerned about router CPU utilization and potential design issues should the enterprise convert to OSPF. The protocol supports VLSM and is fairly efficient regarding bandwidth utilization. Guidelines vary, but most experts recommend fewer than 50 OSPF neighbors (contrasting with EIGRP’s recommendation of 30—partly the result of memory requirements and partly the benefit of link-state protocols), so this design would be pushing that constraint.
While supported on the more advanced routers used for the pilot, EIGRP was not supported on the CBOS (Cisco Broadband Operating System) routers (600 series) that were preferred for cost reasons. In addition, EIGRP isn’t well suited to hub-and-spoke designs and may have problems with low memory/CPU routers with as few as 12 neighbors. A good protocol overall, EIGRP is not well suited to this design.
IGRP would not support VLSM, and it was not supported by the CBOS routers.
Static routes consume no bandwidth and use a minimal amount of CPU. In addition, the use of static routes will support variable-length subnet masks (in a manner of speaking). The downside is that static routes must be configured by the administrator.

Following a review of the above material, the only viable choices were RIP v2 and static routes. RIP v2 was considered, but the number of remote configuration steps and the bandwidth consumption issues were sufficient to put it in second place.

Notice some of the themes used in selecting a routing protocol: link bandwidth, router CPU utilization, router memory, support for VLSM, redundant paths, load balancing, availability, and support staff familiarity. These will be important factors in your designs.

Network Design with RIP

The Routing Information Protocol (RIP) is an amazing protocol. Few things in computing have lasted as long—and with as few changes (not counting RIP v2). However, IP RIP is a very limited (by today’s standards) distance-vector protocol capable of serving networks with up to 15 hops. It is classful, which means that the protocol does not include subnet mask information—therefore, route summarization and VLSM functions are not available.

In actuality, RIP and the other classful routing protocols do summarize— unfortunately, it is on the classful boundary, which was discussed in Chapter 3. Therefore, summarization with a classful protocol is typically a deterent.

Previous Table of Contents Next