cc/td/cpress/design
hometocprevnextglossaryfeedbacksearchhelp

Table of Contents

Designing & Implementing an OSPF Network

Designing & Implementing an OSPF Network

"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 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?

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

"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.

Scalability

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.


Note 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

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.

:on0407.fm

Manageability

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:

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).


Figure 7-2: Network design methodology.


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.


Note What do you know? Going in
to 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.

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.

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.


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

Figure 7-3: OSPF costs.


OSPF Convergence

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:

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.


Note 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 associa
ted 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:

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.


Figure 7-4: OSPF hierarchical topology.


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

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.


Figure 7-7: OSPF network with areas.


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-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.

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:

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:

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.


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


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.


Note 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.


Note 
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.


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


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-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:

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.


Figure 7-14: Configure OSPF for summarization.



Note 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.

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.


Figure 7-16: 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-17: OSPF network with discontiguous subnets.



Note 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.


Note 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:

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.


Note 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.


Note 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:

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:


Note 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 e
ngage 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:

Configuring OSPF on Cisco Routers

OSPF typically requires coordination among many internal routers, area border routers (routers connected to multiple areas), and autonomous system boundary routers. At a minimum, OSPF-based routers, or access servers, can be configured with all default parameter values, no authentication, and interfaces assigned to areas. If you intend to customize your environment, you must ensure coordinated configurations of all routers.

To configure OSPF, complete the tasks in the following sections. Enabling OSPF is mandatory; the other tasks are optional, but they might be required for your network.

Enabling OSPF on an Inter-Area Router

As with other routing protocols, the enabling of OSPF on Cisco routers requires a few steps before the process begins:

    1. You must determine the Process ID under which OSPF will be running within your network. It is suggested that this Process ID be unique from any other OSPF network to which you might be connecting.

    2. You must specify the range of addresses that are to be associated with the OSPF routing process. This is part of one command that must also include the area with which this range of addresses is to be associated.

Now that you have determined how the OSPF process should be configured, you need to start configuring the router. Perform the following tasks, starting in global configuration mode:

    1. Enable OSPF routing, which places you in router configuration mode. You will do this with the following command: router ospf process-id.

    2. Define an interface on which OSPF runs, and define the area ID for that interface. You will do this with the following command: network address wildcard-mask area area-id.

If this was an inter-area OSPF router, then the process for configuring it for OSPF would now be complete. There are a few subtle differences when configuring the different types of OSPF routers, as described in the next few sections.

Configuring an Area Border Router (ABR)

The process for configuring an ABR for OSPF is essentially the same as described in the preceding section "Enabling OSPF on an Inter-Area Router" with just a few minor additions:

    1. Before starting the OSPF routing process, you need to decide on a few things about how OSPF is going to be configured for OSPF in your network. These considerations include: Deciding what OSPF routing process ID you want to assign to your network and deciding if you want OSPF to determine which router becomes the Designated Router (DR) and Backup Designated Router (BDR). The second consideration might require you to decide upon setting a loopback interface. If you do decide to configure a loopback interface then please refer to the section "Creating a Loopback Interface" later in this chapter for specific details.

    2. Turn on the OSPF routing process with the router ospf process-id command as described in the previous section on "Enabling OSPF on an Inter-Area Router."

    3. Assign the appropriate network statements to the OSPF routing process with the correct area ID, for example:

router ospf 109 
network 130.10.8.0 0.0.0.255 area 0 
network 172.25.64.0 0.0.0.255 area 1 

    4. Is the area going to be a stub area? If so, enter the area area-id stub [no-summary] command, which defines a stub area. You will also need to enter the area area-id default-cost cost command, which assigns a specific cost. Some additional commands for areas that you might want to consider are covered in Chapter 6, "Advanced OSPF Design Concepts."

    5. You will want to add the area range command so that the networks within each area can be properly summarized, for example:

router ospf 109 
network 130.10.8.0 0.0.0.255 area 0 
network 172.25.64.0 0.0.0.255 area 1 
area 1 range 130.10.8.0 255.255.255.0 

    6. Determine if you are going to use any optional OSPF parameters. You do not need to decide now to use any of these options, but be aware of them as they can help your OSPF network. Although many of these have been discussed already, the following list highlights a few of the more significant optional parameters in command syntax:

area area-id authentication 
area area-id authentication message-digest 
ip ospf authentication-key 
ip ospf hello-interval 
ip ospf dead-interval 
timers spf spf-delay spf-holdtime 

You can use the show ip ospf border-routers command to see the area border routers within your network. This command is explained in more detail in Chapter 8, "Monitoring & Troubleshooting an OSPF Network."

Configuring an Autonomous System Boundary Router (ASBR)

The process of configuring an autonomous system boundary router (ASBR) for OSPF is very similar to how you would configure an ABR:

    1. You should already know the OSPF Process ID, whether or not you need a loopback interface, and which optional OSPF parameters you are going to be using.

    2. Turn on the OSPF routing process as described previously in the section "Enabling OSPF on an Inter-Area Router." Again, you will use the router ospf process-id command.

    3. Assign the appropriate network statements to the OSPF routing process with the correct Area ID, for example:

router ospf 109 
network 130.10.8.0 0.0.0.255 area 0 
network 172.25.64.0 0.0.0.255 area 1 

    4. Then you will want to add the area range command so that the networks within each area can be properly summarized, for example:

router ospf 109 
network 130.10.8.0 0.0.0.255 area 0 
network 172.25.64.0 0.0.0.255 area 1 
area 1 range 130.10.8.0 255.255.255.0 

    5. At this point, you will want to begin the redistribution process between your OSPF autonomous system and the external autonomous system to which the ASBR is providing connectivity, for example:

router ospf 109 
redistribute rip subnets metric-type 1 metric 12 
network 130.10.8.0 0.0.0.255 area 0 
network 172.25.64.0 0.0.0.255 area 1 
area 1 range 130.10.8.0 255.255.255.0 
router rip 
network 128.130.0.0 
passive interface s 0 
default-metric 5 

You can use the show ip ospf border-routers command to see the area border routers within your network. This command is explained in more detail in Chapter 8, "Monitoring & Troubleshooting an OSPF Network."

Configuring a Backbone Router

The process of configuring an OSPF backbone router for OSPF is very similar to how you would configure an ABR:

    1. You should already know the OSPF Process ID, whether or not you need a loopback interface, and which optional OSPF parameters you are going to be using.

    2. Turn on the OSPF routing process as described previously in the section "Enabling OSPF on an Inter-Area Router." Again, you will use the router ospf process-id command.

    3. Assign the appropriate network statements to the OSPF routing process with the correct Area ID, for example:

router ospf 109 
network 130.10.8.0 0.0.0.255 area 0 
network 172.25.64.0 0.0.0.255 area 1 

    4. Then you will want to add the area range command so that the networks within each area can be properly summarized, for example:

router ospf 109 
network 130.10.8.0 0.0.0.255 area 0 
network 172.25.64.0 0.0.0.255 area 1 
area 1 range 130.10.8.0 255.255.255.0 

Configuring a Simplex Ethernet or Serial Interface

Because simplex interfaces between two devices on an Ethernet represent only one network segment, for OSPF you must configure the transmitting interface to be a passive interface. This prevents OSPF from sending hello packets for the transmitting interface. Both devices are able to see each other via the hello packet generated for the receiving interface.

This means that the suppression of sending hello packets is required on the specified interface. This is accomplished using the following command:

passive interface type number 

Note Why are they called simplex interfaces? Simplex means
half duplex, and this means they typically have one transmitter. However, the newer devices have interfaces that allow full duplex, which means fewer collisions during transmissions. Most interfaces default to simplex.

Configuring OSPF Tunable Parameters

Cisco's OSPF implementation enables you to alter certain interface-specific OSPF parameters, as needed. You are not required to alter any of these parameters, but some interface parameters must be consistent across all routers in an attached network. Those are the parameters set by the following commands:

ip ospf hello-interval 
ip ospf dead-interval 
ip ospf authentication-key 
timers spf spf-delay spf-holdtime 

Therefore, be sure that if you do configure any of these parameters, the configurations for all routers on your network have compatible values.

More detailed information regarding tunable OSPF parameters was previously covered in Chapter 6, "Advanced OSPF Design Concepts." Remember that the hello packet defaults to being sent every 10 seconds on broadcast networks (Ethernet) and every 30 seconds on nonbroadcast networks (Frame Relay).

In interface configuration mode, specify any of the interface parameters as needed for your network as shown in Table 7-1.


