Cisco Knowledge Suite Cisco SystemsCisco Press

Cutting Edge
Core Reference
Guided Learning
Networking Architecture
Internet Protocols (IP)
Network Protocols
Transport and Application Protocols
Desktop Protocols
Security and Troubleshooting
Network Resources and Management
Integrated Services

Designing & Implementing an OSPF Network


< Back Contents Next >


7. -

Designing & Implementing an OSPF Network



OSPF Network Design



Configuring OSPF on Cisco Routers



Chapter Summary



Case Study: Designing an OSPF Frame Relay Network



Case Study Conclusions



Frequently Asked Questions

Save to MyCKS

OSPF Network Design Solutions

From: OSPF Network Design Solutions
Author: Thomas Thomas
Publisher: Cisco Press (53)
More Information

“Imagination: A mind once stretched by a new idea never regains its original dimensions.”— Successories

This chapter covers the actual process of sitting down and designing your OSPF network. The real process of putting the pen to paper and the true process behind it is covered. It is this chapter's intention to take the mystery out of designing any type of network. The concepts and steps discussed have universal application whether your network is BGP or OSPF; of course, the latter is emphasized. Chapter 6, “Advanced OSPF Design Concepts,” covered many of the commands necessary for configuring OSPF. In this chapter, you will become familiar with the necessary steps to actually begin the OSPF process on a Cisco router. You already know there are many potential network architectures where you would have to configure OSPF, and the most common are covered in this chapter. This chapter has two specific sections as follows:

  • OSPF Network Design. This section reviews the specific network design goals that should be the general basis of every network. There are certain issues that you must be aware of as network designers, and they are discussed in this section. The six fundamental steps that make up the Network Design Methodology are covered with special enhancements given to issues regarding OSPF.

  • Configuring OSPF on Cisco Routers. At this point in the book, you have everything you need to know about how OSPF works and how to go about designing and implementing an OSPF network. But how do you turn on OSPF? This section addresses basic and advanced configuration issues as relate to Cisco routers. A bonus area is covered as well that deals with multi-protocol routers.

OSPF Network Design

This book has discussed the various design techniques for OSPF, from the various golden rules to the number of routers per area. It is now time to actually take this information and begin the process of designing an OSPF network. Let's begin the process by determining what is actually supported by Cisco Systems.

Cisco's Implementation of OSPF

As discussed in Chapter 4, “Introduction to OSPF,” there is a variety of RFCs that deal with OSPF. By now, you should be familiar with the many different features available within the OSPF protocol. But which RFCs does Cisco support within its products?

  • RFC 1253: Open Shortest Path First (OSPF) MIB. This RFC contains the information, which provides management information relating to OSPF.

  • RFC 1583: OSPF Version 2. Cisco's implementation conforms to the specifications as detailed in this RFC. They support the following key features: stub areas, route redistribution, authentication (covered later), tunable interface parameters, and virtual links.

  • RFC 1587: Not-So-Stubby-Areas (NSSA). Cisco equipment supports the use of all types of stub areas.

  • RFC 1793: OSPF over Demand Circuits. Cisco supports this RFC as well.

Network Design Goals

It is not necessary to get into the reasons behind your decision to build an OSPF network or any of the previously covered definitions of what a network is. However, the five basic goals that you should keep in mind while designing your OSPF network (or any network for that matter) should be adhered to:

  • Functionality

  • Scalability

  • Adaptability

  • Manageability

  • Cost effectiveness


“The network must work” is the absolute bottom line. Because networks are an integral part of enabling individual users to do their jobs, this is essential. It is here that the use of Service Level Agreements (SLAs) is essential. You must know what is expected of the network in order to design it properly.


As your organization grows, the network must be able to keep pace. Your network and its initial design must enable it to expand accordingly. A network that cannot keep pace with the organization's needs is not much use.

Routing summarization is a major factor in the success of designing your network. If you want to ensure your network can scale properly, the summarization is the biggest factor on your success. Without summarization, you will have a flat address design with specific route information for every host being transmitted across the network, a very bad thing in large networks. To briefly review summarization, remember that routers summarize at several levels, as shown in Figure 7-1. For example, hosts are grouped into subnetworks, subnetworks are then grouped into major networks, and these are then consolidated in areas. The network can then be grouped into an autonomous system.


