Routing protocols usememory to store routing tables and topology information. Route summarization cuts memory consumption for all routing protocols. Keeping areas small reduces the memory consumption for hierarchical routing protocols.

CPU usage is protocol-dependent. Routing protocols use CPU cycles to calculate routes. Keeping routing information small by using summarization reduces CPU requirements by reducing the effect of a topology change and by decreasing the number of routes that must be recomputed after a topology change.

Bandwidth usage is also protocol-dependent. Three key issues determine the amount ofbandwidth a routing protocol consumes:

Distance-vector protocols, such as Routing Information Protocol (RIP) andInterior Gateway Routing Protocol (IGRP), broadcast their complete routing table periodically, regardless of whether the routing table has changed. This periodic advertisement varies from every 30 seconds for RIP, to every 90 seconds for IGRP. When the network is stable, distance-vector protocols behave well, but, waste bandwidth because of the periodic sending of routing table updates, even when no change has occurred. When a failure occurs in the network, distance-vector protocols do not add excessive load to the network, but they take a long time to reconverge to an alternative path or to flush a bad path from the network.

Link-state routing protocols, such as Open Shortest Path First (OSPF), Intermediate System–to–Intermediate System (IS-IS), and NetWare Link Services Protocol (NLSP), were designed to address the limitations of distance-vector routing protocols (slow convergence and unnecessary bandwidth usage). Link-state protocols are more complex than distance-vector protocols, and use more CPU and memory. The additional overhead (in the form of memory utilization and CPU utilization) dictates the number of neighbors that a router can support and the number of routers that can be in an area. These numbers vary from network to network, and depend on variables such as CPU power, memory, number of routes, and link stability.

When the network is stable, link-state protocols minimize bandwidth usage by sending updates only when a change occurs. A hello mechanism ascertains reachability of neighbors. When a failure occurs in the network, link-state protocols flood link-state advertisements (LSAs) throughout an area. LSAs cause every router within the failed area to recalculate routes. The fact that LSAs need to be flooded throughout the area in failure mode and the fact that all routers recalculate routing tables dictate the number of routers that can be in an area.

EIGRP is an advanced distance-vector protocolthat has some of the properties of link-state protocols. EIGRP addresses the limitations of conventional distance-vector routing protocols (slow convergence and high bandwidth consumption in a steady-state network). When the network is stable, EIGRP sends updates only when a change in the network occurs. Like link-state protocols, EIGRP uses a hello mechanism to determine the reachability of neighbors. When a failure occurs in the network, EIGRP looks for new successors when there is no feasible successor present in the topology table by sending messages to its neighbors. The search for new successors can be aggressive in terms of the traffic it generates (updates, queries, and replies) to achieve convergence. This behavior constrains the number of possible neighbors.

InWANs, consideration of bandwidth is especially critical. Frame Relay, for example, which statistically multiplexes many logical data connections (virtual circuits) over a single physical link, allows the creation of networks that share bandwidth. Public Frame Relay networks use bandwidth sharing at all levels within the network. That is, bandwidth sharing may occur within the Frame Relay network of Corporation X, as well as between the networks of Corporation X and Corporation Y.

Two factors have a substantial effect on the design of public Frame Relay networks:

Overall, WANs can lose packets due to a lack of bandwidth. For Frame Relay networks, this possibility is compounded because Frame Relay does not have a broadcast-replication facility; so for every broadcast packet sent out a Frame Relay interface, the router must replicate it for each PVC on the interface. This requirement limits the number of PVCs that a router can handle effectively.

In addition to bandwidth, network designers must consider the size of routing tables that need to be propagated. Clearly, the design considerations for an interface with 50 neighbors and 100 routes to propagate differ significantly from the considerations for an interface with 50 neighbors and 10,000 routes to propagate.

A router running EIGRP stores routes advertised by neighbors so that it can adapt quickly to alternative routes. The more neighbors a router has, the more memory a router uses. EIGRP automatic route aggregation bounds the routing table growth naturally. Additional bounding is possible with manual route aggregation.

EIGRP uses the DUAL algorithm to provide fast convergence. DUAL recomputes only routes affected by a topology change. DUAL is not computationally complex, but utilization of the CPU depends on the stability of the network, query boundaries, and reliability of the links.

EIGRP uses partial updates. Partial updates are generated only when a change occurs; only the changed information is sent, and this changed information is sent only to the routers affected. Because of this, EIGRP is efficient in its usage of bandwidth. Some additional bandwidth is used by EIGRP's Hello protocol to maintain adjacencies between neighboring routers.

To create a scalable EIGRP network, you should implement route summarization. To create an environment capable of supporting route summarization, you must implement an effective hierarchical addressing scheme. The addressing structure that you implement can have a profound impact on the performance and scalability of your EIGRP network.