Table 7-1:
Command Task

ip ospf cost cost

Explicitly specify the cost of sending a packet on an OSPF interface

ip ospf retransmit-interval seconds

Specify the number of seconds between link-state advertisement retransmissions for adjacencies belonging to an OSPF interface

ip ospf transmit-delay seconds

Set the estimated number of seconds it takes to transmit a link-state update packet on an OSPF interface

ip ospf priority number

Set priority to help determine the OSPF designated router for a network

ip ospf hello-interval seconds

Specify the length of time, in seconds, between hello packets the Cisco IOS software sends on an OSPF interface

ip ospf dead-interval seconds

Set the number of seconds that a device's hello packets must not have been seen before its neighbors declare the OSPF router down

ip ospf authentication-key key

Assign a specific password to be used by neighboring OSPF routers on a network segment that is using OSPF's simple password authentication

ip ospf message-digest-key keyid md5 key

Enable OSPF MD5 authentication

Tunable OSPF parameters

Configuring Route Calculation Timers

You can configure the delay time between when OSPF receives a topology change and when it starts a shortest path first (SPF) calculation. You can also configure the hold time between two consecutive SPF calculations. This command was added to prevent routers from computing new routing tables. This is important if you are running OSPF in a very active network that experiences a lot of interface changes or other occurrences which would cause an LSA to be sent, such as a rapidly flapping serial line.

To set the values, perform the following task in router configuration mode:

timers spf spf-delay spf-holdtime 

Creating a Loopback Interface

As previously discussed, the use of a loopback interface will force the selection by OSPF of its router ID. The default for Cisco routers is loopback interface and then the highest IP address assigned to an interface. The use of a loopback interface enables you to assign the router ID. This can be very beneficial. Because a loopback interface is not a physical interface, like Ethernet, you must create it.

You can configure a loopback interface by entering the interface loopback 0 command in the router configuration mode. The following example demonstrates the process:

OSPF_Router# conf t 
Enter configuration commands, one per line. End with CNTL/Z. 
OSPF_Router(config)# interface loopback 0 
OSPF_Router(config-if)# ip address 10.251.11.1 255.255.255.255 
OSPF_Router(config-if)# description Configured to be OSPF Router ID 

Configuring OSPF for Different Network Types

As previously discussed, OSPF classifies different media into three types of networks as a default. Each of these networks requires a slightly different configuration to optimize the performance of OSPF. This section covers the methods and procedures that are needed in order to configure OSPF over different physical networks, such as the following:

One of the most flexible features of OSPF is that you can configure your network as either a broadcast or a nonbroadcast multiaccess network. OSPF will respond accordingly.

X.25 and Frame Relay provide an optional broadcast capability that can be configured using the map command to allow OSPF to run as a broadcast network. This command is useful if you are running a meshed network.

The specific X.25 and Frame Relay commands are outside the scope of this book. If additional information is required, see the x25 map and frame-relay map command descriptions in Cisco's Wide-Area Networking Command Reference for more details.

Configuring your OSPF network type is one of the most functional features of OSPF. Everyone realizes that OSPF is not the perfect protocol, in fact, there will be never a protocol suitable for every situation. The strength of OSPF lies in its capability to be customized to meet certain network design requirements. The following sections will assist your understanding of customizing OSPF to your network's design.

Configuring OSPF for Broadcast or Nonbroadcast Multiaccess Networks

You have the choice of configuring your OSPF network type as either broadcast or nonbroadcast multiaccess (X.25), regardless of the default media type. For example, it does not matter if you have a broadcast media type, such as Ethernet, because you can still configure it as nonbroadcast if you so desire.

Using this feature, you can configure broadcast networks as nonbroadcast multiaccess networks when, for example, you have routers in your network that do not support multicast addressing.

You also can configure nonbroadcast multiaccess networks (such as X.25, Frame Relay, and SMDS) as broadcast networks. This feature saves you from having to configure neighbors, as described in the section "Configuring OSPF for Nonbroadcast Networks," later in this chapter.

Why would it be beneficial not to have a neighbor? This is a very odd statement because OSPF utilizes neighbors quite extensively. Assume, for example, that you have a point-to-point network. By not using neighbors you can reduce router memory and processor usage since there is only one other router to talk with.

Configuring OSPF for Nonbroadcast Networks

Because there might be many routers attached to an OSPF network, a designated router is selected for the network. You must use special configuration parameters in the designated router selection if the broadcast capability is not configured.

These parameters need only be configured in those devices that are eligible to become the Designated Router (DR) or Backup Designated Router (BDR).


Note Any device running OSPF is eligible to become the DR or BDR unless its priority value is set to zero.

To configure routers that connect to nonbroadcast networks, you can specify the following neighbor parameters, as required:

These features enable you to determine several OSPF operating variables in just one router that will be propagated to its neighbors that are identified in the following configuration command:

neighbor ip-address [priority number] [poll-interval seconds] 

Configuring OSPF for Point-to-Multipoint Networks

An OSPF point-to-multipoint interface is defined as a numbered point-to-point interface with the router having one or more OSPF neighbors. Because of this, OSPF will create multiple host routes.

An OSPF point-to-multipoint network has the following benefits compared to nonbroadcast multiaccess and point-to-point networks:

When you decide to configure nonbroadcast, multiaccess networks as either broadcast or nonbroadcast networks, OSPF assumes that there are virtual circuits from every router to every router or that you are running a fully-meshed network.

This is not true in many cases because you might only have a partially-meshed network because the cost required to fully mesh the network is prohibitive. In this case, you can configure the OSPF network type as a point-to-multipoint network. Routing between two routers not directly connected will go through the router that has virtual circuits to both routers.


Note If you are going to configure OSPF's network type as point-to-multipoint then you should not configure any neighbors. Because of the presence of virtual links, this will cause additional unneeded traffic and potential routing problems. You might want to refer to the case study provided in Chaptre 5, "The Fundamentals of OSPF Routing & Design," for more information.

To configure your OSPF network type on a specific interface (int s0), enter the following command in interface configuration mode:

ip ospf network {broadcast|non-broadcast|point-to-multipoint} 

Figure 7-19 shows an example of OSPF in a point-to-multipoint networking environment.


Figure 7-19: Point-to-multipoint network example.



Note Remember there are
no Designated Routers or Backup Designated Routers on a point-to-multipoint subnet. The OSPF Hello protocol will find neighbors.

Referring to the setup in Figure 7-19 and for demonstration purposes, assume the following scenario:

Given this setup, the configurations for Matt, Wayne, Robin, and Ben would be as follows:

Matt's Configuration

hostname Matt 
! 
interface serial 1 
ip address 10.0.0.2 255.0.0.0 
ip ospf network point-to-multipoint 
encapsulation frame-relay 
frame-relay map ip 10.0.0.1 201 broadcast 
frame-relay map ip 10.0.0.3 202 broadcast 
frame-relay map ip 10.0.0.4 203 broadcast 
! 
router ospf 1 
network 10.0.0.0 0.0.0.255 area 0 

Wayne's Configuration

hostname Wayne 
! 
interface serial 0 
ip address 10.0.0.1 255.0.0.0 
ip ospf network point-to-multipoint 
encapsulation frame-relay 
frame-relay map ip 10.0.0.2 101 broadcast 
frame-relay map ip 10.0.0.4 102 broadcast 
! 
router ospf 1 
network 10.0.0.0 0.0.0.255 area 0 

Robin's Configuration

hostname Robin 
! 
interface serial 3 
ip address 10.0.0.4 255.0.0.0 
ip ospf network point-to-multipoint 
encapsulation frame-relay 
clockrate 1000000 
frame-relay map ip 10.0.0.1 401 broadcast 
frame-relay map ip 10.0.0.2 402 broadcast 
! 
router ospf 1 
network 10.0.0.0 0.0.0.255 area 0 

Ben's Configuration

hostname Ben 
! 
interface serial 2 
ip address 10.0.0.3 255.0.0.0 
ip ospf network point-to-multipoint 
encapsulation frame-relay 
clockrate 2000000 
frame-relay map ip 10.0.0.2 301 broadcast 
! 
router ospf 1 
network 10.0.0.0 0.0.0.255 area 0 

Configuring OSPF Area Parameters

Cisco OSPF software enables you to configure several area parameters. These area parameters include authentication, defining stub areas, and assigning specific costs to the default summary route.

Authentication allows password-based or key-based protection against unauthorized access to an area.