There are many smaller networks that desire to use a “standard” routing protocol such as OSPF. These networks can, for example, have 100 or less routers with a relatively small IP space. In these situations, summarization may not be possible and might not gain much if it were implemented.


Adaptability refers to your network's capability to respond to changes. In most cases, adaptability refers to your network's capability to embrace new technologies in a timely and efficient manner. This becomes extremely important as the network ages because change within networking is racing forward at breakneck speeds. Though it is not necessary to always be on the leading or bleeding edge—there is a lot to be said for letting others find the bugs!

Figure 7-1. Route summarization affects network scalability.


To provide “true” proactive network management is the goal here. The network must have the proper tools and design to ensure you are always aware of its operation and current status.

Cost Effectiveness

In this case, I have saved the true bottom line of network design for last. The reality of life is that budgets and resources are limited, and building or expanding the network while staying within the predetermined budget is always a benefit to your career and proper network design.

Although there are five basic goals of network design that can be followed in any situation, I think there also should be a certain mindset during the process. This mindset is regarding the actual technology you will be using. It is very important to use state-of-the-art technologies whenever possible, though this does not mean to use unproven or inadequately tested technology. The reasoning behind this is that by spending a little extra money up front, you are investing with an eye to the future knowing that the network you are building will be able to grow, from a technological standpoint, longer than otherwise possible.

Network Design Issues

Up until this point, the various network design goals and the methodology needed to make the goals become a reality have been discussed. There are also certain design issues that you must consider when working through the network design process:

  • Reliability. When designing networks, reliability is usually the most important goal, as the WAN is often the backbone of any network.

  • Latency. Another big concern with users occurs when network access requests take a long time to be granted. Users should be notified about a latency problem in the network.

  • Cost of WAN resources. WAN resources are expensive, and as such, frequently involve a tradeoff between cost efficiency and full network redundancy. Usually cost efficiency wins.

  • Amount of traffic. This is a very straightforward consideration. You must be able to accurately determine the amount of traffic that will be on the network in order to properly size the various components that will make it up. As you implement the network, you should also develop a baseline that can be used to project future growth.

  • Allowing multiple protocols on the WAN. The simplicity of IP is of great benefit to any network. For example, by only allowing IP-based protocols on the network you will avoid the unique addressing and configuration issues relating to other protocols.

  • Compatibility with standards or legacy systems. Compatibility is always going to be an issue within your network throughout its life. As a network designer, you need to always keep this in mind as you proceed.

  • Simplicity and easy configuration. Having been a network engineer for many years and involved in network management, this feature is doubly important to me. You might only be involved in the design and implementation of the network and not the management. In that case, the knowledge you will develop will need to be passed on to those who will manage the network. Ensure that you keep the ideas of simplicity and ease of configuration in mind while you develop your design documents for the network.

  • Support for remote offices and telecommuters. In today's telecommunications environment, remote satellite offices are becoming commonplace and require network connectivity, so you must plan accordingly. The estimates say that every day you will see companies increase the number of telecommuters. You must keep this in mind as you determine the placement of network components to ensure that they can handle this requirement when it becomes a priority for your organization.

Network Design Methodology

There are six common steps that can be used to design your OSPF network, or any network for that matter. This are not set in stone and will not guarantee the “perfect” network, but they will provide you with realistic steps and considerations that if taken into account will make for well designed network. These steps will also help you avoid getting caught up in all the “bells and whistles” available in the new-enhanced-ultra-secret-turbo-series-network-equipment which is the answer to all your networking needs.

These steps to designing a network have been proven not only over time, but also through countless networks that have been designed and implemented based upon this standard.

  1. Analyze the requirements.

  2. Develop the network topology.

  3. Determine addressing and naming conventions.

  4. Provision the hardware.

  5. Deploy protocol and IOS features.

  6. Implement, monitor, and maintain the network.

Although your network might not have the technology du jour, it might not really need it if you objectively determine the needs of a network by following this design methodology (as shown in Figure 7-2).

Step 1: Analyze the Requirements

This step will detail the process of determining expectations and then converting those into a real network or explaining why everyone can't have video conferencing on the desktop.


What do you know? Going into Step 1, you know that an OSPF network is required but not what it will need to accomplish for your users or how you will need to physically design the network.

Figure 7-2. Network design methodology.

Granted, the needs of users are always changing, and sometimes they do not even know what they need. There I said it! However, it is true; they know what they want and when they want it, which is always now or yesterday. Nevertheless, from a network design prospective, they do not always know what they need or why they need it.

