Problems with Running OSPF in NBMA and Broadcast Mode over Frame Relay

Available Languages

Download Options

  • PDF     (28.5 KB)
    View with Adobe Reader on a variety of devices
Updated:December 29, 2005
Document ID:13696

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

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:

24a.gif

Doc 
interface Ethernet0 
 ip address 50.50.50.50 255.255.255.0 

interface Serial0 
 encapsulation frame-relay 

!--- Enables Frame Relay encapsulation on the interface.

interface Serial0.1 multipoint 

!--- The subinterface is configured as a multipoint link.

 ip address 10.10.10.5 255.255.255.0 
 ip ospf network broadcast 

!--- This command is used to define the network type as broadcast.


!--- The network type is defined on nonbroadcast networks to
 

!--- avoid configuring the neighbors explicitly.

 frame-relay map ip 10.10.10.6 101 broadcast 
 frame-relay map ip 10.10.10.10 100 broadcast 

!--- To define the mapping between a destination protocol address


!--- and the data-link connection identifier (DLCI) used to
 

!--- connect to the destination address.
  

!--- The broadcast keyword is used to forward broadcasts to
 

!--- this address when broadcast/multicast is
 

!--- disabled because of non-broadcast medium.

router ospf 1 
 network 0.0.0.0 255.255.255.255 area 0

Sleepy 
interface Ethernet0 
  ip address 70.70.70.70 255.255.255.0 

 interface Serial0 
  encapsulation frame-relay

!--- Enables Frame Relay encapsulation on the interface. 
interface Serial0.1 multipoint 

!--- The subinterface is configured as a multipoint link. 
  ip address 10.10.10.6 255.255.255.0 
  ip ospf network broadcast

!--- This command is used to define the network type as broadcast. 
!--- The network type is defined on nonbroadcast networks to 

!--- avoid configuring the neighbors explicitly. 
  frame-relay map ip 10.10.10.5 101 broadcast 
  frame-relay map ip 10.10.10.10 102 broadcast 

!--- To define the mapping between a destination protocol address !--- and the DLCI used to connect to the destination address. !--- The broadcast keyword is used to forward broadcasts to !--- this address when broadcast/multicast is !--- disabled because of non-broadcast medium.

 router ospf 1 
  network 0.0.0.0 255.255.255.255 area 0

Sneezy 
interface Ethernet0 
  ip address 60.60.60.60 255.255.255.0 

 interface Serial0 
  encapsulation frame-relay 

!--- Enables Frame Relay encapsulation on the interface.

 interface Serial0.1 multipoint

!--- The subinterface is configured as a multipoint link. 

  ip address 10.10.10.10 255.255.255.0 
  ip ospf network broadcast

!--- This command is used to define the network type as broadcast. !--- The network type is defined on nonbroadcast networks to !--- avoid configuring the neighbors explicitly.
 


  frame-relay map ip 10.10.10.5 100 broadcast 
  frame-relay  map ip 10.10.10.6 102 broadcast 

!--- To define the mapping between a destination protocol address !--- and the DLCI used to connect to the destination address. !--- The broadcast keyword is used to forward broadcasts to !--- this address when broadcast/multicast is !--- disabled because of non-broadcast medium.

 router ospf 1 
  network 0.0.0.0 255.255.255.255 area 0

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.

Doc Neighbor Table 
doc# 
show ip ospf neighbor

  
 Neighbor ID Pri State        Dead Time Address     Interface
 60.60.60.60 1   FULL/DR      00:00:33 10.10.10.10  Serial0.1
Sleepy Neighbor Table 
sleepy# show ip ospf neighbor

 Neighbor ID Pri State        Dead Time Address     Interface
 60.60.60.60 1   FULL/BDR     00:00:32 10.10.10.10  Serial0.1
Sneezy Neighbor Table 
sneezy# show ip ospf neighbor

 Neighbor ID Pri State        Dead Time Address     Interface
 50.50.50.50 1   FULL/DROTHER 00:00:36  10.10.10.5  Serial0.1
 70.70.70.70 1   FULL/DR      00:00:31  10.10.10.6  Serial0.1

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.

