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.

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.

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.

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:

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 below—which displays the Adv router is
not-reachable message.

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.