Nevertheless, you, as the network engineer involved in the design of the network, must still objectively listen and determine user needs. In the end, they are going to be the customers of network, and the customer is always right. You must also take into consideration what the future might hold for them. Therefore, you should ask the users what needs they see themselves having in the future. This question should be directed toward their jobs because it is your responsibility to take their response and turn that into the requirements of the network.

A corporate vision is always important. For example, do the long-range corporate plans include having a Web site? If so, what will it be doing? How about running voice over the network? What about video conferencing; is that going to be a corporate need?

Additional data you might want to consider gathering is the current organization structure, locations, and flow of information within the organization and any internal or external resources available to you. Armed with this information, your networks need analysis, you should then begin determining the cost and benefit analysis. Of course in many cases you will not be able to get all the equipment or bandwidth you think is necessary. Therefore, it is also advisable to create a risk assessment detailing the potential problems or areas of concern regarding the network design.

OSPF Deployment

As you go through the process of determining the network requirements, keep in mind some important questions regarding the requirements of OSPF. The answers to these questions will help you further define the requirements of your OSPF network.

  • How should the OSPF Autonomous System be delineated? How many areas should it have and what should the boundaries be?

  • Does your network and its data need to have built-in security?

  • What information from other Autonomous Systems should be imported into your network?

  • Which sites will have links that should be preferred (lower cost)?

  • Which sites will have links that should be avoided (higher cost)?

Load Balancing with OSPF

As you go through the process of determining the network requirements, keep in mind the load balancing feature of OSPF. In the Cisco implementation of OSPF, any router can support up to four equal-cost routes to a destination. When a failure to the destination is recognized, OSPF immediately switches to the remaining paths.

OSPF will automatically perform load balancing allow equal-cost paths. The cost associated is determined (default) by the interface bandwidth statement unless otherwise configured to maximize multiple path routing.

Before Cisco's IOS release 10.3, the default cost was calculated by dividing 1,000,000,000 by the default bandwidth of the interface. However, with IOS releases after 10.3, the cost is calculated by dividing 1,000,000,000 by the configured bandwidth of the interface as illustrated in Figure 7-3.


In IOS 11.3, this issue has been addressed with the command ospf auto-cost reference bandwidth.

OSPF convergence is extremely fast when compared to other protocols; this was one of the main features included within its initial design. To keep this desirable feature fully functional in your network, you need to consider the three components that determine how long it takes for OSPF to converge:

  • The length of time it takes OSPF to detect a link or interface failure

  • The length of time it takes the routers to exchange routing information via LSAs, rerun the Shortest Path First algorithm, and build a new routing table

  • A built-in SPF delay time of five seconds (default value)

Thus, the average time for OSPF to propagate LSAs and rerun the SPF algorithm is approximately 1 second. Then the SPF delay timer of five seconds must elapse. Therefor OSPF convergence can be a anything from 6 to 46 seconds, depending upon the type of failure, SPF timer settings, size of the network, and size of the LSA database. The worst case scenario is when a link fails but the destination is still reachable via an alternate route, because the 40 second default dead timer will need to expire before the SPF is rerun.

Step 2: Develop the Network Topology

This step will cover the process of determining the networks physical layout. There are generally only two common design topologies: meshed or hierarchical. The following sections take a look at each to see which is the most efficient design for today's networks.


What do you know? Going into Step 2, you've developed a list of the requirements associated with this OSPF network. You have also begun to lay out the financial costs associated with the network based upon this information. These costs could include equipment, memory, and associated media.

Meshed Topology

In a meshed structure, the topology is flat and all routers perform essentially the same function, so there is no clear definition of where specific functions are performed. Network expansion tends to proceed in a haphazard, arbitrary manner. This type of topology is not acceptable to the operation of OSPF. It will not correctly support the use of areas or designated routers.

Hierarchical Topology

In a hierarchical topology, the network is organized in layers that will have clearly defined functions. In this type of network there are three layers:

  • Core Layer. This would make an excellent place for OSPF Backbone Routers that are all connected through area 0. All of these routers would be interconnected, and there should not be any host connections. This is because its primary purpose is to provide connectivity between other areas.

  • Distribution Layer. It is here that you would locate other OSPF areas all connected through Area Border Routers (ABRs) back to the Core Layer (area 0). This is also a good location to begin implementing various network policies such as security, DNS, etc.…

  • Access Layer. This is where the inter-area routers that provide connections to the users would be located. This layer ID is where the majority of the hosts and servers should be connecting to the network.

