- Configure, verify, and troubleshoot OSPF
The most widely used link-state routing protocol today is an IETF standard routing protocol called Open Shortest Path First (OSPF). Developed in 1988, this routing protocol was created to overcome the limitations that RIP presented for large-scale networks. The following sections look at the fundamentals of OSPF and show you how to apply them in your configuration.
OSPF is unique among the routing protocols that are discussed in this book. This is true from its operations all the way down to the configuration. Notably, one of the more intriguing aspects of this routing protocol is that it is completely classless. With the subnet masks accompanying the networks in the routing updates, routers are aware of all the individual subnets that exist. The upside of this knowledge is that you do not have to concern yourself too much with discontiguous network designs, and you can implement VLSM addressing throughout the topology. The downside of knowing all the subnets is that the topology database can grow to be quite large, depending on the size of the autonomous system. Not only does this knowledge exhaust the memory resources in your routers, but any change in the links associated with those subnets causes a flood of updates, consequently causing each router to run the SPF algorithm again. If your autonomous system consists of 1,000 routers, each one has to expend the processing resources to flood the update and rerun its algorithmic calculations based on the residual topology. If the link is continuously going up and then down (known as flapping), each of the 1,000 routers continually floods updates and reruns its Dijkstra SPF algorithm, which could exhaust a router’s resources and detrimentally affect the router’s capacity to function.
OSPF mitigates the need for excessive topology databases and update traffic overhead by segmenting an OSPF autonomous system into smaller areas. As mentioned before, routers that transmit information from one area to another can be configured to summarize the subnets being advertised to other areas. In this situation, routers in other areas need to keep only summarized entries in their topology table, minimizing the amount of memory required. If a link goes down within the area, only devices within that area need to be notified, because the rest of the OSPF autonomous system is aware of only the summarized route. With that update confined within that area, other routers in different areas do not receive an update and do not have to flood and recalculate the information in the update.
For instance, Figure 12.1 shows an OSPF autonomous system in which you have created three areas. Routers C and E have the responsibility of summarizing the subnets in their areas to the rest of the OSPF autonomous system. This hierarchy in routing ensures that any link failure that occurs in the areas they are summarizing does not go beyond those routers. Because these hierarchical routers are sitting on the border between two areas, they are called Area Border Routers (ABRs).
Notice that at the center of the OSPF autonomous system in Figure 12.1 is Area 0, to which Area 1 and Area 51 are attached. This is not by coincidence, but rather by design. Area 0, also known as the backbone area, is an essential part of an OSPF design because, as the name states, this is the area in which traffic from one area must transit to reach another area. If your network design requires only a single area, that area must be Area 0.
Any area that is created must somehow be connected to the backbone area. Because this area is truly an information highway interconnecting all other areas, it typically consists of robust routers called backbone routers that are either completely inside or have an interface that connects to Area 0. Traffic originating in one area is sent to the backbone ABR for that area, which in turn ultimately passes the traffic to the destination backbone ABR and finally to the destination router inside the remote area. Because these links inside the backbone carry excessive traffic, the backbone routers typically are interconnected with high-speed interlinks such as Fast Ethernet or Gigabit Ethernet.
Remember that Area 0 is also commonly called the backbone area. All areas that are created must connect back to Area 0. Stub Area Recall that the term stub in networking refers to networks that contain a single pathway in or out. Accordingly, a stub area is an area that contains only one pathway in or out of that area. The IETF created this concept of a stub area as a measure to decrease the topology database even further for routers that are inside a stub area.
Because the backbone area is a transit area that interconnects other areas, it can never be configured as a stub.
Again, the ABR router takes the credit for this reduction in OSPF overhead, as shown in Figure 12.2. If the area is configured on all routers inside that area as a stub area, the ABR replaces all the networks it learns from the rest of the OSPF autonomous system with a default route. It also advertises that route to the routers inside the stub area. This makes sense, because the routers inside the stub area are using that ABR as a gateway of last resort to leave their area.
When OSPF routers run the Dijkstra algorithm to calculate the best route to reach destination subnets, they use the lowest cumulative cost to reach that network. The path cost is calculated by taking 108 divided by the bandwidth in bps. Table 12.1 lists some of the common path costs associated with their respective bandwidths.
Be prepared to calculate the cost for any given link speed. Notice that when you reach and exceed Fast Ethernet speeds of 100Mbps, the cost is still 1. For that reason, you can configure OSPF to use a different reference for the bandwidth that is higher than 108 to account for links of that magnitude.
Unlike most routing protocols, OSPF routers identify each other with something known as a router ID. The router ID is a 32-bit unique number in which the router is known to the OSPF autonomous system. This ID is determined in the following order:
- The highest IP address assigned to an active logical interface at the start of the OSPF process.
- If no logical interface is present, the highest IP address of an active physical interface at the start of the OSPF process.
When I say “highest IP address,” I am talking about the numerical value of the IP address, not the class of the IP address.
Be sure to know how to determine a router’s router ID based on the IP addresses of the router’s interfaces. Note that if there is a logical interface, the IP address overrides any physical IP address for the router ID, even if it is a lower value. What do I mean by a logical interface? Cisco routers let you create logical or virtual interfaces called loopback interfaces. The advantage of using these virtual interfaces is that, unlike physical interfaces, loopback interfaces cannot go down unless the router is malfunctioning or turned off.
For the exam, keep in mind that loopback interfaces are logical interfaces that cannot go down unless the router is malfunctioning or turned off.
The environment in which OSPF operates varies greatly depending on the type of topology to which an OSPF interface is connected. Such operations as hello and dead timers, neighbor discovery methods, and OSPF update overhead reduction ultimately are dictated by the OSPF interface’s topology. Here are the three main types of topologies:
- Broadcast multiaccess: These topologies denote multiple devices accessing a medium in which broadcasts and multicasts are heard by all devices sharing that medium (such as Ethernet).
- Nonbroadcast multiaccess: NBMA topologies are similar to broadcast multiaccess topologies (multiple devices accessing a medium), except that devices cannot hear each others’ broadcasts because the medium is separated by other routers, such as with Frame Relay.
- Point-to-point: A point-to-point link has only two devices on a shared network link. To demonstrate the point, consider how OSPF timers operate in different topologies. For instance, in broadcast multiaccess and point-to-point links, the hello and dead intervals are 10 and 40 seconds, respectively. Remember, these hello messages are not full routing updates like distance vector routing protocols. The hello messages contain minimal information to identify the sending device to other neighbor routers to ensure that their dead timers do not expire and cause a topology change.
Because NBMA network topologies such as Frame Relay typically comprise slower links, the default timers for these topologies are 30 seconds for hello messages and 120 seconds for the dead timer. The hello messages are not sent as often in NBMA topologies to ensure that OSPF routers do not needlessly consume bandwidth on the WAN links.
Another significant topology-related function of OSPF is the election of a Designated Router (DR) and a Backup Designated Router (BDR) in broadcast and nonbroadcast multiaccess topologies. Routers in these topologies undergo these elections to reduce the amount of update overhead that can be incurred when a link state changes.
For example, in Figure 12.3, all the routers in Area 7 are connected to a switch, which indicates a broadcast multiaccess topology.
If the link connected to Area 0 on ABR Router B were to fail, OSPF protocol dictates that it flood the update to all the neighbors in its neighbor table. When Router B sends that update to all the routers in the topology, all devices hear it because they are all connected to the same switch. However, recall that after the other routers receive that update, they have to alert all their neighbors—again, all the routers connected to the switch. This time, multiple routers send the update and cause excessive traffic on the switched network to devices that are already aware of the update. If you have a large number of routers in the topology, this update traffic can consume quite a bit of unnecessary bandwidth and processor utilization. In point-to-point links, it is not necessary to have a DR or BDR election, because only two routers are on the segment, and there is no threat of excessive update traffic.
Remember that DRs and BDRs are elected only on broadcast and nonbroadcast multiaccess networks.
When a DR and BDR are elected (in case the DR fails), routing updates are minimized, because the update is sent only to the DR and the BDR. The DR then is responsible for updating the rest of the topology. The election is determined by the following:
- Highest interface priority: An arbitrary number you can configure on an interfaceby-interface basis. The default is 1. A value of 0 renders the device ineligible for DR and BDR election.
- Highest router ID: In the event of a tie, the highest router ID is the tiebreaker.
Remember that a 0 value for an interface priority makes it ineligible to become a DR or BDR for that segment.
This election is based on the assumption that all devices start the OSPF process at the same time. Realistically, the first router that comes online is the DR, and the second is the BDR. If you need to set another router as the DR, you must take the current DR and BDR offline or restart the OSPF process to force the election.
Figure 12.4 shows the election process between several routers in a broadcast multiaccess topology. Because Router D’s interface priority is highest, that router becomes the DR for that segment. Router F, with the second-highest priority, becomes the BDR if Router D is turned off or crashes. Now if a link fails, the update is sent to Router D, which in turn updates the rest of the topology.
Be able to determine which routers will be elected the DR and BDR on each segment (decided by the highest interface priority, followed by the highest Router ID in the event of a tie). Also, keep in mind that DR and BDR elections can vary on an interface-by-interface basis. In other words, a router may be a DR on one segment and a BDR or neither on another interface segment.
One missing piece of this OSPF puzzle is how the devices manage to send updates to the DR and BDR routers only if they are all connected in the same topology. The answer lies in the manner in which OSPF routers propagate LSAs and LSUs. Rather than broadcast this information as RIPv1 does, OSPF sends updates to two different reserved multicast addresses. The multicast address, 126.96.36.199, is reserved for the DR and BDR. When a router needs to send an update in a broadcast or nonbroadcast topology, it sends the LSU to 188.8.131.52, which only the DR and BDR process.
The DR then sends the LSU to the multicast address of 184.108.40.206, which is the address to which all OSPF routers listen for updates and hello messages. So now when Router B detects the link failure, it multicasts its LSU to 220.127.116.11, which only Router D and Router F process. Because Router D is the DR, it disseminates the update to everyone else in the topology by sending the update to 18.104.22.168.
Recall that link-state routing protocols establish who the router’s neighbors are before exchanging updates. This process is actually quite intricate and depends on several factors. To clarify, let’s look at what happens when an OSPF router comes online. After the OSPF process is started in a router, it sends a hello message out all interfaces that are configured to participate in OSPF. The hello LSAs are sent to the multicast address of 22.214.171.124 so that all devices running OSPF process it.
Information contained in the hello messages includes the following: router ID, hello/dead intervals, known neighbors, area ID, priority, DR address, BDR address, authentication password (similar to RIPv2), and stub area flags (if the area is configured as a stub area). A router that receives this hello message adds that neighbor to its neighbor table only if the hello/dead intervals, area ID, authentication password, and stub flag match its configuration. If these values match, the router sends back a hello message, which includes the Router ID of the new router in the neighbor list. At that point, the original router adds that router to its neighbor table. This process occurs until the router discovers all the neighbors on its links.
Remember that the hello/dead intervals, authentication password, stub flag, and area ID must match in the hello LSAs to form a neighbor relationship.
It is important to note that no update information has been exchanged at this point. If the topology has a DR elected (indicated in the hello messages it received), it synchronizes its topology table with that router because the DR always has the most current information. If the topology is a point-to-point connection, the two routers synchronize with the neighbor on the other side of the link. After the topology tables are synchronized, it is said that the devices have formed an adjacency. Now that the router has all possible routes in the topology table, it can run the Dijkstra algorithm to calculate the best routes to each subnet.
Introduction to Configuring OSPF
One of the first steps you should take when configuring OSPF is to configure loopback interfaces to ensure that your Router ID matches the IP address of the loopback interface when the OSPF routing process is started. To create a virtual loopback interface, you configure it like a normal interface:
Router(config)#interface loopback 0
Router(config-if)#ip address 10.1.42.1 255.255.255.255
The interface number for the loopback interface is arbitrary because the interface is virtual. Also, notice that the subnet mask used in the loopback interface is 255.255.255.255 or a /32. This is known as a host mask. Typically it is used on loopback interfaces because there is no need to use an entire subnet on a virtual interface that doesn’t connect to anything.
Keep in mind for the exam that loopback interfaces typically have a subnet mask of 255.255.255.255, known as a host mask.
To start the OSPF process for configuration, you use the router keyword followed by ospf, just as you have in the past with other routing protocols. In the case of OSPF, however, you must specify a process ID after the router ospf keywords. The process ID is an arbitrary number ranging from 1 to 65535, in which the router can track whether you have multiple instances of OSPF running in your router. Because this process ID is only known on the local router that you configure, the process ID does not need to match in all router configurations.
Remember that the process ID is a locally significant number between 1 and 65535 that is used to track multiple instances of OSPF that might be running on the router. It does not have to match in all other router configurations.
Before we go further with the explanation of the OSPF configuration, you need to understand the means by which OSPF advertises the classless networks in the configuration. Because you no longer have the luxury of putting a classful subnet in the network statement, you need to have some way of telling the router what specific IP subnets are to be applied to the OSPF routing process. OSPF (as well as EIGRP and access lists) uses something called a wildcard mask to tell the IOS how much of an IP address should be applied to a criteria in a configuration statement. That criteria differs depending on which configuration statements the wildcard mask is using.
Wildcard masks are revisited with access lists in Chapter 19, “Using Cisco Access Lists.”
In the case of OSPF, the wildcard mask is used to define what portion of the IP in a network statement is to be associated with the routing process. If the IP addresses assigned to interfaces match the scope of the addresses defined with the IP address and wildcard mask criteria in the network entry, OSPF is enabled on those interfaces, and their subnets are advertised in routing updates.
Wildcard masks are represented as 32-bit numbers separated into four octets, just like IP
addresses and subnet masks. Each bit in the wildcard mask corresponds to the same bit position in the IP address to identify whether that bit should be applied to the criteria. Specifically, if the bit value in a wildcard mask is a 0, the corresponding bit in the IP address is checked and applied to the criteria. Conversely, a 1 in a wildcard mask bit signifies that the corresponding bit in the IP address can be ignored. Using these 0s and 1s, you are basically telling the IOS to perform pattern matching against the IP address that precedes the wildcard mask and to apply the portion that matches the conditions in the configuration statement.
For example, if you wanted to apply a wildcard mask to a specific IP address, every bit in the wildcard mask must be a 0 (0000000.0000000.0000000.0000000), because each corresponding bit in the IP address is being applied to the criteria. So, for example, if you wanted to specify the IP address of 10.1.4.2, the corresponding wildcard mask for that specific IP would be 0.0.0.0 in decimal. On the contrary, if you wanted to apply the criteria to any IP (therefore, you do not care whether any of the corresponding bits match), you would need to have a wildcard mask composed of all 1s (11111111.1111111.11111111.11111111, or 255.255.255.255 in decimal). Technically, it does not matter which IP address precedes this wildcard mask, because you are applying any value, so it is common to use an IP address of 0.0.0.0 with the 255.255.255.255 wildcard mask.
In cases such as those with OSPF, you need to use wildcard masks to specify a specific IP subnet. For instance, given an IP subnet of 192.168.1.0 /24, you know that you want to apply the criteria to the first 24 bits in the IP address. Because the last octet of the IP subnet can be any value from 0 to 255, you don’t want to apply any of those bits to your criteria. The resultant wildcard mask ultimately is composed of the first three octets in the wildcard mask, containing all 0s to match the 192.168.1, and the last octet, containing all 1s. Thus, the 192.168.1.0 /24 subnet would be identified as 192.168.1.0 0.0.0.255 in the configuration statement.
That may seem fairly cut and dried, but how do you apply a wildcard mask to a subnet such as 192.168.1.4 /30? You know that the first three octets will have all 0s, but you can’t say you don’t care about all 8 bits in the last octet, because you want to apply this criteria to only the IPs in the 192.168.1.4 255.255.255.252 subnet (192.168.1.4 to 192.168.1.7). As shown in Figure 12.5, by breaking the last octet into binary, you can see how to align the corresponding bits in the wildcard mask. Namely, the first 6 bits in the last octet must be exactly the same values that are in the IP address to give you a decimal value of 4. The last 2 bits can be any combination of 1s or 0s, because they will ultimately give you the values of 192.168.1.4, 192.168.1.5, 192.168.1.6, and 192.168.1.7. Because the first 6 bits must match, and the last two do not matter, the wildcard mask in binary for the last octet is 00000011, or 3 in decimal. So, to specify the 192.168.1.4 /30 subnet, your statement would look like 192.168.1.4 0.0.0.3.
An easier way to determine a wildcard mask for an entire subnet is to subtract the subnet mask from 255.255.255.255. For example, 255.255.255.255 – 255.255.255.252 = 0.0.0.3. In addition, the wildcard mask is always 1 less than the increment of the subnet in the octet where the subnet falls. For instance, a subnet of 255.255.255.252 has an increment of 4. So the wildcard mask in the last octet (because the /30 subnet falls in the last octet) is 1 less than the increment, or 0.0.0.3.
Notice in Figure 12.5 that the wildcard mask happens to be the inverse of the subnet mask. For this very reason, the wildcard mask is sometimes called the inverse mask. This is the case for all wildcard masks that correspond to an entire subnet.
You will be expected to be able to determine a wildcard mask given an IP address or an entire subnet for several concepts throughout the CCNA and ICND2 exams. It is imperative that you practice and master these calculations and be able to recognize an incorrect configuration if presented with a troubleshooting scenario.
OSPF Network Configuration
Reverting to the matter of configuring OSPF, you left off with entering the OSPF routing process by entering something similar to the following:
Router(config)#router ospf 4
Recall that the number 4 in this example is the process ID and does not have to match in all routers. Because you are in the routing process (indicated by the Router(config-router)# prompt) for OSPF, you are ready to specify the classless networks that are to participate in OSPF. As you do with other routing protocols, you start by using the keyword network, but from there you go a different direction. At this point, you need to specify an IP address or IP subnet, followed by the wildcard mask to identify which interfaces are participating in the OSPF process. Immediately following the IP and wildcard mask is the keyword area, followed by the OSPF area number where the router’s interface is located. For example, if you have an IP address of 192.168.1.1 with a subnet mask of 255.255.255.0 connected to area 0, you would configure it something like this:
Router(config)#router ospf 4
Router(config-router)#network 192.168.1.0 0.0.0.255 area 0
Be sure you understand the syntax involved in starting the OSPF process and assigning networks to that process. Because you use the wildcard mask in the OSPF configuration, you actually have multiple ways to specify an interface and its subnet in the OSPF routing process. Using the same example, you could use any of the configurations shown in Table 12.2 to place that interface in area 0.
Because there are so many ways you can advertise the networks with OSPF, the exam looks for one specific way. If it isn’t otherwise specified, specify the entire subnet for each interface.
Figure 12.6 shows the configuration for two of the routers in the multiarea OSPF autonomous system. First, notice that Router B and Router D do not have matching Router IDs. These values are significant locally only to those routers to keep track of multiple instances of OSPF that might be running. Router D has both interfaces in the backbone area, so you specify each subnet, using the appropriate wildcard mask, and identify the networks to be in Area 0. Notice that the configuration parameters are similar in Router B, except the interface that has the 192.168.1.8 subnet assigned to it is in Area 51. With that network placed in a different area, that router is now configured to be an ABR.
Additional OSPF Commands
As you know, OSPF is loaded with additional features and capabilities that make this routing protocol extremely adaptable. Throughout the course of your Cisco career, you may find yourself needing to configure additional parameters to fit the needs of your network. This section covers a few of the many configurations that OSPF offers.
For instance, in instances where you want to designate your area as a stub to decrease the amount of routing information stored in the topology database, you can use the area command in the routing process to identify that area as a stub:
Router(config-router)#area 51 stub
Remember, the stub flag was one of the required fields to form a neighbor relationship, so be sure you configure this for all routers that touch that area.
Because OSPF does not have automatic summarization, you have to configure these routers manually to summarize a set of networks. For example, if you wanted to summarize the 192.168.1.4 /24 to 192.168.1.7 /24 subnets in Area 51, you would use the range keyword in the area configuration, as in the following:
Router(config-router)#area 51 range 192.168.1.4 255.255.252.0
Similar to RIP, suppose your local router has a default route configured, and you want to redistribute that default route into OSPF so that other routers will dynamically learn the default route via OSPF updates. You would use the default-information originate command in the routing configuration:
Remember that the default-information originate command is used to generate a default route into OSPF updates. OSPF also has several commands that are actually configured on the interfaces as opposed to in the routing process. For example, if you wanted to manipulate the cost of an interface to make a network favorable over another or to force the router to load-balance, you could use
the ip ospf cost command:
Router(config)#interface serial 0/0
Router(config-if)#ip ospf cost 2
On interfaces that are connected to broadcast and nonbroadcast multiaccess topologies, it is highly recommended that you change the priority in the routers in which you want to force the DR and BDR election. By default, the priority is 1, but you can change that manually by using the ip ospf priority command as follows:
Router(config)#interface serial 0/0
Router(config-if)#ip ospf priority 3
Configuring OSPF with SDM
With all these configuration commands for OSPF we have encountered so far (which are only the tip of the iceberg), it is a relief to have some of these configurations simplified by the webbased SDM GUI. To begin, we should take similar steps as we did with the CLI configuration, which is to create a loopback interface. You can do this by selecting Configuration, Interface and Connections. From there, select the Edit Interface/Connection tab, and choose the Add tool at the top of the window. Choose New Logical Interface, Loopback, as shown in
Figure 12.7, to bring up the loopback configuration pop-up window.
Here you need to select Static IP Address from the pull-down menu. This allows you to input your IP address and subnet mask for this logical interface, as shown in Figure 12.8, which will inevitably become the router ID for your OSPF routing process.
With our loopback interface in place, it is time to configure the OSPF routing protocol parameters. Select Configure, Routing. Click the Edit button in the Dynamic Routing section. In the Edit IP Dynamic Routing dialog box, shown in Figure 12.9, choose the OSPF tab. Identify your process ID for OSPF, and click the Add button to add networks to the Network List. The Add an OSPF dialog box asks for the networks, wildcard masks, and area IDs for that OSPF process. As soon as all the networks have been advertised, the configurations are added to the runningconfig after you click OK.
. Verify router hardware and software operation using SHOW & DEBUG commands
Because there are so many aspects to OSPF, you have a considerable number of show commands at your disposal to verify OSPF operations. As before, you can use show runningconfig to verify the local configuration of your routing protocol. In the case of OSPF, this is useful to ensure that you configured the network and wildcard mask correctly, as well as associated the network with the correct area. In addition, show ip protocols again shows you information about the networks you are advertising with OSPF.
Recall that OSPF maintains three separate tables in its routing process: the routing table, the neighbor table, and the topology table. You are already familiar with the show ip route command to view the routing table and verify whether you are receiving OSPF networks from the neighbors:
RouterA>show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default
U - per-user static route, o - ODR
Gateway of last resort is not set
O IA 172.17.0.0/16 [110/74] via 192.168.1.6, Serial0/0
C 172.16.0.0/16 is directly connected, FastEthernet0/0
O 172.18.0.1/16 [110/65] via 192.168.1.6, Serial0/0
10.0.0.0/32 is subnetted, 1 subnets
C 10.1.42.1 is directly connected, Loopback0
192.168.1.0/30 is subnetted, 1 subnets
C 192.168.1.4 is directly connected, Serial0/0/0
The 172.17.0.0 and 172.18.0.0 networks in this example were learned via OSPF through the
Serial 0/0/0 interface. Notice that the 172.17.0.0 entry has an IA (interarea) indicator. It signifies that this network was learned from an ABR and that the network resides in another area.
To see a listing of the neighbors that were discovered through LSA hello advertisements, you
can look in your router’s neighbor table by using the show ip ospf neighbor command:
RouterA>show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
10.1.42.100 10 FULL/DR 00:00:39 192.168.1.6 Serial0/0
The Neighbor ID is actually the Router ID of the neighbor that is being advertised in the
neighbor’s hello messages. The Pri field indicates the priority configured on your neighbors’
interfaces. Because the default priority is 1 and this neighbor has a priority of 10, that router
happens to be the DR for that segment, as shown in the State field. The other possible values
for this state are BDR and DROTHER (not DR or BDR), depending on whether those
routers won the election on that segment.
The show ip ospf database command shows the third table that OSPF maintains: the topology table. This table lists all the network entries and the advertising routers for those entries.
From this table, the SPF algorithm is run, and the routes with the lowest cumulative cost
are put in the routing table. Here you can see the output of the show ip ospf database
summary command, because the information is presented in a more intelligible output:
RouterA>show ip ospf database summary
OSPF Router with ID (10.1.42.1) (Process ID 1)
Summary Net Link States (Area 51)
Routing Bit Set on this LSA
LS age: 537
Options: (No TOS-capability, DC)
LS Type: Summary Links(Network)
Link State ID: 172.17.0.0 (summary Network Number)
Advertising Router: 10.1.42.100
LS Seq Number: 80000001
Network Mask: /16
TOS: 0 Metric: 10
You can see the 172.17.0.0 network you learned from the neighbor router, 10.1.42.100, and the cost of the link associated with that network.
In a larger-scale example, there could be hundreds of these networks that have been learned from other routers in the OSPF area and in other areas as well.
The final show command for OSPF is actually extremely useful when you want to gather information about the network topologies that are connected to the router’s interfaces. The show ip ospf interface command yields a wealth of information, such as the local router’s Router ID, interface topology type, link cost and priority, router ID for the DR and BDR on the segment, hello/dead intervals, and a count of how many neighbors and adjacencies formed:
RouterA#show ip ospf interface
FastEthernet0/0 is up, line protocol is up
Internet Address 172.16.0.1/16, Area 51
Process ID 4, Router ID 10.1.42.1, Network Type BROADCAST, Cost: 1
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 10.1.42.1, Interface address 172.16.0.1
No backup designated router on this network
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:03
Supports Link-local Signaling (LLS)
Index 2/2, flood queue length 0
Last flood scan length is 0, maximum is 0
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 0, Adjacent neighbor count is 0
Suppress hello for 0 neighbor(s)
Serial0/0/0 is up, line protocol is up
Internet Address 192.168.1.5/30, Area 0
Process ID 4, Router ID 192.168.100.155, Network Type POINT_TO_POINT, Cost: 64
Transmit Delay is 1 sec, State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:07
Supports Link-local Signaling (LLS)
Index 1/1, flood queue length 0
Last flood scan length is 0, maximum is 0
Last flood scan time is 0 msec, maximum is 0 msec
Neighbor Count is 0, Adjacent neighbor count is 0
Suppress hello for 0 neighbor(s)
The show ip ospf neighbor and show ip ospf interface commands can show you which router is the DR and which is the BDR.
. Troubleshoot routing issues
At the risk of sounding like a broken record, you should begin your troubleshooting by using the show commands discussed in the preceding section to ensure that your configurations are correct. Some of the more common problems that occur with OSPF configurations are simple mistakes such as those that occur with incorrect network statements (incorrect network ID, wildcard mask, or area) and forgetting to configure each router as a stub in a stub area.
In cases where the configuration checks out, OSPF also can debug routing information in real time if you use the debug ip ospf events command. This command is useful if you are trying to troubleshoot occurrences such as routers that cannot form a neighbor relationship. In the following example, you can see that a hello message has been received from 10.1.42.100. Notice that no real routing information is shown in these hello messages, because OSPF does not send entire routing updates in its hello LSAs.
RouterA#debug ip ospf events
OSPF events debugging is on
00:57:13: OSPF: Rcv hello from 10.1.42.100 area 51 from Serial0/0 192.168.1.6
00:57:13: OSPF: End of hello processing
It is time to test your OSPF configuration skills. In this challenge, you configure a new OSPF router given the following parameters: Fast Ethernet interface IP: 172.16.100.65 /27 Area 0 Serial interface IP: 192.168.100.9 /30 Area 1 Router ID: 10.1.1.1 /32
- Ensure that the Router ID is configured before you configure the OSPF router process.
- Configure the OSPF router process using an ID of 65535.
- Advertise the entire Fast Ethernet subnet, and place it in the backbone area.
- Advertise the entire Serial subnet, and place it in Area 1.
- Configure Area 1 as a stub.
- Navigate to the Fast Ethernet interface, and make sure your router becomes the DR by setting the priority to 2.
Based on the parameters specified, your router configuration should resemble the following:
ip address 10.1.1.1 255.255.255.255
router ospf 65535
network 172.16.100.64 0.0.0.31 area 0
network 192.168.100.8 0.0.0.3 area 1
area 1 stub
ip ospf priority 2
To configure the router ID, you have to assign the IP address of 10.1.1.1 with a host mask of 255.255.255.255 to a virtual loopback interface so that it is chosen over the physical interfaces. After the OSPF process has begun, you need to advertise both subnets attached to the interfaces. The network ID for the Fast Ethernet interfaces is 172.16.100.64. The wildcard mask for a subnet of 255.255.255.224 is 0.0.0.31 (255.255.255.255 to 255.255.255.224). Likewise, the network ID for 192.168.100.9 is 192.168.100.8 with a wildcard mask of 0.0.0.3 (255.255.255.255 to 255.255.255.252).
Balanced Hybrid Operations
- Compare and contrast methods of routing and routing protocols
Balanced hybrid routing protocols are sometimes called advanced distance vector routing protocols. The rationale behind this logic is that these routing protocols use similar metrics and have a maximum hop count as distance vector routing protocols. However, balanced hybrid routing protocols discover neighbors and put them in a neighbor table before exchanging routing information, as well as keep lists of all possible routes in a topology table, just as link-state routing protocols do. By taking the best attributes from both classes of routing protocols, they have the pick of the litter, so to speak. This enables these routing protocols to be considered some of the more elite routing protocols.