Stability and redundancy are the most important criteria for the backbone. Stability is increased by keeping the size of the backbone reasonable. The size of the backbone must be reasonable because each router in the backbone needs to recompute its routes after every link-state change. Keeping the backbone small reduces the likelihood of a change and reduces the amount of CPU cycles required to recompute routes. Redundancy is important in the backbone to prevent partition when a link fails. Good backbones are designed so that no single link failure can cause a partition.

OSPF backbones must be contiguous. OSPF includes the use of virtual links. A virtual link creates a path between two Area Border Routers (an Area Border Router is a router that connects an area to the backbone) that are not directly connected. A virtual link can be used to heal a partitioned backbone. It is not a good idea, however, to design an OSPF network to require the use of virtual links. The stability of a virtual link is determined by the stability of the underlying area. This dependency can make troubleshooting more difficult. In addition, virtual links cannot run across stub areas. See the section titled "Backbone-to-Area Route Advertisement," later in this chapter for a detailed discussion of stub areas.

Avoid placing hosts (such as workstations, fileservers, or other shared resources) in the backbone area. Keeping hosts out of the backbone area simplifies network expansion and creates a more stable environment.

Individual areas should be contiguous. An area can be partitioned, but it is not recommended. In this context, a contiguous area is one in which a continuous path can be traced from any router in an area to any other router in the same area. This does not mean that all routers must share common network media. The two most critical aspects of area design follow:

Areas should have a contiguous set of network or subnet addresses. Without a contiguous address space, it is not possible to implement route summarization. The routers that connect an area to the backbone are called Area Border Routers. Areas can have a single Area Border Router or they can have multiple Area Border Routers. In general, it is desirable to have more than one Area Border Router per area to minimize the chance of the area becoming disconnected from the backbone.

When creating large-scale OSPF networks, the definition of areas and assignment of resources within areas must be done with a pragmatic view of your network. The following are general rules that help ensure that your network remains flexible and provides the kind of performance needed to deliver reliable resource access:

Route summarization is extremely desirable for a reliable and scalable OSPF network. The effectiveness of route summarization, and your OSPF implementation in general, hinge on the addressing scheme that you adopt. Summarization in an OSPF network occurs between each area and the backbone area. Summarization must be configured manually in OSPF. When planning your OSPF network, consider the following issues:

One of the simplest ways to allocate addresses in OSPF is to assign a separate network number for each area. With this scheme, you create a backbone and multiple areas, and assign a separate IP network number to each area. Figure3-11 illustrates this kind of area allocation.

Figure 3-11. Assignment of NIC Addresses Example

The following are the basic steps for creating such a network:

In the network illustrated in Figure3-11, each area has its own unique address. These can be Class A (the backbone in Figure3-11), Class B (Areas 4 and 6), or Class C (Area 5). The following are some benefits of assigning separate address structures to each area:

In the example illustrated in Figure3-11, the route-summarization configuration at the Area Border Routers is greatly simplified. Routes from Area 4 injecting into the backbone can be summarized as follows: All routes starting with 150.98 are found in Area 4.

The main drawback of this approach to address assignment is that it wastes address space. If you decide to adopt this approach, be sure that Area Border Routers are configured to do route summarization. Summarization must be explicitly set.

Bit-wise subnetting and variable-length subnetwork masks (VLSMs) can be used in combination to save address space. Consider a hypothetical network in which a Class B address is subdivided using an area mask and distributed among 16 areas. The Class B network, 156.77.0.0, might be subdivided as illustrated in Figure3-12.

Figure 3-12. Areas and Subnet Masking.

In Figure3-12, the letters x, y, and z represent bits of the last two octets of the Class B network, as follows:

Appendix A, "Subnetting an IP Address Space," provides a complete example illustrating assignment for the Class B address 150.100.0.0. It illustrates both the concept of area masks and the breakdown of large subnets into smaller ones using VLSMs.

Private Addressing

Private addressing is another option often cited as simpler than developing an area scheme using bit-wise subnetting. Although private address schemes provide an excellent level of flexibility and do not limit the growth of your OSPF network, they have certain disadvantages. Developing a large-scale network of privately addressed IP nodes limits total access to the Internet, for instance, and mandates the implementation of what is referred to as a demilitarized zone (DMZ). If you need to connect to the Internet, Figure3-13 illustrates the way in which a DMZ provides a buffer of valid NIC nodes between a privately addressed network and the Internet.

Figure 3-13. Connecting to the Internet from a Privately Addressed Network

Note

For a case study on network security, including information on how to set up firewall routers and communication servers, see Chapter 22, "Increasing Security in IP Networks."

Route summarization is particularly important in an OSPF environment because it increases the stability of the network. If route summarization is being used, routes within an area that change do not need to be changed in the backbone or in other areas. Route summarization addresses two important questions of route-information distribution:

The default value for OSPF metrics is based on bandwidth. The following characteristics show how OSPF metrics are generated:

When an area has only a single Area Border Router, all traffic that does not belong in the area will be sent to the Area Border Router. In areas that have multiple Area Border Routers, two choices are available for traffic that needs to leave the area:

If the Area Border Routers inject only the default route, the traffic goes to the Area Border Router closest to the source of the traffic. Generally, this behavior is desirable because the backbone typically has higher bandwidth lines available. If you want the traffic to use the Area Border Router nearest the destination (so that traffic leaves the area as late as possible), however, the Area Border Routers should inject summaries into the area instead of just injecting the default route.

Most network designers prefer to avoid asymmetric routing (that is, using a different path for packets going from A to B than for those packets going from B to A). It is important to understand how routing occurs between areas to avoid asymmetric routing.

To prevent a partitioned network, network topologies are typically designed to provide redundant routes. Redundancy is also useful to provide additional bandwidth for high-traffic areas. If equal-cost paths between nodes exist, Cisco routers automatically load balance in an OSPF environment.

Cisco routers can use up to four equal-cost paths for a given destination. Packets might be distributed either on a per-destination (when fast-switching or better) or a per-packet basis. Per-destination load balancing is the default behavior.

An OSPF router stores all the link states for all the areas that it is in. In addition, it can store summaries and externals. Careful use of summarization and stub areas can reduce memory use substantially.

An OSPF router uses CPU cycles whenever a link-state change occurs. Keeping areas small and using summarization dramatically reduces CPU use and creates a more stable environment for OSPF.

OSPF sends partial updates when a link-state change occurs. The updates are flooded to all routers in the area. In a quiet network, OSPF is a quiet protocol. In a network with substantial topology changes, OSPF minimizes the amount of bandwidth used.

Use OSPF NSSA when you want to summarize or filter Type 5 LSAs before they are forwarded into an OSPF area. The OSPF specification (RFC 1583) prohibits the summarizing or filtering of Type 5 LSAs. It is an OSPF requirement that Type 5 LSAs always be flooding throughout a routing domain. When you define an NSSA, you can import specific external routes as Type 7 LSAs into the NSSA. In addition, when translating Type 7 LSAs to be imported into nonstub areas, you can summarize or filter the LSAs before exporting them as Type 5 LSAs.

In Figure3-14, the central site and branch office are interconnected through a slow WAN link. The branch office is not using OSPF, but the central site is. Rather than define a RIP domain to connect the sites, you can define an NSSA.

Figure 3-14. OSPF NSSA Operation

In this scenario, Router A is defined as an ASBR. It is configured to redistribute any routes within the RIP/EIGRP domain to the NSSA. When the area between the connecting routers is defined as an NSSA, the following happens:

Type 7 LSAs have the following characteristics:

The steps used to configure OSPF NSSA are as follows:

Figure 3-15. Configuring OSPF NSSA.

Be sure to evaluate these considerations before implementing NSSA. As shown in Figure3-15, you can set a Type 7 default route that can be used to reach external destinations. The command to issue a Type 7 default route is as follows:

  router(config)#area area-id nssa [default-information-originate]

When configured, the router generates a Type 7 default into the NSSA by the NSSA ABR. Every router within the same area must agree that the area is NSSA; otherwise, the routers will not be able to communicate with one another.

If possible, avoid doing explicit redistribution on NSSA ABR because you could get confused about which packets are being translated by which router.

This feature is useful when you want to have an OSPF backbone at the central site, and you want to connect telecommuters or branch offices to the central site. In this case, OSPF on-demand circuit allows the benefits of OSPF over the entire domain without excessive connection costs. Periodic refreshes of Hello updates and LSA updates, and other protocol overhead are prevented from enabling the on-demand circuit when there is no "real" data to transmit.

Overhead protocols such as Hellos and LSAs are transferred over the on-demand circuit upon initial setup only and when they reflect a change in the topology. This means that topology-critical changes that require new SPF calculations are transmitted to maintain network topology integrity, but that periodic refreshes that do not include changes are not transmitted across the link.

Figure3-16 shows the network that will form the basis for the following overview of OSPF on-demand circuit operation:

Figure 3-16. OSPF Area

The steps used to configure OSPF on-demand circuit are summarized as follows:

If the router is part of a point-to-point topology, only one end of the demand circuit needs to be configured with this command, but both routers need to have this feature loaded. All routers that are part of a point-to-multipoint topology need to be configured with this command.

Consider the following before implementing OSPF on-demand circuit:

NBMA mode is the most efficient way to run OSPF over nonbroadcast networks, both in terms of link-state database size and in terms of the amount of routing-protocol traffic. However, it has one significant restriction: It requires all routers attached to the NBMA network to be able to communicate directly. Although this restriction may be met on some nonbroadcast networks, such as an ATM subnet utilizing SVCs, it is often not met on other nonbroadcast networks, such as PVC-only Frame Relay networks.