By using this type of logical layered network design, you will gain some benefits that will help you design the network as shown in Figure 7-4.

The benefits of the OSPF hierarchical topology as implemented in Figure 7-4 are as follows:

Figure 7-4. hierarchical topology.
  • Scalable. Networks can grow easily because functionality is localized so additional sites can be added easily and quickly.

  • Ease of Implementation. This physical topology fits easily into OSPF's logical hierarchy, making network implementation easier.

  • Ease of Troubleshooting. Because functionality is localized, it is easier to recognize problem locations and isolate them.

  • Predictability. Because of the layered approach, the functionality of each layer is much more predictable. This makes capacity planning and modeling that much easier.

  • Protocol Support. Because an underlying physical architecture is already in place if you want to incorporate additional protocols, such as BGP, or if your organization acquires a network running a different protocol, you will be able to easily add it.

  • Manageability. The physical layout of the network lends itself towards logical areas that make network management much easier.

There are other variations of the three-layered hierarchical design that are available are one layer—distributed, hub and spoke—and two layers, but they are beyond the scope of this book. At this point, though, you can see that the three layered hierarchical model fits perfectly into OSPF's logical design, and it is this model on which you will be basing your network design. Before discussing how to implement and design this type of model, you need some basic OSPF backbone design suggestions.

OSPF Backbone Design in the Hierarchical Model

The process of designing the backbone area has been previously discussed, so it will be only briefly reviewed here. Always keep the backbone area as simple as possible by avoiding a complex mesh. Consider using a LAN solution for the backbone. The transit across the backbone is always one hop, latency is minimized, and it is a simple design that converges very quickly. Figure 7-5 illustrates a simple OSPF backbone design.

Figure 7-5. Simple OSPF backbone design.

You know that you should keep users off the backbone because it is only a transit area, but that is not enough. You also need to consider securing your backbone physically. As a network critical shared resource, the routers need to be physically secure. If you use the previously mentioned LAN backbone solution, then securing your network can be relatively easy; just put it in a secure closet or rack as shown in Figure 7-6.

Figure 7-6. Isolate the backbone and secure it both physically and logically.
Areas: Stub, Totally Stubby, or Not-So-Stubby

You will have to design your OSPF network with areas to make the network scalable and efficient. Areas have been discussed in previous chapters, but let's briefly review them at this point. Areas should be kept simple, stubby, with less than 100 (optimally 40-50) routers, and have maximum summarization for ease of routing. The network illustrated in Figure 7-7 demonstrates these suggestions.

Even though these design suggestions are helpful, what are you really going to gain in your network by adding stub areas? Simply put, they will summarize all external LSAs as one single default LSA that applies only to the external links from outside the autonomous system. The stub area border router sees all the LSAs for the entire network and floods them to other stub area routers. They keep the LSA database for the stub area with this additional information and the default external route. Figure 7-8 illustrates the operations in a stub area.

Figure 7-7. network with areas.

Figure 7-8. Stub area operation.

There are also totally stubby areas that you could design within your network. Totally stubby areas are a Cisco-specific feature available within their implementation of the OSPF standard. You can use totally stubby areas in Cisco IOS Release 9.1 and later.

If an area is configured as totally stubby, only the default summary link is propagated into the area by the ABR. It is important to note that an ASBR cannot be part of a totally stubby area, nor can redistribution of routes from other protocols take place in this area. Figure 7-9 shows the operations in an example totally stubby area.

Figure 7-9. Totally stubby area operation.

The main difference between a stub area and a not-so-stubby area (NSSA) is that the NSSA imports a limited number of external routes. The number of routes is limited to only those required to provide connectivity between backbone areas. You may configure areas that redistribute routing information from another protocol to the OSPF Backbone as a NSSA. NSSAs are discussed later in this chapter.

Example of an OSPF Network with a Hierarchical Structure