Doc Routing Table 
doc# 
show ip route

 Gateway of last resort is not set
      10.0.0.0 255.255.255.0 is subnetted, 1 subnets
 C       10.10.10.0 is directly connected, Serial0.1
      50.0.0.0 255.255.255.0 is subnetted, 1 subnets
 C       50.50.50.0 is directly connected, Ethernet0
Sleepy Routing Table 
sleepy# show ip route
 Gateway of last resort is not set
      10.0.0.0/ 24 is subnetted, 1 subnets
 C       10.10.10.0 is directly connected, Serial0.1
      60.0.0.0/ 24 is subnetted, 1 subnets
 O       60.60.60.0 [110/ 11175] via 10.10.10.10, 00: 07: 25, Serial0.1
      70.0.0.0/ 24 is subnetted, 1 subnets
 C    70.70.70.0 is directly connected, Ethernet0
Sneezy Routing Table 
sneezy# show ip route
 Gateway of last resort is not set
      10.0.0.0/ 24 is subnetted, 1 subnets
 C       10.10.10.0 is directly connected, Serial0.1
      60.0.0.0/ 24 is subnetted, 1 subnets
 C       60.60.60.0 is directly connected, Ethernet0
      70.0.0.0/ 24 is subnetted, 1 subnets
 O       70.70.70.0 [110/ 11175] via 10.10.10.6, 00: 07: 53, Serial0.1

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.

Doc Database 
doc# 
show ip ospf database


                               OSPF Router with ID (50.50.50.50) (Process ID 1)

                                          Router Link States (Area 0)

 Link ID       ADV Router    Age    Seq#        Checksum Link count
 50.50.50.50   50.50.50.50   169    0x80000030  0x3599   2
 60.60.60.60   60.60.60.60   1754   0x8000002F  0xD26D   2
 70.70.70.70   70.70.70.70   1681   0x8000002D  0xFDD9   2

                                           Net Link States (Area 0)

 Link ID       ADV Router    Age    Seq#        Checksum
 10.10.10.6    70.70.70.70   569    0x8000002B  0x8246

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.

Network Link-State 
doc# 
show ip ospf database network 10.10.10.6


                                           Net Link States (Area 0)

 LS Type: Network Links
 Link State ID: 10.10.10.6 (address of Designated Router)
 Advertising Router: 70.70.70.70

 Network Mask: 255.255.255.0
       Attached Router: 70.70.70.70
       Attached Router: 60.60.60.60

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.

Doc Neighbor Table 
doc# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
60.60.60.60       1   FULL/DR         00:00:29    10.10.10.10     Serial0.1

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

Doc Neighbor Table 
doc# 
show ip ospf database router

             OSPF Router with ID (50.50.50.50) (Process ID 1)

                Router Link States (Area 0)

  LS age: 57
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 50.50.50.50
  Advertising Router: 50.50.50.50
  LS Seq Number: 800000D4
  Checksum: 0x355D
  Length: 48
  Number of Links: 2

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 10.10.10.10
     (Link Data) Router Interface address: 10.10.10.5
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 50.50.50.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 10


  Adv Router is not-reachable
  LS age: 367
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 60.60.60.60
  Advertising Router: 60.60.60.60
  LS Seq Number: 800000C9
  Checksum: 0xC865
  Length: 48
  Number of Links: 2

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 10.10.10.6
     (Link Data) Router Interface address: 10.10.10.10
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 60.60.60.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 10


  Adv Router is not-reachable
  LS age: 53
  Options: (No TOS-capability, DC)
  LS Type: Router Links
  Link State ID: 70.70.70.70
  Advertising Router: 70.70.70.70
  LS Seq Number: 800000CA
  Checksum: 0xEDD4
  Length: 48
  Number of Links: 2

    Link connected to: a Transit Network
     (Link ID) Designated Router address: 10.10.10.6
     (Link Data) Router Interface address: 10.10.10.6
      Number of TOS metrics: 0
       TOS 0 Metrics: 64

    Link connected to: a Stub Network
     (Link ID) Network/subnet number: 70.70.70.0
     (Link Data) Network Mask: 255.255.255.0
      Number of TOS metrics: 0
       TOS 0 Metrics: 10

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.

Related Information

Revision History

Revision Publish Date Comments
1.0
29-Dec-2005
Initial Release

Was this Document Helpful?

FeedbackFeedback

Contact Cisco

This Document Applies to These Products