On nonbroadcast networks in which not all routers can communicate directly, you can break the nonbroadcast network into logical subnets, with the routers on each subnet being able to communicate directly. Then, each separate subnet can be run as an NBMA network or a point-to-point network if each virtual circuit is defined as a separate logical subnet. This setup requires quite a bit of administrative overhead, however, and is prone to misconfiguration. It is probably better to run such a nonbroadcast network in point-to-multipoint mode.

Point-to-multipoint networks have been designed to work simply and naturally when faced with partial mesh connectivity. In point-to-multipoint mode, OSPF treats all router-to-router connections over the nonbroadcast network as if they were point-to-point links. No designated router is elected for the network, nor is there an LSA generated for the network. It may be necessary to configure the set of neighbors that are directly reachable over the point-to-multipoint network. Each neighbor is identified by its IP address on the point-to-multipoint network. Because no designated routers are elected on point-to-multipoint networks, the designated-router eligibility of configured neighbors is undefined.

Alternatively, neighbors on point-to-multipoint networks may be dynamically discovered by lower-level protocols such as Inverse ARP. In contrast to NBMA networks, point-to-multipoint networks have the following properties:

The following is an example of point-to-multipoint configuration on an NBMA (Frame Relay, in this case) network. Attached is the resulting routing table and router link state, along with other pertinent information:

  interface Ethernet0
   ip address 130.10.6.1 255.255.255.0
  !
  interface Serial0
   no ip address
   encapsulation frame-relay
   frame-relay lmi-type ansi
  !
  interface Serial0.1 multipoint
   ip address 130.10.10.3 255.255.255.0
   ip ospf network point-to-multipoint
   ip ospf priority 10
   frame-relay map ip 130.10.10.1 140 broadcast
   frame-relay map ip 130.10.10.2 150 broadcast
  !
  router ospf 2
   network 130.10.10.0 0.0.0.255 area 0
   network 130.10.6.0 0.0.0.255 area 1

  R6#sh ip ospf int s 0.1
  Serial0.1 is up, line protocol is up
  Internet Address 130.10.10.3/24, Area 0
  Process ID 2, Router ID 140.10.1.1, Network Type POINT_TO_MULTIPOINT, Cost: 6,
  Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
  Hello due in 00:00:18
  Neighbor Count is 2, Adjacent neighbor count is 2
  Adjacent with neighbor 130.10.10.2
  Adjacent with neighbor 130.10.5.129

  R6#sh ip ospf ne

  Neighbor ID      Pri     State     Dead Time      Address          Interface
  130.10.10.2       0     FULL/      00:01:37       130.10.10.2   Serial0.1
  130.10.5.129      0     FULL/      00:01:53       130.10.10.1   Serial0.1
  R6#

  R6#sh ip ro
  Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
      D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
      E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
      i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
      U - per-user static route

  Gateway of last resort is not set

  130.10.0.0/16 is variably subnetted, 9 subnets, 3 masks
  O     130.10.10.2/32 [110/64] via 130.10.10.2, 00:03:28, Serial0.1
  C     130.10.10.0/24 is directly connected, Serial0.1
  O     130.10.10.1/32 [110/64] via 130.10.10.1, 00:03:28, Serial0.1
  O IA     130.10.0.0/22 [110/74] via 130.10.10.1, 00:03:28, Serial0.1
  O     130.10.4.0/24 [110/74] via 130.10.10.2, 00:03:28, Serial0.1
  C     130.10.6.0/24 is directly connected, Ethernet0

  R6#sh ip ospf data router 140.10.1.1

         OSPF Router with ID (140.10.1.1) (Process ID 2)
  Router Link States (Area 0)

   LS age: 806
   Options: (No TOS-capability)
   LS Type: Router Links
   Link State ID: 140.10.1.1
   Advertising Router: 140.10.1.1
   LS Seq Number: 80000009
   Checksum: 0x42C1
   Length: 60
   Area Border Router
    Number of Links: 3
  Link connected to: another Router (point-to-point)
   (Link ID) Neighboring Router ID: 130.10.10.2
   (Link Data) Router Interface address: 130.10.10.3
   Number of TOS metrics: 0
    TOS 0 Metrics: 64

  Link connected to: another Router (point-to-point)
   (Link ID) Neighboring Router ID: 130.10.5.129
   (Link Data) Router Interface address: 130.10.10.3
   Number of TOS metrics: 0
    TOS 0 Metrics: 64

  Link connected to: a Stub Network
   (Link ID) Network/subnet number: 130.10.10.3
   (Link Data) Network Mask: 255.255.255.255
   Number of TOS metrics: 0
    TOS 0 Metrics: 0