To design this type of model network, you should gather a list of the different locations requiring network connectivity within your organization. For purposes of this example and ease of understanding, let's consider your organization, as an international corporation, and you have been tasked with building its OSPF network within the United States. You have determined that you have the following divisions (each with various business units within it), as shown in the following hierarchy, which groups the units by location and then by function.

  • Headquarters: Washington D.C. (all in the same building)

    • United States Exe ecutives

    • Legal department

  • Human Resources (located at headquarters but in different building)

    • Payroll

    • Benefits

    • Corporate Recruiting

  • Sales & Marketing

    • Northern division (6 offices)

    • Southern division (6 offices)

    • Eastern division (5 offices)

    • Western division (7 offices)

  • Manufacturing

    • Engineering located in western U.S.

    • Widgets division located in northern U.S. (4 factories)

    • Gidgets division located in southern U.S. (3 factories)

    • Tomgets division located in western U.S. (3 factories)

The listed units will become the basis of OSPF areas. Contained within the areas will be OSPF inter-area routers that connect to the various hosts.

Of these groupings, you should select essential locations at which to locate the backbone routers. For our example, you know that Headquarters will have a backbone router that will be connected to area 0. You have been given several requirements based upon traffic flow and corporate requirements:

  • All divisions must be within the same area, regardless of geographic location

  • All divisions must be able to connect to headquarters

  • In our company, area 0 links all major continental locations throughout the globe

  • All region clusters must have alternate routes

  • Internet connectivity for entire company

  • If backbone router fails, network operation within U.S. division must continue

  • Engineering and Manufacturing must communicate quickly and easily

Begin separating the sites into areas and picking one location within each area at which will reside the area border router (ABR). This will result in a proposed set of OSPF routers deployed as follows:

  • Backbone router (area 0): Connects to global area 0

  • ABR (area 1): Executives and legal department

  • ABR (area 2): Human resources

  • ABR (area 3): Sales

  • ABR (area 4): Manufacturing and Engineering

  • ASBR: Internet connectivity

The remaining sites will each be assigned an inter-area router to connect them to the network. One main site within each geographical area will be the hub site for that geographic area, thereby reducing bandwidth costs.

At this point, you should have your organization separated into areas or layers and an overall topology map laid out. Figure 7-10 illustrates the example network described up to this point.

I want to throw out a couple of disclaimers here before people start tearing up my example. First, remember requirement number 1 (All divisions must be within the same area, regardless of geographic location). Second, there are many ways of designing a network and this is just one way and one person's opinion. Third, there is no substitute for actual network design experience, because everyone makes mistakes. Fourth, now that you think you have a solid network design, have someone else look at it and consider modeling it in a software package such as NetSys from Cisco.

Step 3: Determine Addressing & Naming Conventions

Step 3 covers the actual process of assigning the overall network-addressing scheme. By assigning blocks of addresses to portions of the network, you are able to simplify addressing, administration, routing and increase scalability.

Because OSPF supports variable-length subnet masking (VLSM), you can really develop a true hierarchical addressing scheme. This hierarchical addressing results in very efficient summarization of routes throughout the network. VLSM and CIDR were discussed at great length earlier in the book, and it is in this step of designing your OSPF network that you should begin applying these two techniques.

Figure 7-10. Proposed network design: topology map.


What do you know? Coming into Step 3, you have determined your network's requirements and developed a physical network topology. You have continued to keep track of the costs both one time and recurring while planning. In this step, you will determine the addressing and naming conventions that you plan on using.

Public or Private Address Space

A good rule of thumb to remember when determining whether to use public or private address space is that your address scheme must be able to scale enough to support a larger network because your network will most likely continue to grow.

Now you must determine what range of IP addresses you are going to deploy within your network. The first question you need to answer is: “Do I have public address space assigned to me by the InterNIC or am I going to be using private address space as specified in RFC 1918 and 1597?”

Either choice will have its implications on the design of your network. By choosing to use private address space and with having to connect to the Internet, you will be faced with having to include the capability to do address translation as part of your network design.

To further complicate the issue, you might also have to deal with a preexisting addressing scheme and/or the need to support automatic address assignment through the use of Dynamic Host Configuration Protocol (DHCP) or Domain Naming System (DNS). That type of technology is beyond the scope of this book and will not be covered.


DHCP is a broadcast technique used to obtain an IP address for an end station.

DNS is used for translating the names of network nodes into IP addresses.

Figure 7-11 shows a good example of how to lay out the IP addresses and network names for the example network.

Figure 7-11. Address and naming conventions
Plan Now for OSPF Summarization

