Problems with Running OSPF in NBMA and Broadcast Mode over Frame RelayPrintable Pdf
Document ID: 13696
Introduction Prerequisites
Requirements
Components Used
Conventions
Background Theory Problem
Causes Solution NetPro Discussion Forums - Featured Conversations Related Information
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.
NetPro Discussion Forums - Featured Conversations
Networking Professionals Connection is a forum for networking professionals to share questions, suggestions,
and information about networking solutions, products, and technologies. The featured links are some of the
most recent conversations available in this technology.
Related Information
Troubleshooting OSPF
OSPF Design Guide
OSPF Neighbor Problems Explained
Initial Configurations for OSPF over Non-Broadcast Links
Initial Configurations for OSPF over Frame Relay Subinterfaces