Stub areas are areas into which information on external routes is not sent. Instead, there is a default external route generated by the area border router, into the stub area for destinations outside the autonomous system.

To further reduce the number of link-state advertisements sent into a stub area, you can configure no-summary on the ABR to prevent it from sending summary link advertisement (LSA Type 3) into the stub area.

In router configuration mode, specify any of the following area parameters as needed for your network:

Configuring OSPF Not-So-Stubby Areas (NSSAs)

NSSAs are similar to regular OSPF stub areas, except that an NSSA does not flood Type 5 external LSAs from the core into the not so stubby area, but it has the capability to import AS external routes in a limited fashion within the area.

Prior to NSSA, the connection between the corporate site border router and the remote router could not be run as OSPF stub area because routes for the remote site cannot be redistributed into stub area. A simple protocol like RIP is usually run to handle the redistribution. This has meant maintaining two routing protocols. With NSSA, you can extend OSPF to cover the remote connection by defining the area between the corporate router and the remote router as an NSSA. Figure 7-20 illustrates the overall operation of an OSPF NSSA.


Figure 7-20: OSPF NSSA overview.


NSSA allows importing of Type 7 AS external routes within NSSA area by redistribution. These Type 7 LSAs are translated into Type 5 LSAs by NSSA ABR which are flooded throughout the whole routing domain. Summarization and filtering are supported during the translation.

If you are an Internet Service Provider (ISP), or a network administrator who has to connect a central site using OSPF to a remote site that is using a different protocol, such as RIP or EIGRP, you can use NSSA to simplify the administration of this kind of topology. Before NSSA, the connection between the corporate site ABR and the remote router used RIP or EIGRP. This meant maintaining two routing protocols. Now, with NSSA, you can extend OSPF to cover the remote connection by defining the area between the corporate router and the remote router as an NSSA, as shown in Figure 7-21. You cannot expand the normal OSPF area to the remote site because the Type 5 external will overwhelm both the slow link and the remote router.


Figure 7-21: Reasons to use the OSPF NSSA option.


NSSA Implementation Considerations

Evaluate the following considerations before implementing NSSA:

If possible, avoid using explicit redistribution on NSSA ABRs because confusion might result over which packets are being translated by which router.

In router configuration mode, specify the following area parameters as needed to configure and define the OSPF NSSA:

area area-id nssa [no-redistribution] [default-information-originate] 

In router configuration mode on the ABR, specify the following command to control summarization and filtering of Type 7 LSA into Type 5 LSA during the translation process:

summary address prefix mask [not advertise] [tag tag] 

Configuring Route Summarization Between OSPF Areas

In OSPF, an ABR will advertise addresses that describe how to reach networks (routes) from one area into another area. Route summarization is the consolidation of these advertised addresses. This feature causes a single summary route to be advertised to other areas by an ABR, thereby representing multiple routes in a single statement. This has several benefits, but the primary one is a reduction in the size of routing tables.

If the network numbers in an area are assigned in such a way that they are contiguous, you can configure the ABR to advertise a summary route that covers all the individual networks within the area that fall into the range specified by the summary route.

To specify an address range, perform the following task in router configuration mode:

area area-id range address mask 

Configuring Route Summarization when Redistributing Routes into OSPF

When redistributing routes from other protocols into OSPF, each route is advertised individually in an external link-state advertisement (LSA). However, you can configure OSPF to advertise a single route for all the redistributed routes that are covered by a specified network address and mask. Doing so helps decrease the size of the OSPF link-state databases and in turn the routing table. The same benefits discussed in route summarization between areas is applicable here, only now the routes are coming from an external source.

To have OSPF advertise one summary route for all redistributed routes covered by a network address and mask, perform the following task in router configuration mode:

summary-address address mask 

Generating a Default OSPF Route during Redistribution

Whenever you specifically configure redistribution of routes from a different routing protocol or autonomous system into an OSPF routing domain, the router in question automatically becomes an autonomous system boundary router (ASBR) because it is doing the redistribution. You can force an ASBR to generate a default route into an OSPF routing domain as illustrated in Figure 7-22.


Figure 7-22: ASBRs consolidate routes.


However, an ASBR does not, by default, generate a default route into the OSPF routing domain. To force the ASBR to generate a default route, perform the following task in router configuration mode:

default-information originate [always] [metric metricvalue] [metric-type type-value] [route-map map-name] 

Figure 7-23 shows a good example of when you would generate a default during the use of an OSPF stub area.


Figure 7-23: Manually configuring a path to the OSPF stub network.


The most common method of generating a default route is through the use of a static route statement within the router. When using a static route paired with a passive interface, you will stop routing updates and enable the path to have a lower administrative distance.

Configuring Lookup of DNS Names

You can configure OSPF to look up Domain Naming System (DNS) names for use in all OSPF show command displays. This feature makes it easier to identify a router, because it is displayed by name rather than by its router ID or neighbor ID. Through the use of this command you will find that some of the more cryptic components displayed by OSPF will make a bit more sense, especially if you have used a good naming system, as previously discussed.

To configure OSPF to do a DNS name lookup, perform the following task in the routers global configuration mode:

ip ospf name-lookup 

Forcing the Router ID Choice with a Loopback Interface

OSPF uses the largest IP address configured on the interfaces as its router ID. If the interface associated with this IP address is ever unavailable, or if the address is removed, the OSPF process must recalculate a new router ID and flood all its routing information out its interfaces.

If a loopback interface is configured with an IP address, OSPF will default to using this IP address as its router ID, even if other interfaces have larger IP addresses. Because loopback interfaces never go down, greater stability throughout your OSPF network is achieved.


Note You cannot tell OSPF to use a particular interface as its router ID. It has built in defaults that force it to accept a loopback interface first then the highest IP address on any interface.

Disable Default OSPF Metric Calculation Based on Bandwidth

In Cisco IOS Release 10.2 and earlier, OSPF assigned default metrics to router interfaces regardless of the interface bandwidth. It gave both 64K and T1 links the same metric (1562), and thus required an explicit ip ospf cost command in order to take advantage of the faster link.

In Cisco IOS Release 10.3 and later, by default, OSPF calculates the OSPF metric for an interface according to the bandwidth statement of the interface. You can see this in the following excerpt from a router:

OSPF_Router# sho int s0 
Serial0 is down, line protocol is down 
Hardware is QUICC Serial (with onboard CSU/DSU) 
Description: OSPF uses the Bandwidth Statement on EVERY Interface 
Internet address is 10.251.20.1/24 
MTU 1500 bytes, BW 56 Kbit, DLY 20000 usec, rely 255/255, load 1/255 
Encapsulation FRAME-RELAY IETF, loopback not set, keepalive set (10 sec) 
LMI enq sent 0, LMI stat recvd 0, LMI upd recvd 0, DTE LMI down 
LMI enq recvd 0, LMI stat sent 0, LMI upd sent 0 
LMI DLCI 0 LMI type is ANSI Annex D frame relay DTE 
Broadcast queue 0/64, broadcasts sent/dropped 0/0, interface broadcasts 0 
Last input never, output never, output hang never 
Last clearing of "show interface" counters 00:02:17 
Queueing strategy: fifo 
Output queue 0/40, 0 drops; input queue 0/75, 0 drops 
5 minute input rate 0 bits/sec, 0 packets/sec 
5 minute output rate 0 bits/sec, 0 packets/sec 
0 packets input, 0 bytes, 0 no buffer 
Received 0 broadcasts, 0 runts, 0 giants 
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
0 packets output, 0 bytes, 0 underruns 
0 output errors, 0 collisions, 5 interface resets 
0 output buffer failures, 0 output buffers swapped out 
0 carrier transitions 
DCD=down DSR=down DTR=up RTS=up CTS=up 

For example, a 64K link gets a metric of 1562, and a T1 link gets a metric of 64.


Note Remember that OSPF will load balance over multiple equal-cost links, so if you use the defaults, this feature will be on automatically.

To disable this feature, perform the following task in router configuration mode:

no ospf auto-cost-determination 

Configuring OSPF Over On-Demand Circuits

The OSPF on-demand circuit operational capability is an enhancement to the OSPF protocol that allows efficient operation over on-demand circuits like ISDN, X.25, switched virtual circuits (SVCs) and dial-up lines. This feature set is fully supported by Cisco and follows the standard as described in RFC 1793, Extending OSPF to Support Demand Circuits. This is one of the better RFCs and is worth consulting if you plan to configure OSPF to operate within this type of networking environment.