The operation and benefits of route summarization have been discussed in previous chapters. At this point though, you should realize the importance of proper summarization on your network. The OSPF network in Figure 7-12 does not have summarization turned on. Notice that by not using summarization, every specific-link LSA will be propagated into the OSPF backbone and beyond, causing unnecessary network traffic and router overhead. Whenever an LSA is sent, all affected OSPF routers will have to recompute their LSA database and routes using the SPF algorithm.

OSPF will provide some added benefits if you design the network with summarization. For example, only summary-link LSAs will propagate into the backbone (area 0). This is very important because it prevents every router from having to rerun the SPF algorithm, increases the network's stability, and reduces unnecessary traffic. Figure 7-13 demonstrates this principle.

Figure 7-12. No route summarization will cause network problems.

Figure 7-13. Proper route summarization improves OSPF network stability.

IP addresses in an OSPF network should be grouped by area, and you can expect to see areas with some or all of the following characteristics:

  • Major network number(s)

  • Fixed subnet mask(s)

  • Random combination of networks, subnets, and host addresses

It is important that hosts, subnets, and networks be allocated in a controlled manner during the design and implementation of your OSPF network. The allocation should be in the form of contiguous blocks that are adjacent so OSPF LSAs can easily represent the address space. Figure 7-14 shows an example of this.


Allocation of IP addresses should be done in powers of two so that these “blocks” can be represented by a single summary link advertisement. Through the use of the area range command you will be able to summarize large contiguous blocks of addresses. In order to minimize the number of blocks you should make them as large as possible.

Figure 7-14. Configure OSPF for summarization.
Bit Splitting

Bit splitting is also a very useful technique discussed in previous chapters, and you might now want to consider using it if you have to split a large network number across more than one OSPF area. Simply put, bit splitting borrows some subnet bits for designated areas, as discussed in Chapter 5, “The Fundamentals of OSPF Routing & Design.”

To differentiate two areas, split one bit.

To differentiate 16 areas, split four bits.

Figure 7-15 demonstrates this bit splitting technique.

Figure 7-15. Bit splitting address space.

The example uses four bits for the area and uses 32-bit numbers to represent four of the 16 possible areas. The area numbers appear in dotted decimal notation and look like subnet numbers. In fact, the 32-bit area numbers correspond to the summary advertisement that represents the area.

Map OSPF Addresses for VLSM

Variable-length subnet masking (VLSM) has been discussed previously, so this section will not dwell on it too deeply. But suffice it to say that the reasons behind it are similar to bit splitting. Remember to keep small subnets in a contiguous block and increase the number of subnets for a serial meshed network. Figure 7-16 provides a good example of VLSM OSPF mappings.

Discontiguous Subnets

Subnets become discontiguous when they are separated by one or more segments represented by a different major network number. Discontiguous subnets are supported by OSPF because subnets masks are part of the link-state database.

Consider the following example: The OSPF backbone area 0 could be a class C address, while all the other areas could consist of address ranges from a class B major network as illustrated in Figure 7-17.

Figure 7-16. VLSM OSPF mappings.

Figure 7-17. network with discontiguous subnets.


OSPF supports discontiguous subnets regardless of whether summarization is configured within the network. Although, everything within your network will route better and have a more stable design if summarization is configured.

Naming Schema

The naming scheme used in your network should also be designed in a systematic way. By using common prefixes for names within an organization, you will make the network much easier to manage and more scalable. All of this is shown in Figure 7-11.

It is also important to carry a naming convention into your routers as well. This will assist everyone dealing with your network because the router names actually hold some meaning, instead of an abstract like an order number.

Step 4: Provision the Hardware

In Step 4, you must use vendor documentation, salesmen, and system engineers to determine the hardware necessary for your network. This is for both LAN and WAN components.

For LANs, you must select and provision router models, switch models, cabling systems, and backbone connections.

For WANs, you must select and provision router models, modems, CSUs/DSUs, and remote access servers.


What do you know? Coming into Step 4 you have determined your network requirements, developed a physical network topology, and laid out your addressing and naming scheme for the network. In this step, you will begin selecting and provisioning the necessary network equipment to implement the design.

When selecting and provisioning routing or switching hardware, consider the following areas:

  • Expected CPU usage

  • Minimum RAM

  • BUS budget

  • Forwarding budget

  • Required Interface Types and Density

Step 5: Deploy Protocol and IOS Features

