The Fundamentals of OSPF Routing Design

Previous Table of Contents Next


Scenario 1: Assigning Unique Network Numbers to Each OSPF Area

In this scenario each OSPF area has its own unique NIC-assigned IP address range. This can be as grand as a Class A address for the entire network with multiple Class Bs assigned to each area, or more realistically, you can be using a group of Class C addresses. This example is demonstrated in Figure 5-15. The benefits of this method are as follows:

  Address assignment is very simple.
  Configuration of the routers is easy and mistakes unlikely.
  Network operations are streamlined because each area has a simple unique address prefix.

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

1.  Define your structure (identify areas and allocate nodes to areas).
2.  Assign addresses to networks, subnets, and end stations as demonstrated in Figure 5-16.


Figure 5-16  Assigning unique network numbers to each OSPF area.

As an example, the route summarization configuration at the ABRs is greatly simplified. Routes from area 4 injected into the backbone would be summarized as “all routes starting with 150.98 are found in area 4.” This can be accomplished on a Cisco router with the following command:

    area 4 range 150.98.0.0 255.255.0.0 

The main drawback of this approach is that it can be very wasteful with important IP address space. Of course, this space could also be very difficult to obtain, at least until IPv6.

Scenario 2: Complex Address Assignment with Only a Single NIC Address

There might be a situation where you only have one NIC address (a single Class B for example) to allocate for all areas of your multi-area OSPF network. You might also wish to save some address space by using VLSM such that the point-to-point serial links in each area have a subnet mask that allows two hosts per subnet.

This example uses part of the address space for the NIC address 150.100.0.0. It is meant to illustrate both the concept of “area masks” and also the breakdown of large subnets into smaller ones (VLSMs).

The points that follow list the assumptions made and describe the process used to allocate addresses:

1.  Determine how many areas you will have in your OSPF network. A value of 500 has been chosen for this example. (A 500 area OSPF network is not realistic, but it will help to illustrate the methodology used.)
2.  Create an artificial “area mask boundary” in your address space. The dotted lines in Figure 5-17 indicate that you will be using 9 bits of the subnetable portion of the address to identify the areas uniquely. Note that 2exp9=512 meets the requirement of 500 areas. Only the address space for two of the 512 areas is documented in this example.


Figure 5-17  Bit-wise subnetting and VLSM example.

3.  Determine the number of subnets required in each area and the number of hosts (maximum) required per subnet. In this example, you require seven subnets with 14 hosts each and four subnets with 2 hosts each (the serial lines).
4.  Step 3 enables you to decide where to draw the dividing line between the subnet and host (called subnet mask) within each area. Note that you have only 7-bits left to use because of the creation of the artificial area mask. In fact, the 9-bits of the area mask are part of the subnet portion of the address, but you have restricted their flexibility so that you can summarize all the subnets of an area with one range command.

The portion of the address space that has the 2-bit host field (subnet mask of 255.255.255.252) was chosen arbitrarily from one of the larger subnet fields. This method of assigning addresses for the VLSM portion of the address space is done to guarantee no address overlap. Alternatively, if the requirement had been different, you could have chosen any number of the larger subnets (with mask 255.255.255.240) and broken them up into smaller ranges with fewer hosts, or combined several of them to create subnets with more hosts.

Realistic Summarization Design Guidelines

It is important to note that the sample of addresses and mask boundary choices in scenario 2 were chosen simply so that the entire address space of a single area could be shown on a single page. It is not realistic to have an OSPF network designed with 500 areas.

A realistic design might include the following:

  About 20-30 areas (maximum) for the entire AS
  Approximately 20-30 routers per OSPF area
  One or more Class B addresses with several Class C networks to allocate for the AS

Real World Route Summarization Example

Now that you know about segmenting the IP address space for 500 areas, you can take a more realistic approach. Assume that you have the following design criteria and IP addresses to work with:

  18 OSPF areas including the backbone area
  The following assigned network addresses:
  Class B: 156.77.0.0
  Class C: 198.22.33.0 198.22.34.0

Area Assignment

Here, each Class C network will be used entirely in its own area (similar to scenario 1) and the Class B address will be subdivided using an area mask and distributed among the remaining 16 areas.

The Class B network, 156.77.0.0, could be subdivided as follows:

    156.77. x x x x y y y y . y z    area mask boundary 

The letters x, y and z represent bits of the last two octets of the Class B.

The four x bits are used to identify 16 areas.

The five y bits represent up to 32 subnets per area.

The seven z bits allow for 126 (128-2) hosts per subnet.

All of the principles used for summarization and VLSM shown in scenarios 1 and 2 also apply for this more realistic example.

Route summarization is extremely desirable for a reliable and scalable OSPF internetwork. The effectiveness of route summarization, and your OSPF implementation in general, hinges on the addressing scheme that you adopt. Summarization in an OSPF internetwork occurs between each area and the backbone area. Summarization must be configured manually in OSPF.


Previous Table of Contents Next




OSPF Network Design Solutions
OSPF Network Design Solutions
ISBN: 1578700469
EAN: 2147483647
Year: 1998
Pages: 200
Authors: Tom Thomas

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net