Prior to this RFC, periodic OSPF hello and link-state advertisements (LSAs) would be exchanged between routers that were connected on the demand link, even when no changes were being reported in the hello or LSA information. This would cause the costs involved with these types of connectivity to skyrocket.

However, with this enhancement to OSPF, periodic hellos are suppressed and the periodic refreshes of LSAs are not flooded over the demand circuit. These packets bring up the link only under tightly controlled circumstances:

This operation allows the underlying Data Link layer to be closed when the network topology is stable. Thus saving on unnecessary costs. This is very useful because if your company is paying ISDN costs every time a call is placed, you want to ensure that the call is necessary. Consider it an automatic feature that restricts your teenage daughter from using the telephone unless it is necessary . . . very useful isn't it.

This feature is also very useful when you want to connect telecommuters or branch offices to an OSPF backbone at a central site. In this case, OSPF for on-demand circuits allows the benefits of OSPF over the entire domain, without excess connection costs. Periodic refreshes of hello updates, LSA updates, and other protocol overhead are prevented in this configuration from enabling the on-demand circuit when there is no "real" data to transmit. Figure 7-24 illustrates this type of OSPF setup.


Figure 7-24: OSPF on-demand circuit operation.


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

To configure OSPF for on-demand circuits, enter the following command within the OSPF configuration mode:

ip ospf demand-circuit 

This command is also shown in the following example:

OSPF_Router(config)#router ospf 200 
OSPF_Router(config-router)#ip ospf demand circuit 

Note If the router is part of a point-to-point topology, then only one end of the demand circuit must be configured with this command. However, all routers must have this feature loaded within the area and must be configured with the ip ospf demand-circuit command. If the router is part of a point-to-multipoint topology, only the multipoint end must be configured with this command.

Implementation Considerations for OSPF over On-Demand Circuits

Please evaluate the following considerations before implementing on-demand circuits on a Cisco router:

Multicast OSPF

Multicast OSPF (MOSPF) was defined as an extension to the OSPF unicast routing protocol in RFC 1584. Multicast OSPF works by ensuring each router in a network understands all the available links in the network. Each OSPF router calculates routes from itself to all possible destinations.

Before discussing MOSPF any further, it is important to note that Cisco Systems does NOT support this feature of OSPF. Nevertheless, because many networks will have multiple router manufacturers in them or connect to other manufacturers, it is important to discuss this OSPF feature, as you will probably encounter it if your network has a blend of routers within it. This section will later discuss the reasons why Cisco does not support Multicast OSPF.


Note If you have a need to run MOSPF, then you will need to contact one of these five router vendors: 3Com, Bay Networks, IBM, Proteon, and Xyplex as they are the only manufacturers to have implemented MOSPF.

MOSPF works by including multicast information in OSPF link-state advertisements. A MOSPF router learns which multicast groups are active on which LANs.

MOSPF then builds a distribution tree for each source/group pair and computes a tree for active sources sending to the group. The tree state is cached on all routers, and trees must be re-computed when a link-state change occurs or when the cache times out. This eventuality in turn can hinder multicast performance, depending upon the size of the network and the volatility of the multicast groups.

As expected, MOSPF works only in internetworks that are using OSPF and have implemented routers manufactured by a company other than Cisco Systems.

MOSPF is best suited for environments that have relatively few source/group pairs active at any given time. It will work less well in environments that have many active sources or environments that have unstable links.

Some multicast group addresses are assigned as well-known addresses by the Internet Assigned Numbers Authority (IANA). These groups are called permanent host groups, similar in concept to the well-known TCP and User Datagram Protocol (UDP) port numbers.

Why doesn't Cisco Systems support this powerful enhancement to the OSPF protocol? You will not find this information on CCO nor in any of their corporate literature, and I had to open a trouble ticket with the TAC to find it. Various engineers within Cisco were consulted, and the problem with MOSPF is that every OSPF router in your network must have it turned on. Every router will then have to run the Dijkstra algorithm for every multicast source and group within the network. This feature will work properly within a multicast network that is very small but it will melt down routers as the number of multicast routers grows.

For example, this means that every receiver of a multicast is also a sender and will therefore cause another instance of the Dijkstra algorithm to be run within every router in the network. As the use of your multicast application grows, this would cause an increased load to be placed on the CPUs of your routers. Simply put, imagine if you have an ABR that was connected to multiple areas and every area had several hundred routers. Your ABR would have to run the Dijkstra algorithm for every router in every area, thus a network melt down would result.

Now extend that to every router in your network.


Note A nice example of the added load MOSPF will put on your network are some figures surrounding Proteon's implementation of MOSPF. When adding MOSPF into the base OSPF code, it caused a 30 percent increase in its size. Extra load will be placed upon a router to support such a jump in size and the operational requirements of MOSPF. My suggestion is: be very sure of the benefits you expect to gain if ever you decide to implement this feature. Due to scalability issues, Cisco does not see a need to go to MOSPF right now. Additionally, PIM is getting pushed now as the multicast protocol of choice.

OSPF and the Multi-Protocol Router (MPR)

I considered long and hard about whether to include this section in the book, and I decided I would. Because it is important to note the extent to which OSPF has been implemented throughout the networking arena.

Not too long ago, routers were by default very expensive pieces of hardware that always received the blame for network outages. You are probably aware that the Cisco router is usually very reliable and easy to understand--at least when compared to the competition. Imagine that--reliable and easy to operate, and they are the market leader--seems like Business 101 to me, but I digress.

Today routers are relatively inexpensive and self-configuring to a certain degree. It is acknowledged that the IOS is the soul of the router because it examines and makes routing decisions, which the hardware executes. There are now a variety of router manufacturers such as Cisco Systems, Bay Networks, Ascend, 3Com, and many others. However, Novell made a truly astounding move by introducing the Multi-Protocol Router (MPR) as a software service within their NetWare Software Suite. This MPR delivers routing services, and it can operate on any machine that can run NetWare server. Novell's move indicates a move within networking away from traditional router design. It was not long before Microsoft also offered an MPR within Windows NTv4. Adding this routing ability is an excellent move on their part because it further enhances the usefulness of their operating systems. You can argue all day about the good and bad regarding software routers or specialized routers. Nevertheless, the bottom line for many is economics and being able to use a PC as a router has its appeal. While Cisco and others have many office or campus routers on the market, they still have not recognized the need to make a PC a router, so this market remains the sole property of Novell and Microsoft.

To be fair, I should discuss both Microsoft's and Novell's MPRs, but this is a book about OSPF networks and only Novell recommends configuring your MPR using the OSPF standard. In this case, it is beyond the scope of this book to discuss Microsoft's MPR. Sorry Bill, but you should consider OSPF as the default in WIN NTv5.

OSPF & Novell's MPR

When configuring OSPF within Novell's MPR it is important to note that by default OSPF is turned on--they are so smart! The MPR uses the standards for OSPF in its design. It is not as configurable as a normal router but then it was not meant to be. You will find that the MPR has the following configurable options:


Note MPR is good bec
ause you don't need a dedicated router. You can use a Novell server to do the routing for you in addition to serving files and giving print services.

Considering that you would likely use an MPR within a stub area, at a very small location not rating a real router, or in case of emergencies, it can be configured surprisingly well. The MPR is not the means to build today's Enterprise networks but, it certainly should not be discarded out of hand because it does have its place in the grand scheme of networking. It is going to be interesting to see what the future is going to bring us regarding this area of networking. I suggest watching it very closely.

Chapter Summary

This chapter covered the common set of network design goals to ensure that your network is of enterprise quality. There are always some unique issues surrounding every type of network and these were discussed as well. To review, the six steps of designing a network with special emphasis on the areas that are essential to OSPF are as follows:

    1. Analyze the requirements.

    2. Develop the network topology.

    3. Determine addressing and naming conventions.

    4. Provision the hardware.

    5. Deploy the protocol and IOS features.

    6. Implement, monitor, and manage the network.

Answering the question of "how to actually make my Cisco router do all this" was then covered in the "Configuring OSPF on Cisco Routers" section. The overall process of implementing OSPF on your routers as well as the different types of OSPF routers (inter-area, intra-area, ABR, ASBR, and backbone), was discussed. Then, a variety of different scenarios that you might encounter within your network were discussed, as well as how best to implement OSPF to meet these scenarios. The chapter concluded with the "IOS on a PC" or Multi-Protocol Router (MPR) that are beginning to see more wide-spread application within the industry and, of course, they also support OSPF, so their roles as they relate to OSPF were discussed.