In Step 5, you will need to deploy the more specific features possible by the OSPF protocol and the routers IOS. It is not necessary to have a network with every single option turned, nor is it something you are likely to see. Some of the features you should consider implementing are covered in the two sections that follow.


What do you know? Coming into Step 5 you have determined your network requirements, developed a physical network topology, laid out your addressing and naming scheme, and begun the provisioning of the network equipment. In this step, you will begin deploying the OSPF and IOS features that you will be using within the network.

OSPF Features

This area covers some of the features of OSPF (authentication and route redistribution between protocols) that you should consider deploying within your network. There can be only one choice concerning which feature should be first for you to consider.

Protecting corporate resources, security, policing the network, ensuring correct usage of the network, authentication—they are all different labels for a similar need within every network: network security. Network security should be built into the network from day one, not added as an afterthought. Mistakes have already happened in the networking environment you know today. Nevertheless, how could they not with the almost required Internet presence and “www” logo seen on almost every business card? The open unsecure protocols such as Simple Mail Transfer Protocol (SMTP) or Simple Network Management Protocol (SNMP) are essential for business and network management, though they are also vulnerable for exploitation. Hopefully, the respective working groups will get moving towards solving this problem. All is not doom and gloom though, as OSPF comes with built-in authentication—the way it should be!

OSPF's built-in authentication set is extremely useful and flexible. In the OSPF specification, MD5 is the only cryptographic algorithm that has been completely specified. The overall implementation of security within OSPF is rather straightforward. For example, you assign a key to OSPF. This key can either be the same throughout your network or different on each router's interface or a combination of the two. The bottom line is that each router directly connected to each other must have the same key for communication to take place. Further detailed discussion of this OSPF feature will take place in later chapters.

Route redistribution is another very useful Cisco IOS software feature. To review redistribution is the exchange of routing information between two different routing processes (protocols). This feature should be turned on in your routers if you have separate routing domains within your Autonomous System and you need to exchange routes between them.

For example, the engineering department might be running OSPF and the accounting department might be running IGRP as shown in Figure 7-18.

Figure 7-18. Redistributing routing information between protocols.

Figure 7-18 depicts one router connecting the two separate touring processes (protocols), which need to share routing information. This sharing process is called redistribution. The router shown in Figure 7-18 is configured to run both IGRP and OSPF routing.


When routes are redistributed between major networks, no subnet information is required.

IOS Features

Some of the features of the IOS that you should consider deploying within your network are as follows:

  • Access lists

  • Queuing

  • Route maps

  • Limit of certain routes from being propagated

Step 6: Implement, Monitor, and Manage the Network

The last step is also the first step to continually managing the growth of your network. Some time is spent on this subject later in the chapter, but Chapter 9, “Managing Your OSPF Network,” will delve more deeply into the network management arena. In the context of this step you should consider the following actions:

  • Using network management tools for monitoring

  • Performing proactive data gathering

  • Knowing when to scale the network to meet new demands (new hardware, upgrade circuit speeds, support new applications)


What do you know? Coming into Step 6 you have determined your network requirements, developed a physical network topology, laid out your addressing and naming scheme, provisioned your network equipment, and deployed the necessary OSPF and IOS features. In this step, you will begin to implement the network, institute monitoring, and engage in proactive network management.

Network Management and Monitoring Applications

Network management applications that use Simple Network Management Protocol (SNMP) provide a useful array of tools to control internetwork support costs:

  • Cisco debug and show commands

  • Syslogd

  • Protocol analyzers

  • DNS

  • TFTP and FTP

  • DHCP and BOOTP

  • Telnet


  • Cisco Works (Router configuration management, network analysis)


< Back Contents Next >

Save to MyCKS


Breaking News

One of the primary architects of OpenCable, Michael Adams, explains the key concepts of this initiative in his book OpenCable Architecture.

Expert Advice

Ralph Droms, Ph.D., author of The DHCP Handbook and chair of the IETF Dynamic Host Configuration Working Group, guides you to his top picks for reliable DHCP-related information.

Just Published

Residential Broadband, Second Edition
by George Abe

Introduces the topics surrounding high-speed networks to the home. It is written for anyone seeking a broad-based familiarity with the issues of residential broadband (RBB) including product developers, engineers, network designers, business people, professionals in legal and regulatory positions, and industry analysts.


From the Brains at InformIT


Contact Us


Copyright, Terms & Conditions


Privacy Policy


© Copyright 2000 InformIT. All rights reserved.