In preparation of our CCNP exam, we want to make sure we cover the various concepts that we could see on our Cisco CCNP exam. So to assist you, below we will discuss Why do routes appear in the OSPF database but not in the routing table in a frame.
Introduction
This Tech Note explains an issue of OSPF routes appearing in the Link State database but not in the routing table in a fully meshed Frame Relay environment. For more scenarios, see Why Are Some OSPF Routes in the Database but Not the Routing Table?
Prerequisites
Requirements
Readers of this document should have knowledge of these topics:
- OSPF
- Frame Relay
Components Used
This document is not restricted to specific software and hardware versions. However, the configuration in this document is tested and updated by use of these software and hardware versions:
- Cisco 2500 Series Router
- Cisco IOS® version 12.2(24a)
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Conventions
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
Background Theory
The example below uses a fully meshed Frame Relay environment. The network diagram and configurations are shown below:
Problem
Initially, all routers have all routes in their neighbor tables. An event occurs that causes Doc and Sleepy to drop each other from their respective neighbor tables. From the neighbor tables given in this section, we can see that the Doc neighbor table does not have the entry 70.70.70.70 and the Sleepy neighbor table does not have the entry 50.50.50.50.
In addition, Doc loses all OSPF routes from its routing table, and Sleepy and Sneezy no longer have 50.50.50.0 (Doc's LAN subnet) in their routing tables.
Although Doc does not have any OSPF routes in its routing table, we can see from the output below that it does have a complete OSPF database.
The network link-state is a link state generated by the designated router (DR) that describes all the routers attached to the network. In the output below, we see that the DR does not list the Doc Router ID (50.50.50.50) as an attached router, which breaks the broadcast model. Therefore Doc does not install any OSPF routes learned through the Frame Relay network.
Another way to look at this is that Doc declares Sneezy as a DR and expects Sneezy to generate a network link-state. However, since Sneezy is not a DR, it does not generate a network link-state, which in turn does not allow Doc to install any routes in its routing table.
Causes
According to the database, the DR for the Frame Relay cloud is Sleepy. However, Sleepy does not see Doc as an OSPF neighbor. As seen in this example, the ping from Sleepy to Doc fails:
sleepy# ping 10.10.10.5
Type escape sequence to abort.
Sending 5, 100- byte ICMP Echos to 10.10.10.5, timeout is 2 seconds:
…..
Success rate is 0 percent (0/ 5)
From the output of the show frame-relay map command in Sleepy, we can see that the DLCI going to Doc is inactive. That explains why Sleepy cannot ping Doc, and why they do not see each other as neighbors. This is the event that triggered the problem:
sleepy#
show frame-relay map
Serial0.1 (up): ip 10.10.10.5 dlci 101( 0x65,0x1850), static,
broadcast,
CISCO, status defined, inactive
Serial0.1 (up): ip 10.10.10.10 dlci 102( 0x66,0x1860), static,
broadcast,
CISCO, status defined, active
Because the PVC between Doc and Sleepy is broken, and Doc's link to the designated router (DR) is broken, Doc declares all LSAs from Sneezy (which is not a DR) as unreachable. The broadcast model over Frame Relay works properly if the Frame Relay cloud is fully meshed. If any permanent virtual circuits (PVCs) are broken, it can create problems in the OSPF database, which is evident from the show ip ospf database router command output shown belowwhich displays the Adv router is not-reachable message.
Solution
When you configure OSPF to run over a broadcast-capable or non-broadcast, multi-access network, all devices must be able to communicate directly with (at a minimum) the designated router. The broadcast and NBMA model relies on the Frame Relay cloud being fully meshed. If a permanent virtual circuit (PVC) goes down, the cloud is no longer fully meshed and OSPF fails to work correctly.
In a Frame Relay environment, if Layer 2 is unstable, as in our example, we do not recommend an OSPF broadcast network-type. Use OSPF point-to-multipoint instead.
We hope you found this Cisco certification article helpful. We pride ourselves on not only providing top notch Cisco CCNP exam information, but also providing you with the real world Cisco CCNP skills to advance in your networking career.