Case Study: Designing an OSPF Frame Relay Network

Terrapin Pharmaceuticals has 25 regional sales offices dispersed throughout the eastern United States. The main corporate headquarters and the data center for Terrapin Pharmaceuticals is located in Tennessee. The following list details some of the network attributes of the Terrapin Pharmaceuticals setup.

Figure 7-25 shows the existing Terrapin Pharmaceutical network.


Figure 7-25: Terrapin Pharmaceuticals' existing network.


Wide Area Network Design Requirements

Terrapin wants to remove the leased lines and 3174 cluster controllers and network its sales offices using public Frame Relay service. The new WAN must seamlessly integrate into the existing corporate internetwork.

As the design engineer, you are responsible for the OSPF design and implementation, TCP/IP addressing scheme, and router implementation of this frame relay network. To construct a scalable OSPF network capable of meeting both the present and future requirements, you need to gather the necessary information from the appropriate

company decision-makers. This information will consist of determining the customer's requirements as discussed in the following section.

Determining the Frame Relay PVC Architecture

The corporate engineering group has control of all circuit and transmission architectural decisions such as the planning and ordering of all data and voice lines, as well as equipment procurement and installation. You are told that the new frame relay topology will be a partially-meshed hub and spoke. Figure 7-26 illustrates this topology.


Figure 7-26: Partially-meshed hub and spoke PVC topology.


Each spoke or remote sales office will have a 56KB local circuit installed into the frame relay POP with a single 32K CIR PVC provisioned to a T1 circuit which will be installed on a central hub router at the corporate Headquarters and data center facility in Tennessee. The CIR on the T1 circuit will be 384K.

Determining if There Will Be Multi-Protocol Support

The WAN network must support Novell IPX in addition to TCP/IP since it is on the customers' LANs. The corporate IS manager indicates that no native SNA will need to be supported on this network as all the IBM 3174 controllers will be removed after conversion to frame relay. Mainframe access will be accomplished using TCP/IP directly from terminal emulation software running TN3270 (Telnet) at the Regional Sales Offices

Determining the Application Data Flow

The IS manager tells you that the majority of traffic on this frame relay network will flow from individual branches to corporate HQ, in the form of PC-to-mainframe communications. It will be necessary for certain sales offices to share and print files on remote Novell Servers and printers. All remote sales offices are located in the Northeastern and Southeastern US.

Determining the Number of Routers

There will be 25 routers on this frame relay network with a potential 10% increase (3 routers) over the next three years (one location per year). The existing corporate network has 30 Cisco routers deployed, servicing 50 TCP/IP subnets and IPX networks on an Ethernet infrastructure.

Determining TCP/IP Addressing

Terrapin Pharmaceuticals is allocating TCP/IP addresses from the private RFC 1918 space. All existing LANs are subnetted out of 172.17.0.0 space using 24 bit prefixes. (/24 prefix or 255.255.255.0 subnet mask). IP subnets currently allocated on the corporate network are 172.17.1.0-172.17.55.0. You are told that you must support between 50 and 150 IP hosts per remote Sales LAN from unused subnets out of this same address space.

Determining Internet Connectivity

Terrapin Pharmaceuticals currently has Internet connectivity through a firewall segment. The default route or "gateway of last resort" is propagated into IGRP from a central router on the internal network to all other IGRP-speaking routers. A registered class C address has been obtained and is deployed as the Internet DMZ segment. This is the only address that is announced to the Internet from Terrapin's Internet Cisco 4700 router, as the firewall has proxy and Network Address Translation (NAT) capabilities.

Determining Enterprise Routing Policies

After speaking with the managers of the IS department, you discover that they intend to migrate the network from IGRP to OSPF on the existing Cisco router base in the near future. Thus, the frame relay network must run OSPF and integrate seamlessly into the eventual corporate OSPF network architecture. Because no timeframe for the campus OSPF conversion can be determined, your network must integrate into the IGRP network upon installation for an undetermined period of time.

Establishing Security Concerns

The company plans to use OSPF password-authentication when the network is converted to OSPF from IGRP. The security manager indicates that a single password will be sufficient across all OSPF-speaking router links.

After evaluating all of Terrapin's requirements, Figure 7-27 illustrates the proposed OSPF network design.


Figure 7-27: Proposed Terrapin Pharmaceutical OSPF Frame Relay network.


OSPF Network Design

This section will discuss some of the design topics to consider within this case study.

TCP/IP Addressing

You are able to obtain a contiguous block of 32 "class C" (/24 or 255.255.255.0 mask) subnets for this network from the IP address manager. The address block is 172.17.64.0/19, which will allow clean summarization into the backbone area once the corporate network converts to OSPF. (This occurs because all of the frame relay network LAN and WAN addresses will be summarized as one route (172.17.64.0/19) once the backbone routers are converted to OSPF as show in Figure 7-28.)


Figure 7-28: OSPF summarization with TCP/IP.


Sales Office LAN Addressing

Given the host requirements of 50-150 nodes per remote LAN and the existing subnetting scheme of /24 (class C mask) on the corporate network, it makes sense to assign /24 subnets of the 172.17.64.0/19 space to every one of the 25 spoke LANs. Every LAN will have addressing space for up to 254 nodes with this subnetting scheme that will facilitate future growth requirements at each site. This fulfills the earlier requirement concerning network growth and planning. This masking scheme will be easily understood by the desktop support staff and will work with existing routers running the IGRP routing protocol.


Note IGRP does not carry subnet information in routing updates and routers require a uniform masking scheme enterprise-wide.

The spoke router LAN subnets on this network will be assigned out of the range 172.17.64.0-172.17.88.255.

The hub router will attach to an existing corporate backbone Ethernet segment, and will be assigned an IP address from that subnet, which does not fall within the 172.17.64.0/19 range. You are given 172.17.10.240/24 for the Hub router Ethernet IP address.

WAN Addressing

Before the WAN IP address plan can be devised for the routers on this network, the decision must be made as to whether to treat the frame relay PVCs as a single multipoint subnet or a collection of point-to-point links on the Cisco routers.


Note Multipoint mode models the Frame Relay cloud as a LAN subnet, whereas the point-to-point mode models each PVC as a separate WAN point-to-point link in terms of addressing and routing

Given the additional requirements to support the IPX protocol in an any-to-any fashion, the point-to-point model is the only option.


Note IPX RIP is a distance-vector routing protocol with limitations of the split-horizon behavior of not sending routing updates out an interface on which they were received. The multipoint model would not facilitate IPX any-to-any as the router would not send IPX routing updates out to any of the remote routers.

To support the point-to-point model, you must define individual router serial port logical interfaces or subinterfaces, each of which will represent a discrete IP subnet and IPX network. TCP/IP addressing can accommodate this model most efficiently by assigning each of the subinterfaces with a /30 subnet. IP address space for these WAN links will be derived from further subnetting of a single /24 bit subnet (172.17.95.0) The example Hub router configuration (TENN) that follows provides more details:

TENN# 
interface serial 0 
encapsulation frame-relay ietf 
frame-relay lmi-type ansi 
no ip address 
interface serial 0.1 point-to-point 
description PVC to Cumberland router 
ip address 172.17.95.1 255.255.255.252 
ipx network 179500 
frame-relay interface-dlci 401 broadcast 
interface serial 0.2 point-to-point 
description PVC to west LA router 
ip address 172.17.95.5 255.255.255.252 
ipx network 179504 
frame-relay interface-dlci 402 broadcast 

OSPF Area Organization

Given the relatively small size of this network (less than 50 routers), it will be practical to include all routers into one single OSPF area. This will create a "portable" OSPF network that can be easily integrated into the enterprise corporate OSPF network once converted from IGRP. Because you do not know the future location of the OSPF backbone, you decide to be safe and put all routers in this network into a non-zero area. Putting this network into a non-zero area will allow you to avoid a future mass router reconfiguration after the corporate network is converted to OSPF. You assign this non-zero OSPF area an identifier of 64, because this number is the base number of the /19 CIDR block which is a logical representation of the addressing. You decide to use the company's registered BGP AS# of 5775 as the OSPF process ID# for this network:

router ospf 5775 

The hub router in Tennessee will be the sole ASBR in this network, as it must run OSPF and IGRP to support mutual redistribution of routes between the Campus and WAN networks.

Because all routers in the frame relay network will be in area 64, no backbone area (area 0) will be created, and subsequently no routers will be configured as ABRs or backbone routers at this point.

