|
|
Configuring OSPF |
| This article leads you through the initial steps of implementing OSPF on a Cisco router. At the CCNA level, OSPF is probably the most difficult routing protocol that you will encounter because it can be complex to configure. |
If your only routing protocol experience is with RIP or IGRP, you will find OSPF much more complex to configure. This isn't necessarily bad, the additional configuration is needed because OSPF has many more features than these protocols. EIGRP may be simpler to configure when only its basic features are used, but in networks of any substantial complexity, the configuration of OSPF, ISIS, and EIGRP is of comparable difficulty.
Once you have defined the area identifiers and the addresses that will be in each area, you can begin to configure individual routers. The first step is to establish the OSPF process, and the second step is to establish the unique ID of the router you are configuring. Unique router IDs are necessary to identify the link information a given router originates
For any OSPF process to initialize, it must be able to define a router ID for the entire OSPF process. Once the router-wide data structures are built, it is then necessary to define the networks that the router will advertise and the area numbers into which these networks will be advertised.
There are several potential sources for the router ID. The most common stable source is the IP address set on loopback 0. If more than one loopback address is defined, the IOS will select the numerically highest IP address (e.g., 192.1.1.1 is numerically higher than 172.255.255.254) configured on a loopback interface. In other words, it is the IP address on the loopback interface that breaks ties, not the number of the loopback interface -- loopback 1 is not automatically preferred to loopback 0.
Table 1. Router ID with Multiple Loopbacks
| int loop 0 | int loop 1 | int loop 2 |
| ip addr 1.2.3.4 | ip addr 5.6.7.8 | ip addr 2.3.4.6 |
The router ID, in this case, was 5.6.7.8.
If no loopback interfaces are defined, the OSPF process uses the numerically highest IP address value on an active physical interface. If no physical interfaces are active and configured with an IP address, the OSPF code will not initialize. In recent IOS versions, the router issues an error message if it cannot find a router ID. Older versions simply do not initialize OSPF.
If there is only a single loopback interface, its IP address will always be the router ID, as shown in Table 2.
Table 2. Router ID with a Single Loopback
| int loop 0 | int ser 0 | int ser 1 |
| ip addr 1.2.3.4 | ip addr 5.6.7.8 | ip addr 2.3.4.6 |
Here, the router ID would be 1.2.3.4. If there were no loopback interfaces, the numerically highest active interface would be used, as shown in Table 3.
Table 3. Router ID with No Loopback and Highest IP shutdown
| int eth 0 | int ser 0 | int ser 1 |
| ip addr 1.2.3.4 | ip addr 5.6.7.8 | ip addr 2.3.4.6 |
| no shutdown | Shutdown | no shutdown |
Here, 2.3.4.6 would be the router ID. If serial 0 were not shutdown, however, the router ID would be 5.6.7.8.
To start OSPF on a Cisco router, enter the router major command and at least one network statement.
! first OSPF process
router ospf process-id
network <prefix-to-advertise>
w.w.w.w
area
<area for prefix>
The process-id number on the router statement confuses many people. It is not an autonomous system number or any other number that is visible to other routers. Like the bridge-group command in bridging, the number is used to identify which interfaces belong to a particular process when there is more than one process. Most router vendors only allow one OSPF process per router, but IOS allows multiple processes (see Figure 2). In this example, OSPF 1 and OSPF 2 are not aware of one another. Routes generated by both processes can appear in the main routing table. For one OSPF process to have its routing information advertised by the other process, you must set up explicit redistribution.
Figure 2. Multiple OSPF Processes
I have found multiple processes most useful when consolidating different OSPF networks after corporate mergers and acquisitions. When the goal is to coordinate several regions, I establish a "backbone of backbones," using BGP or sometimes static routes, to link the OSPF domains. To create multiple processes, give them different process identifiers.
! second OSPF process (if you use multiple processes) ! process-id must be different from process-id ! on first statement router ospf process-id network statements...
router is the major command under which most OSPF subcommands affecting areas or domains are entered. Some other subcommands are subordinate to the interface major command. See Table 4.
Table 4. Organizing OSPF Commands
| Purpose | Associated major command |
| Creating a process | router |
| Selecting interfaces where OSPF runs | router |
| Setting interface cost | interface |
| Redistribution | router |
| Area-wide parameters | router |
Inside an area, all subnets belonging to that area must be made known to all routers in that area. OSPF is not aware of classful addressing and makes no distinction between networks and subnets. Unfortunately, it uses the term "network" confusingly to refer to any prefix associated with a specific medium.
Cisco has yet another usage of "network" in the OSPF context. The network subcommand of router indicates which interfaces are to run OSPF and to which area they belong.
In Cisco OSPF configuration, you begin by telling the router what interfaces to include in the OSPF process. You specify this information on network subcommands of router. As these interfaces come up, OSPF will advertise the prefix to which they are connected. When these interfaces hear announcements from other routers on the same medium, they will validate these announcements and flood the relevant ones to other OSPF routers.
The basic OSPF network statement has three main parameters:
network ip-address wildcard-mask area area-number
Two of these parameters, ip-address and wildcard-mask, work together to select the interface(s) on which OSPF will run. Wildcard masks are the same kind of mask you use on access lists. They are not subnet masks, although, just to make sure you're paying attention, there are some OSPF statements that do use subnet masks. In the immediate discussion, we are concerned with wildcard masks, which have a zero bit in every position where we want to make decisions about routing. This is the reverse of subnet masks, where zero bits mean "don't care."
The third parameter area-number specifies the area to which the interface belongs.
Simply coding the network statement will not cause the associated address to be advertised. A physical interface with an address inside the address range specified with the address and mask on the network statement must be active before OSPF will start to use it.
There is a distinct relationship between wildcard masks and subnet masks. When written in decimal, the subnet mask and wildcard mask octets for a specific address add to 255, as shown in Table 5.
Table 5. Subnet and Wildcard Mask Octets
| Subnet mask octet | Corresponding wildcard mask octet |
| 255 | 0 |
| 254 | 1 |
| 252 | 3 |
| 248 | 7 |
| 240 | 15 |
| 224 | 31 |
| 192 | 63 |
| 128 | 127 |
| 0 | 255 |
True subnet masks match only one specific address, which can either be a prefix or a host address. Just as a prefix mask will match multiple host addresses, you can create wildcard masks that match multiple interfaces. I don't recommend doing so. Experience has shown me that a configuration is much easier to understand and troubleshoot when there is a one-to-one correspondence between network statements and OSPF-speaking interfaces.
Nevertheless, you must understand how network statements can be written to cover a range of interface addresses. This was a very popular configuration in the old ACRC course and continues into newer material.
Network statements for all Cisco interior routing protocols enable the routing protocols on specific interfaces. For RIP, IGRP, and EIGRP, however, this takes no more than ensuring that the interface address is in the same classful network. OSPF is much more specific. Incidentally, both Bay/Nortel and Juniper enable OSPF directly on the interfaces, not under the OSPF process.
Figure 3. A Single Router to Configure
It is illegal to use discontiguous one bits in subnet masks, but discontiguous bits are permitted in both OSPF and access list wildcard masks. I don't recommend using discontiguous bits in wildcard masks, because it can make the configuration very hard to understand and debug.
Cisco's algorithm for assigning interfaces to routing protocols is sometimes subtle, especially with OSPF. Like access lists, it is order-dependent.
The first rule that matches an address will be the rule that applies, even if a more specific rule might follow in the list. In the case of OSPF configuration, the first matching network statement specifies the area into which the interface will be placed.
Subnet masks on each interface of the router are logically ANDed with the interface address, producing a prefix associated with the interface. This prefix is then compared with each prefix defined by a network subcommand of each router command. If the prefixes match, the routing protocol specified by the router statement activates on that interface.
Originally, the IETF working group that defined OSPF consciously did not define a specific rule for interface cost. It simply defined metric as the sum of costs along the path. Sloppiness wasn't involved here -- the committee wanted to maximize implementation flexibility. Bandwidth, for example, is not always the most important cost factor.
Subsequently, the OSPF MIB specification suggests a bandwidth-based interface cost of 108/bandwidth. While a bandwidth-based metric is generally most appropriate, the working group recognized there might be other situations where, for example, a monetary cost might be associated with going through particular interfaces.
Most, but not all, vendors use this bandwidth-based cost. In a multivendor environment, it's always wise to set the cost manually. To set costs, use the ip ospf cost cost command on each relevant interface.
TipWhen dealing with routes that go outside a single area, other decision factors are usually more important than metric. |
Be careful with the default on Cisco serial interfaces. If you do not explicitly configure the interface bandwidth value, the Cisco IOS software assumes the interface cost is that of a T1 interface on serial lines.
The 108/bandwidth default works up to 100 Mbps. Since the metric is internally an integer, a speed faster than 100 Mbps has an undefined metric of 1. Newer Cisco releases allow you to change the scaling factor to be other than 108. If you have a network with an extremely wide range of speeds, such as the US Coast Guard network with both 2.4 Kbps radio links to ships and 100 Mbps LANs, the simple convention of dividing a constant by a bandwidth does not cover the entire range of interface costs. In such cases, you need to develop a system of interface preference values that produce a metric that reflects your policies.
[IE-OSPF1-WP1-F04]
[2001-09-07-01]
|