Figure 7-29 shows the OSPF area architecture established for Terrapin.


Figure 7-29: OSPF Frame Relay network area architecture.


Specifying the OSPF Network Type

Use the default OSPF network type of point-to-point because you are modeling the router frame-relay cloud as individual point-to-point subinterfaces. The initial step of DR/BDR election is not required because only two routers exist on point-to-point networks, resulting in quick adjacency formation upon startup.

Implementing Authentication

The IS security manager insists that you use OSPF authentication to provide a low level of security on this network. You implement simple password authentication by assigning a key of "watchtower" to your OSPF area 64. All OSPF routers added to this frame relay network need to have this key configured in order to form an OSPF adjacency with the Hub router. This authentication will need to be entered under the OSPF process ID and on each serial interface as follows:

interface serial 0.1 point-to-point 
description PVC to Cumberland router 
ip address 172.17.95.1 255.255.255.252 
ip ospf authentication-key watchtower 
ipx network 179500 
frame-relay interface-dlci 401 broadcast 
! 
router ospf 5775 
area 64 authentication 

Note If you are planning on implementing OSPF authentication, you should also enable the Cisco Password encryption option through the use of the service password- encryption command.

Configuring Link Cost

Because all spoke routers will only have one PVC provisioned to the hub router, there is no need to configure specific OSPF costs to links to engineer traffic patterns in a particular matter. Use the defaults by not assigning costs in router configurations.

Tuning OSPF Timers

Because all routers are Cisco and running the same version of code, there is no reason to tune individual HELLO, DEAD, or RETRANSMIT timers. Cisco's default WAN values of 10, 40 and 120, respectively, will provide fast convergence times and ensure consistency across all routers:

TENN# 
interface Ethernet 0 
description LAN connection to campus backbone 
ip address 172.17.10.240 255.255.255.0 
! 
interface serial 0.1 point-to-point 
description PVC to Cumberland router 
ip address 172.17.95.1 255.255.255.252 
ip ospf authentication-key watchtower 
ipx network 179500 
frame-relay interface-dlci 401 broadcast 
! 
interface serial 0.2 point-to-point 
description PVC to west LA router 
ip address 172.17.95.5 255.255.255.252 
ip ospf authentication-key watchtower 
ipx network 179504 
frame-relay interface-dlci 401 broadcast 
! 
router ospf 5775 
network 172.17.95.0 0.0.0.255 area 64 
area 64 authentication 

Strategizing Route Redistribution

Redistribution of routes between the OSPF and IGRP domains will be done at the frame-relay hub router (ASBR) in Tennessee. To learn of routes from both domains, the hub router must run both an OSPF and IGRP routing process. Redistribution of routes must address all of the issues detailed in the sections that follow.

Campus Routing to Frame Relay WAN

This section discusses how the existing campus routers will dynamically learn about the new Frame Relay networks, specifically examining the following issues:

Redistribution of OSPF routes into the IGRP process will cause the hub router to send IGRP advertisements of all /24 subnets known to OSPF. This will allow all spoke router LAN subnets to be learned by IGRP routers.

Use the "internal" keyword when performing this redistribution on the Hub Cisco router to allow only OSPF "internal" routes to be redistributed into IGRP. This will prevent a possible router loop in the future if more routers are installed and running "two-way" OSPF/IGRP redistribution. (All of the frame relay LAN/WAN networks will be known as OSPF "internal" routes because they originated from this same domain.)

The WAN subnets cannot be redistributed into IGRP this simply, however, due to the "classless" IP subnetting scheme of /30. IGRP only supports "classful" subnetting, and routers would ignore all /30 subnets when redistributing. Although this would not affect host-to-host IP connectivity, it could potentially cause a problem with network management tools, subsequently causing routing holes when accessing the router's WAN IP address directly to/from frame-relay.

Two possible strategies for handling the WAN link advertisements into IGRP are possible: static route aggregation and redistribution into IGRP and OSPF Route aggregation and redistribution into IGRP.

With static route aggregation and redistribution into IGRP, you must represent all /30 WAN subnets into an aggregate 24-bit summary and then redistribute them because only /24 prefixed routes will be announced into IGRP. Configure a static route on the Hub router for 172.17.95.0 255.255.255.0, with the next hop as the "Null 0" interface (a.k.a. the hub router). Now, redistribute static routes into IGRP and all IGRP routers will be able to route traffic to these WAN links. Control redistribution of routes to just the 172.17.95.0/24 network by defining an access list that will only allow redistribution of this route. Defining an access list may prevent future routing problems if additional static routes are added to the hub router, which the campus need not know about through IGRP. The following configuration demonstrates how to control redistribution of routes.

TENN# 
router igrp 10 
network 172.17.0.0 
passive-interface serial0.1:0.30 
default-metric 10000 100 255 1 1500 
redistribute ospf 5774 match internal 
redistribute static 
distribute-list 3 out static 
ip route 172.17.95.0 255.255.255.0 null0 
access-list 3 permit 172.17.95.0 

The passive-interface command stops IGRP updates from being broadcasted unnecessarily across all wan PVCs.

The default-metric command assigns IGRP metrics to routes known from all other route sources (in this case static routes) that need redistribution into IGRP.


Note IGRP uses Bandwidth, Delay, Reliability, Load, and MTU components to calculate route metrics across specific interfaces. The values 10000 100 255 1 1500 are defaults for 10MB Ethernet.

An alternative to static route aggregation of the WAN subnets would be to employ OSPF route aggregation and redistribution into IGRP to accomplish this task. This is the preferred solution, and the one chosen for this case study, as OSPF is already currently being redistributed into the IGRP process in order to propagate the LAN subnets.

To accomplish OSPF route summarization, the Hub router will need to be configured as an ABR. This is required because OSPF inter-area summarization can only be accomplished at area boundaries towards the backbone. You can accomplish this by adding the Ethernet interface into OSPF area 0. Now that the hub router (TENN) is an ABR, you can summarize the WAN subnets as one /24 network (172.17.95.0/24). This network falls on the established 24-bit boundary and will be redistributed into IGRP and understood by all interior IGRP-speaking routers as shown in the following configuration example.

TENN# 
router igrp 10 
network 172.17.0.0 
passive-interface serial0.1:0.30 
default-metric 10000 100 255 1 1500 
redistribute ospf 5775 match internal 
router ospf 5775 
summary-address 172.17.95.0 255.255.255.0 
network 172.17.95.0 0.0.0.255 area 64 
network 172.17.10.240 0.0.0.0 area 0 
area 64 range 172.17.95.0 255.255.255.0 
area 64 authentication 

To test the OSPF route redistribution into IGRP, you can display the routing table of any IGRP internal router, which will indicate the success or failure of the redistribution of OSPF routes into IGRP. If problems arise, debugging on IGRP transactions on the ASBR (hub) router may provide information as to what is going wrong.

CAMPUS to WAN Routing

Now that all WAN routes are available on the campus IGRP backbone, it will be necessary to advertise routing information to the WAN routers such that all campus subnets can be reached. This can be accomplished in two ways:

All known IGRP subnets can be redistributed into OSPF at the Hub router with the following:

TENN# 
router ospf 5775 
redistribute igrp 10 metric 100 metric-type 1 subnets 

metric 100 is an arbitrary default metric that will be attached to IGRP routes redistributed into OSPF.

metric-type 1 will make redistributed IGRP routes external Type 1, which will allow the OSPF spoke routers to add individual link costs in order to calculate OSPF metrics.

subnets is necessary to allow subnets of natural class B address 172.17.0.0 to be redistributed into OSPF.

You should take note that the IGRP "gateway of last resort," default route or 0.0.0.0, will be automatically redistributed into OSPF because it appears as an IGRP route on the Hub router. This default route will be propagated to all frame-relay routers as an external 0.0.0.0/0 route.

When generating a default route into OSPF, because all spoke routers only have a single path (one PVC) out to the WAN, all destinations, which are not locally connected, would have to traverse that path. A default route (0.0.0.0/0.0.0.0) can be sent from the ASBR Hub router in lieu of specific subnet routes. This is the preferred method in this case, since the routing tables on remote routers become smaller, and potential routing loops which sometimes result from two-way redistribution can be avoided altogether. The syntax that follows demonstrates this procedure.

TENN# 
router ospf 5775 
default information originate metric 100 metric-type 1 

Note In order to use the default route method, it is necessary to enable classless interdomain routing (CIDR) on all OSPF routers. This is done using the "ip classless" command on all routers:

Router#
ip classless

Without this command, remote routers will not use the default route as a possible path for any destination networks, which are subnetted out of the "native class" 172.17.0.0 network.

Refer to Figure 7-29 to see the implementation of the techniques covered in this section for Campus-to-WAN routing.

Case Study Conclusions

Although the Terrapin OSPF network design was fairly simple in terms of IP addressing and OSPF architecture, integration into the IGRP network presented a number of challenges. Adding OSPF into existing networks running other routing protocols is often a difficult task, and must be carefully planned out; otherwise sub-optimal routing or even loops may occur.

Frequently Asked Questions

Q What is the benefit of a one-layer distributed network design?

A They are good for smaller networks and are useful from a survivability aspect if you plan to distribute servers throughout the network. The downside is a tendency to have duplicated functions at the various sites, which results in higher costs.

Q I have a server farm type of LAN within my networking environment. How should I design the network to maximize their placement?

A The standard hub and spoke network design would be good for locations having a server farm. You might also want to consider using the higher bandwidth LANs (fddi and fast Ethernet) to connect the servers.

Q Why shouldn't I put hosts and users on the backbone of my network?

A To facilitate effective routing at the backbone, users should not be directly connected to it. Ideally, about 80 percent of LAN traffic should remain there. By following the guidelines, you will increase the backbone's reliability, facilitate proper traffic management, and be able to easily plan for backbone equipment or bandwidth upgrades.

Q Where can you get OSPF software?

A The first thing that comes to mind is Cisco routers. However, there are other places to find the software such as other router manufactures. In addition, Merit Networks of Ann Arbor, MI currently maintains a program known as GATED. This program is among other things a routing daemon for Unix platforms and it contains OSPF. The original implementation of OSPF has been incorporated into GATED. For additional information on these two sources, refer to the following sites: http://www.cisco.com and http://www.gated.com.

Q How can I learn more about networking and OSPF in particular?

A I would recommend two mailing lists. The first is a mailing list regarding Cisco networking equipment as a whole. You can join it by sending a subscription request to: cisco-request@spot.colorado.edu.

The other mailing list that I would recommend concerns the OSPF protocol as a whole. The OSPF Working Group has a mailing list that holds discussions on various OSPF topic. You can join it by sending a subscription request to: ospf-request@gated.cornell.edu.

You can also go to the IETF and learn more about the IETF Working Groups and the areas of networking that they monitor and such: http://www.ietf.com.

Cisco also has a very extensive Web page that contains an impressive amount of information on networking, although to access the majority of it, you need a Cisco Connection Online (CCO) account. This information can be found at http://www.cisco.com.

Q I need an explanation of OSPF link types. Could you please summarize and explain the differences between the following:

A RFC 1583 describes what those links are. The following information is in RFC 1583:

Q I want to run OSPF over ISDN (DDR). How can I suppress that the connection is established for every hello packet? Does snapshot routing work with OSPF, or just with distance vector protocols?

A Snapshot will not work with OSPF because it is a link-state protocol. However, OSPF over DDR links is supported in Cisco IOS 11.2. This feature enables you to suppress hellos and updates after the updates and hellos are passed initially.

Q What is the best way to implement an IP default network (0.0.0.0) in a mixed RIP/OSPF network? I have inherited a network that has an OSPF backbone and is redistributed into RIP on the boundary routers. There are static routes to 0.0.0.0 scattered throughout the network, and they are redistributed in OSPF and RIP. In fact, there is a static route to 0.0.0.0 pointing to the next hop for Frame Relay defined on every router. There are IP default network statements on every local campus router, and there is an OSPF default-information originate statement. What is the best, most fault tolerant methodology to introduce a simple clean default route in this environment?

A Remove all the static routes. Watch where you dynamically get a default route. Make sure you have the default-info originate command on the correct router that you want to generate the 0.0.0.0 route. Let this go to every area dynamically. When you redistribute OSPF into RIP, this route will also go dynamically. Remember that you cannot originate default on every OSPF router: 1) Stub areas do this automatically; 2) Only ABR can generate this by using the default-information command.

Q Can OSPF give me full connectivity for IP in a partially-meshed Frame Relay network? Or, will I have to configure subinterfaces?

A OSPF has a feature called point-to-multipoint interfaces to easily allow full connectivity over a partially meshed Frame Relay network in Cisco IOS 11.0 and later. It could be done before Cisco IOS 11.0, but it required the hub router to be the Designated Router and some map statements on each spoke router to all the rest of the spoke routers through the hub router.

Q Can the ip ospf network point-to-multipoint command be used with Frame Relay subinterfaces?

A Yes, that is exactly what it was designed for.

Q Can IPX be routed using OSPF?

A No, OSPF is for IP. NetWare Link Services Protocol (NLSP) is Novell's answer to link-state routing protocol for IPX.

Q I have a serial link between Router A and Router B. They will use an ISDN link for bandwidth-on-demand and backup, as indicated here:

backup interface bri 0 
backup load 25 5 
backup delay 10 60 

The serial link has OSPF and IPX configured. Is it possible to have all the IPX and OSPF perimeters transferred to the ISDN link when the serial reaches 25 percent, or must I configure OSPF and IPX on the BRI?

A You need to configure both the IP and IPX parameters on the BRI interface also. After all, bringing up another link means another physical path to the destination and this path must contain the IP and IPX information before the router can put IP and IPX traffic onto this link.

Q Does OSPF support secondary addressing? Is there anything special I have to configure?

A Yes, secondary addressing is supported. The secondary address needs to be in the same area as the primary interface. In addition, OSPF cannot be configured on a secondary interface without being enabled on the primary.

Q Can I redistribute interior BGP routes into OSPF?

A Yes, but it is really not allowed and is strongly discouraged. Otherwise, you might cause routing loops.

Q My ASBR router is running OSPF as well as BGP. The router knows about my network's IP addresses through OSPF--the sh ip route command shows all my OSPF routes. But the BGP process does not exchange these routes with its peer, even if I use the BGP command: network <number> <mask>, where <number> <mask> are the aggregated IP addresses and corresponding masks of networks known by the ASBR router's OSPF process. If I redistribute the OSPF routes into the BGP process using the redistribute ospf <id> route-map <ospf-to-bgp> command, then only BGP will start redistributing my networks to its peer. I have taken care to use the proper access list associated with the redistribute command. The Cisco manuals recommend not to redistribute IGP into BGP, however, and state that the better way to do this is to use the BGP network command, which does not seem to work for me. How can I resolve this problem?

A For the network command to work, you need to have the exact route specified in it contained in your routing table. Make sure that your IP routing table has the exact routes that are mentioned in the network statement. Refer to BGP Technical Tips at: http://www.cisco.com/warp/customer/459/ 18.html or the Cisco troubleshooting engine which is found at: http://www.cisco.com/diag/te_start.html.

Q Can you use the distribute-list out command to filter static routes that are being redistributed into OSPF? I have a network running OSPF. On some of my routers, I have static routes that are being redistributed into OSPF; however, I do not want all of the static routes to be redistributed. I used the distribute-list out command, and this appears to have worked, but I have found that if I add another access-list command to permit an additional static route to be redistributed, the new access-list has no effect until I remove the distribute-list out command from the OSPF routing process and then re-insert it.

A What you have done is fine. You can also use the clear ip ospf redistribution command to refresh the redistribution process.

Q When implementing an OSPF network, what are the advantages and disadvantages in establishing Area 0 for the whole network?

A Generally, it depends on the total number of routers in the network and the topology of the network. If you are going to have fewer than 40 routers in the network, you should be able to get away with having all routers in area 0. For larger networks, you will want to subdivide your network to break it up into areas.

Q Can you set an OSPF dead interval timer in Cisco IOS 11.0 on a 4500 series router? I configured a core router (FDDI-attached) with the same configuration as a local router, but the users could not see out of their LAN. Both of the interfaces configured are Ethernet. There was an OSPF hello interval statement and network statements in the one router, and both had area statements.

A Yes, you can change the dead interval using the ip ospf dead-interval command. If this timer is not manually set, it will take a value of four times the Hello interval, by default.

Q What is the command to enable the serial interface learn routes only (listen) and not send the updates? I am running OSPF in a Cisco 7000 router.

A You will not be able to do this. The command passive-interface serial x with OSPF will disable both incoming and outgoing routing updates. The command distribute-list out cannot be used, unless this is an autonomous system border router (ASBR), and you only want to filter external routes (from other routing protocols).

On the other router, the most you can do is filter incoming updates from the serial link with distribute-list in. This will affect only those routers coming into that particular router's routing table. It will not alter the OSPF database.

Thus, that router will pass the LSAs on to its other neighbors, so even this is not a very good solution. You would need a distribute-list in on each subsequent router to block the LSAs from getting into each router's routing table.

Q If area1=NJ, area2=Delaware, and area0=NYC, will routing ever take place between area 1 and area 2 without traversing the backbone (as it will be the shortest path)?

A In the migration of RIP to OSPF, there seems to be a case where two non-backbone areas are going to be connected, such as area 1 to area 2. This is in place for redundancy. In OSPF, all areas must touch the backbone area 0. You can, however, use virtual links to get from area 1 to the backbone and then to area 2. The virtual links are tunnels to the backbone.

Q What is the recommended maximum number of routers in an OSPF area, specifically the backbone area?

A It depends on how stable your network is. If it is extremely stable, with no flapping links, you can get by with more routers in an area. 40 is a conservative estimate.

Q What is the correct wildcard mask for an OSPF network with mask 255.255.255.252? We are using Class C network addresses, on Loopback interfaces for DLSw, subnetted 255.255.255.252. From the three proposals that follow, what is the correct wildcard mask to use on the OSPF network definition statement router ospf 1234:

    1. network 192.168.1.4 0.0.0.2 area 0 (two hosts)

    2. network 192.168.1.4 0.0.0.3 area 0 (two hosts and broadcast)

    3. network 192.168.1.4 0.0.0.4 area 0 (network, two hosts, and broadcast)

A The third wildcard mask is the best method. For the loopback interface, you can use a 255.255.255.255 mask to save address space because OSPF supports host-route. To answer your question, if your loopback is 192.168.1.9 255.255.255.252, then under OSPF you would have: network 192.168.1.8 0.0.0.3 area 0. In other words, #2 in your question is the correct choice.

Q How does OSPF handle multiple exit points? I am running OSPF between areas and RIP within areas. I also have multiple exit points to some destinations. How do I tell OSPF to use the preferred path? Do I need static route statements to force it?

A OSPF will use the lowest cost to the end destination. You can find the total cost by adding up all the costs on individual links to the exit points. If you want, you can manipulate the OSPF costs with the ip ospf cost command. The administrative distance of RIP is 120 and OSPF is 110.

Q Is there anything I should look out for with Dial Backup using OSPF?

A It will work well as long as you obey the general rules of OSPF, such as never dial between areas (from area 1 to area 2, for example). Also, make your backup delay intervals long enough so you don't end up causing route flaps in the OSPF, which will cause routing storms.

Q If I inject some external routes into OSPF, can I then summarize those routes into one route on some router downstream in the network? It seems that the only way to summarize the external routes is by summarizing on the router that first injected (redistributed) the external routes. I am using the summary-address command. I do not think the area range command will work either because this summarizes only internal OSPF routes.

A You must summarize the external routes at the ASBR router (the router where the redistribution of external routes into OSPF is taking place). Please see the OSPF Design Guide for details.

Q While testing OSPF, I ran OSPF on one of my routers and used the OSPF default-information originate metric-type 1 command. This same router had a static route ip route 0.0.0.0 0.0.0.0 xxx.xxx.xxx.xxx, where xxx.xxx.xxx.xxx was the opposite directly connected interface on s0 of my test router. When I shut down s0, the default route generated by the default-information originate command disappeared. Does that mean that the OSPF default-information originate command polls the interface defined in the static route?

A If the next hop in a static route is unreachable or down, the static route will no longer be installed. In addition, because that static route is no longer in the router, OSPF is not originating default. For the router to originate a default without any regard to the availability of a default route in the router, use the command default-information originate always.

Q When using OSPF, is area 0.0.0.0 the same as area 0? Should the backbone always be area 0?

A Yes. Area 0 is also displayed as area 0.0.0.0. Yes. Area 0 is the backbone area, and it is mandatory.

Q Do Cisco routers support OSPF for secondary addresses? We would like to run OSPF for both the primary and secondary addresses, but have that interface as passive. A second scenario (but not yet needed) is OSPF on the LAN with OSPF neighbor as primary IP address, with neighbor as secondary IP address--is that possible?

A Cisco routers treat secondary addresses as stub networks under OSPF. They also do not form adjacencies on secondary addresses. It has to be the primary for that to happen.

Q Is it possible to create an OSPF virtual link through two or more areas to connect to area 0?

A That is not a supported function according to the RFC. You cannot create an OSPF virtual link across more than one area.

Q How do I set the hub router on a hub and spoke Frame Relay network to be the designated router (DR) in an OSPF routing environment?

A Most hub-and-spoke architectures do not have any broadcast capability to emulate shared media between remote nodes, but instead are made up of a set of point-to-point links converging on one central router. In any point-to-point topology, even with a large set of neighbors, the DR concept is irrelevant and not used. The routers will establish a complete adjacency without electing a DR. In many cases, the above might require that each subinterface be set up as an explicitly point-to-point subinterface and/or the use on a per-interface basis of: ip ospf network point-to-point. If, for some reason, you want to establish DR/BDR relationships on point-to-point links, you may still implement ip ospf priority < number >, where < number > is greater than one and applied on the local interfaces to the hub router. In such a topology, however, this is not recommended.

Q How do I advertise a single summary route to other OSPF areas? I have subnetted a Class C network no. With a 255.255.255.252 mask for my Frame Relay backbone. For each of my point-to-point connections, I am using a subnet, and on the Frame Relay backbone all subnets are contiguous. How would I summarize all routes using OSPF to advertise a single summary route to other OSPF areas? For example, based on a 207.105.207.0 network no., is the following correct?

Network no.: 207.105.207.0 
Subnet mask: 255.255.255.252 

A Summarize all addresses between 207.105.207.4 through 207.105.207.44 with the following: area 12 range 207.105.207.4 255.255.255.47. The area range command summarizes a block of addresses in an area to the backbone. This command should be configured on the backbone area border router. For example, if you were to summarize a block of addresses 131.108.32.0-131.108.47.255 in area 12 to the backbone; the required command would be area 12 range 131.108.32.0 255.255.240.0.

Q If a router (router 1) has a default route specified to be to a router (router 2, which is not talking OSPF) on a network on which router 1 has an interface, and router 1 has default-information originate set so that it propagates a default route, will the default route advertisements have a forwarding address set to the address of router 2 so as to avoid ICMP redirects?

A The OSPF updates should contain database information including the IP address of the location of the default router. The OSPF router receiving the update should independently decide the best "next-hop" to get to the network where that address resides. If it is directly connected to the subnet in common with router 1 and router 2, it should send the packet directly to router 2 even though router 2 does not speak OSPF. Unlike classic distance-vector protocols, the "next-hop" address is independent of the advertising router.

Q When using floating static routes on a link backup over ISDN, how can I ensure that the floating route stays active until the OSPF table is built?

A Floating static routes have administrative distances greater than the other routing protocols (higher than 120). This means that a route learned via any routing protocol will take precedence, regardless of the metric. When the link is restored, the router will use the OSPF route as soon as it is available. The backup link will stay up until the backup delay timer expires, but IP traffic will use the OSPF route.

Q I have a network (Frame Relay) in which every remote site has a primary and a secondary link. I want the secondary link to be used only if the primary becomes inaccessible; OSPF is my routing protocol. When I do trace route, the path taken to reach the destination is through the secondary link. Why does this happen?

A I think you mean that both links are connected to the same router. The best way is to use different ip ospf cost on the links or use static routing for the backup link with a higher distance than OSPF.

Q How do I resolve discontiguous networks?

A You can use secondary IP addresses to link the address space or you can use OSPF EIGRP, IS-IS or BGP4 with auto summarization turned off.

Q In 9.1, why must the neighbor command be used when running OSPF over X.25 networks?

A You need the neighbor command to make OSPF work on X.25 in 9.1. In 9.21 and later, at OSPF level, an X.25 network can be configured to be a broadcast network, and OSPF would treat X.25 as a broadcast network only. X.25 maps with the broadcast keyword would be needed to make it work.

Q How can an OSPF default be originated into the system based on the existence of certain external information (i.e., routes learned from some exterior protocol) on a router which does not itself have a default?

A OSPF will generate a default only if it is configured using the command default-information originate and if there is a default network in the box from a different process.


hometocprevnextglossaryfeedbacksearchhelp
Posted: Wed Aug 2 16:10:21 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.