This tutorial is dedicated to the OSPF non-broadcast network type. You will learn what OSPF non-broadcast network type is, how it works, how to configure and verify that OSPF network type on Cisco IOS, how OSPF represents non-broadcast multi-access (NBMA) links in router/network LSAs, how the DR/BDR election process works over OSPF non-broadcast interfaces, and an issue of OSPF when it is running over Frame Relay partial mesh networks. But before that, I will explain some fundamental concepts about Frame Relay.

In this guide, I will be using the following network topologies.

 

Figure 1 – Full mesh Frame Relay network

Here are the initial router configurations for this first network diagram.

Router R1 Router R2 Router R3 Router R4

 

Figure 2 – Partial mesh Frame Relay network

For this second network topology, the routers have been initially configured like the following.

Router R1 Router R2 Router R3 Router R4

Note that in both network diagrams above, all routers can ping each other’s IP address in subnet 10.0.0.0/24. We use the encapsulation frame-relay command to enable the Frame Relay data-link protocol on the serial 1/0 interfaces.

Moreover, we use the frame-relay map ip command to tell routers what DLCIs to use in order to reach IP addresses on the Frame Relay network. This last step is essential for routers in order to exchange IP packets over those WAN networks.

Finally, all interfaces are advertised in OSPF area 0, and the network type of the loopback interfaces is set to point-to-point so that their corresponding subnets get advertised with their real subnet masks.

What is Non-Broadcast Network?

In the context of layer 2 protocols, a non-broadcast network is a type of medium that allows more than two devices to communicate, and in which devices cannot broadcast packets to all other devices on the medium.

In other words, network devices cannot send one layer 2 frame with a specific destination layer 2 address and hope it reaches all devices on the medium. Instead, they must use a point-to-point or point-to-multipoint communication network topology to exchange layer 2 frames.

Quick Overview About Frame Relay as a Non-Broadcast Multi-Access Network (NBMA)

What is Frame Relay?

Frame Relay (FR) is a data communication protocol that is used to transmit layer 2 frames over wide area networks (WANs). It is a high-speed and packet-switched technology that is implemented to transfer data between end devices located at different geographical locations.

Unlike point-to-point layer 2 protocols, Frame Relay allows building up non-broadcast multi-access networks, which allows more than two devices to connect over the network while prohibiting layer 2 broadcast and multicast frames.

Frame relay works by dividing layer 2 frames into small units. These data units are transmitted over a shared communication cloud of Frame Relay switches, which are used to establish virtual circuits (VCs) between the devices.

A Frame Relay virtual circuit (VC) is a logical connection between two devices in a frame relay network. A virtual circuit represents a bidirectional communication path from one FR end device to another.

This means the end devices of the virtual circuit are often not directly wired together and they are separated by a cloud of intermediated devices whose role is forwarding Frame Relay frames between the VC’s endpoints.

Moreover, a virtual circuit is established by the ISP’s switches or routers and allows data to be transmitted between the devices over a shared network, which is used by a lot of Frame Relay customers.

It is called a virtual circuit because end devices connected to the Frame Relay cloud do not know the exact path layer 2 frames take to go from one device to the other.

For example, we have four virtual circuits in Figure 2. Three VCs are connecting R1 to R2, R3, and R4, and one VC connects R2 to R3. On the other hand, we have six virtual circuits in Figure 1.

When a VC is established in a frame relay network, a DLCI is assigned to it. The DLCI is used by the current router to forward data to the other device on the VC. A DLCI identifies a VC locally on the physical link.

Overall, a data link connection identifier (DLCI) is a unique identifier that is used to identify a VC on a specific physical link/interface.

Figure 3 – Initial R1’s Frame Relay frame encapsulating an ICMP echo request message destined for R2

When router R1, in Figure 2, sends layer 2 frames, carrying ICMP echo-request packets, with DLCI 102 (Figure 3), that traffic reaches router R2 and it appears with DLCI 201 to it (Figure 4), and vice versa.

Figure 4 – Actual content of an R1’s Frame Relay frame, encapsulating an ICMP echo request message, received by R2

Non-broadcast networks, like Frame Relay, support two types of network topologies:

Partial Mesh Frame Relay Topology

Partial mesh Frame relay topology is a type of network configuration in which some, but not all, devices in a network may be connected to every other device. This means that not all devices have a dedicated virtual circuit to each other, but they can still communicate through intermediate devices.

For example, the network diagram in Figure 2 represents a partial mesh Frame Relay topology. R1 has dedicated VCs to all other routers. R4 has a connection to R1 only; however, it can ping R2 and R3 simply by using R1 as a next-hop router when sending traffic destined to them. To achieve that, we need to map the IP addresses of R2 and R3 with DLCI 401 that is identifying the virtual circuit connecting R4 to R1.

Partial mesh Frame relay topologies are often used in networks where there are a large number of devices and it is not practical or cost-effective to connect every router to every other router. It can also be used in networks where devices are located in different geographical areas and it is not possible to establish a direct connection between them.

Full Mesh Frame Relay Topology

Full mesh Frame relay topology is a network configuration type in which every Frame Relay device has a virtual circuit to every other device on the network. In fact, all devices can send Frame Relay frames to each other without the necessity for intermediate devices.

Figure 1 represents an example of a full mesh Frame Relay network. Each router has VCs to the other routers.

What is OSPF Non-Broadcast Network Type?

The OSPF non–broadcast network type is an operating mode in which OSPF considers the link as non-broadcast multi-access (NBMA) and performs similarly to what it does on broadcast networks except using multicast OSPF hellos.

In this mode, OSPF nodes build/maintain neighbor relationships, elect a DR and BDR, and use unicast IP addresses when exchanging OSPF hellos and packets.

OSPF non–broadcast is the default network type for main Frame Relay interfaces and Frame Relay multipoint subinterfaces, as illustrated in this example. Additionally, the default hello and dead intervals are 30 and 120 seconds, respectively.

R1# show ip ospf interface serial 1/0
Serial1/0 is up, line protocol is up 
  Internet Address 10.0.0.1/24, Area 0 
  Process ID 1, Router ID 10.0.0.1, Network Type NON_BROADCAST, Cost: 64
  Topology-MTID    Cost    Disabled    Shutdown      Topology Name
        0           64        no          no            Base
  Transmit Delay is 1 sec, State DR, Priority 1
  Designated Router (ID) 10.0.0.1, Interface address 10.0.0.1
  No backup designated router on this network
  Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5
    oob-resync timeout 120
    Hello due in 00:00:21

omitted output

A Frame Relay multipoint subinterface is a virtual router interface supporting multiple DLCIs like in this example.

R4(config)# interface Serial1/0
R4(config-if)# encapsulation frame-relay
R4(config-if)# no shutdown
R4(config-if)# exit
R4(config)# 
R4(config)# interface Serial1/0.1 multipoint
R4(config-subif)# ip address 10.0.0.4 255.255.255.0
R4(config-subif)# frame-relay map ip 10.0.0.1 401
R4(config-subif)# frame-relay map ip 10.0.0.2 401
R4(config-subif)# frame-relay map ip 10.0.0.3 401

How Does OSPF Non-Broadcast Network Type Work?

Non-broadcast networks are commonly used to connect distant sites or networks over a Wide Area Network (WAN) network cloud, such as Frame Relay or ATM.

An NBMA network is characterized by the absence of layer 2 broadcast capability, which requires some manual configurations to set up OSPF over that network medium type because neighbor adjacencies cannot get established automatically as on network links supporting broadcast layer 2 frames.

How Do OSPF Routers Build Neighbor Relationships and Communicate Over a Non-Broadcast Link?

OSPF does not use multicast hellos on non-broadcast multi-access networks. OSPF requires configuring manually OSPF neighbors with which each OSPF node wants to build neighbor relationships. Otherwise, no OSPF adjacencies can be formed.

For example, in the initial router configurations above, even though all interfaces are advertised in OSPF area 0, the routers cannot build up neighbor relationships, as illustrated in this example which indicates that R1’s OSPF neighbor list is empty.

R1# show ip ospf neighbor

R1#

To fix this issue, we have to use the neighbor command in order to specify routers with which to establish OSPF neighbor relationships. The command has to be configured on at least one end of the virtual circuit.

For instance, to instruct routers R1 and R2 to form an OSPF neighbor relationship, it is enough to issue the neighbor command on either R1 or R2. It is unnecessary to use it on both routers.

Since we have six VCs in Figure 1, it is enough to issue the neighbor command six times, meaning one time for each VC, in order to start negotiating OSPF neighbor adjacencies in the network.

In these examples, we configure R1, in Figure 1, to exchange OSPF hellos with R2, R3, and R4. We set up R2 to initiate negotiating OSPF relationships with R3 and R4. Finally, we configure R3 to form an OSPF adjacency with R4.

Router R1

R1(config)# router ospf 1
R1(config-router)# neighbor 10.0.0.2
R1(config-router)# neighbor 10.0.0.3
R1(config-router)# neighbor 10.0.0.4

Router R2

R2(config)# router ospf 1
R2(config-router)# neighbor 10.0.0.3
R2(config-router)# neighbor 10.0.0.4

Router R3

R3(config)# router ospf 1
R3(config-router)# neighbor 10.0.0.4

The configuration is working fine. R4 and R3 are elected as DR and BDR, as you stated in this example.

R1# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
N/A               0   ATTEMPT/DROTHER 00:00:35    10.0.0.2        Serial1/0
10.0.3.3          1   FULL/BDR        00:01:35    10.0.0.3        Serial1/0
10.0.4.4          1   FULL/DR         00:01:47    10.0.0.4        Serial1/0

DR/BDR Election Issues on Partial Mesh Frame Relay Networks

Similar to the previous examples, to instruct routers R1 and R2 (Figure 2) to form an OSPF neighbor relationship, it is enough to issue the neighbor command on either R1 or R2.

In these examples, we configure R1, in Figure 2, to exchange OSPF hellos with R2, R3, and R4. Additionally, we set up R3 to initiate negotiating an OSPF relationship with R2.

Router R1

R1(config)# router ospf 1
R1(config-router)# neighbor 10.0.0.2
R1(config-router)# neighbor 10.0.0.3
R1(config-router)# neighbor 10.0.0.4

Router R3

R3(config)# router ospf 1
R3(config-router)# neighbor 10.0.0.2

The following show ip ospf neighbor command outputs state that two DRs and BDRs got elected on the network.

Router R1

R1# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.0.2.2          1   FULL/BDR        00:01:46    10.0.0.2        Serial1/0
10.0.3.3          1   2WAY/DROTHER    00:01:57    10.0.0.3        Serial1/0
10.0.4.4          1   FULL/DR         00:01:35    10.0.0.4        Serial1/0

Upon the exchange of OSPF hellos with routers R2, R3, and R4, R1 finds that R4 is the DR and R2 is the BDR, and thus it forms OSPF adjacencies with them and ignores R3 since it is declaring itself as a DR while R1 thinks R4 is the DR for the non-broadcast network.

Moreover, R1 would exchange LSAs with R4 only, and thus it would have access to R4’s loopback only, as stated in the show ip route command output. Likewise, R4 would reach R1’s loopback0 interface.

R1# show ip route

omitted output

      10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
C        10.0.0.0/24 is directly connected, Serial1/0
L        10.0.0.1/32 is directly connected, Serial1/0
C        10.0.1.0/24 is directly connected, Loopback0
L        10.0.1.1/32 is directly connected, Loopback0
O        10.0.4.0/24 [110/65] via 10.0.0.4, 00:15:26, Serial1/0

Router R2

R2# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.0.1.1          1   FULL/DROTHER    00:01:37    10.0.0.1        Serial1/0
10.0.3.3          1   FULL/DR         00:01:54    10.0.0.3        Serial1/0

Router R3

R3# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.0.1.1          1   EXSTART/DROTHER 00:01:32    10.0.0.1        Serial1/0
10.0.2.2          1   FULL/BDR        00:01:53    10.0.0.2        Serial1/0

R2 and R3 exchanged OSPF hellos, which result in electing R3 and R2 as the DR and BDR, respectively. Therefore, R2 and R3 can reach subnets 10.0.3.0/24 and 10.0.2.0/24, respectively.

Router R4

R4# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.0.1.1          1   FULL/BDR        00:01:55    10.0.0.1        Serial1/0

To sum up, letting routers on a partial mesh non-broadcast medium elect themselves automatically the DR and BDR would result in dividing routers into multiple groups, thus creating distinct LSDBs of the same OSPF area and resulting in inconsistent routing information.

You would think we can solve this issue by configuring R4 to negotiate OSPF neighbor relationships with R2 and R3. However, this is impossible because OSPF hellos sent by R4 to R2 and R3, and vice versa, cannot be transmitted by R1 because the TTL field of OSPF hello packets is 1, and thus those hellos would get dropped once they reach R1.

To fix such an issue, the router having direct layer 2 connections with all routers in the non-broadcast multi-access network should be elected as Designated Router (DR). To do so, we configure the neighbor command on R1 only, and prevent routers R2 and R3, and R4 from becoming DRs or BDRs by setting their OSPF priority on the non-broadcast network to 0.

How Do OSPF Routers Calculate The Next-Hop Address for a Route Associated with a Router LSA Received over a Non-Broadcast Network?

Similar to broadcast networks, the designated router distributes LSAs it does receive from OSPF adjacent neighbors on the network, including router LSAs, to all routers on the same link. It is the responsibility of each OSPF node to calculate the next-hop IP address of each route in the network.

For example, when R2 gets R3’s router LSA, it would set the next-hop address for subnet 10.0.3.0/24 to 10.0.0.3, R3’s IP address on the network, which represents the starting point of the shortest path to that subnet.

If router R2 does not know to which DLCI IP address 10.0.0.3 should be mapped, the router cannot forward traffic destined to 10.0.3.0/24 even if it has a route for it in its routing table. Therefore, a Frame Relay map for that IP address should be configured either manually or automatically.

In this example, we remove the Frame Relay mapping between IP address 10.0.0.3 and DLCI 203 from R2’s configuration (Figure 1), and then delete automatic entries in the Frame Relay mapping table.

R2(config)# interface serial 1/0
R2(config-if)# no frame-relay map ip 10.0.0.3 203
R2(config-if)# end
R2# clear frame-relay inarp

Now, R2 cannot ping 10.0.3.3 even though its routing table includes a route to subnet 10.0.3.0/24, as you can see in these examples.

R2# ping 10.0.3.3

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.3.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

R2# show ip route ospf
Codes: L - local, C - connected, S - static, 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
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route, + - replicated route

Gateway of last resort is not set

      10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
O        10.0.1.0/24 [110/65] via 10.0.0.1, 00:29:21, Serial1/0
O        10.0.3.0/24 [110/65] via 10.0.0.3, 00:29:21, Serial1/0
O        10.0.4.0/24 [110/65] via 10.0.0.4, 00:29:21, Serial1/0

To fix this issue, it is enough to map IP address 10.0.0.3 to whatever DLCI that allows IP packets sent to that IP gateway to get delivered. Meaning that it is not mandatory to associate that IP address with DLCI 203, but we can map it for example with DLCI 201. In this case, router R1 will have to redirect them to R3. However, it is recommended to map 10.0.0.3 with DLCI; otherwise, it is waste of time and bandwidth.

How Does OSPF  Represent Non-Broadcast Networks in Router and Network LSAs?

Essentially, each OSPF node in a non-broadcast link generates one router LSA (LSA Type 1) entry for the interface connected to that medium; if a DR exists, OSPF nodes label the non-broadcast medium as a transit network, and it includes the IP address and cost of the interface, and the DR’s IP address, as you indicated in this example.

Moreover, the IP address of the BDR does not get inserted in router LSAs.

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

If no DR got selected, the router considers the nonbroadcast link as a stub network, and inserts its cost, subnet IP address and subnet mask in its router LSA, as shown in this example.

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

On nonbroadcast/NBMA links, the designated router generates a network LSA (LSA Type 2) in order to represent the medium. A network LSA includes all OSPF neighbors connected to the current nonbroadcast/NBMA network, and the IP address and subnet mask of the DR, which can be used to figure out the IP address of the matching subnet by ANDing them.
Finally, here is an example of a network LSA.

R1# show ip ospf database network

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

                Net Link States (Area 0)

  Routing Bit Set on this LSA in topology Base with MTID 0
  LS age: 623
  Options: (No TOS-capability, DC)
  LS Type: Network Links
  Link State ID: 10.0.0.4 (address of Designated Router)
  Advertising Router: 10.0.4.4
  LS Seq Number: 80000003
  Checksum: 0xAB28
  Length: 40
  Network Mask: /24
        Attached Router: 10.0.4.4
        Attached Router: 10.0.1.1
        Attached Router: 10.0.2.2
        Attached Router: 10.0.3.3

Configuring OSPF Non-Broadcast Network Type on Cisco IOS

To configure the Open Shortest Path First (OSPF) network type to nonbroadcast multiaccess (NBMA), issue the ip ospf network non-broadcast command in interface configuration mode. To return to the default value, use the no form of this command.

The following example sets the OSPF network of R1’s F0/0 interface as a non-broadcast network:

R1(config)# interface fastEthernet 0/0
R1(config-if)# ip ospf network non-broadcast

To verify the OSPF non-broadcast network type, issue the show ip ospf interface command in enable mode, as illustrated in this example.

R1# show ip ospf interface fastEthernet 0/0
FastEthernet0/0 is up, line protocol is up 
  Internet Address 11.0.0.1/24, Area 0 
  Process ID 1, Router ID 10.0.1.1, Network Type NON_BROADCAST, Cost: 1
  Topology-MTID    Cost    Disabled    Shutdown      Topology Name
        0           1         no          no            Base


omitted output

Finally, note that this command is not allowed on loopback interfaces.

OSPF Broadcast vs Non-Broadcast Network Type

When the OSPF non-broadcast network type is selected, OSPF nodes do not use multicast or broadcast packets to detect neighbors and form adjacencies. Instead, OSPF neighbors exchange OSPF packets using unicast packets, and this requires configuring the IP addresses of each OSPF node’s neighbors manually.

When the OSPF broadcast network type is used, OSPF uses multicast to discover neighbors and build neighbor relationships. This means that routers can automatically form and maintain OSPF adjacencies without the need to specify the IP address of each OSPF node on the current link.

Non-broadcast networks can be more difficult to scale, as each router must be manually configured with its neighbors’ IP addresses. Broadcast networks are more scalable, as routers can automatically discover and establish connections with other routers on the network.

There are no issues with the DR/BDR election process on broadcast and full mesh non-broadcast networks. However, on partial mesh NBMA networks, the DR/BDR election may encounter issues leading to inconsistent LSDBs if the routers are not configured conveniently.

Related Lessons to OSPF Non-Broadcast Network Type

Conclusion

I hope this blog post helps you learn something.
Now I’d like to turn it over to you:
What did you like about this tutorial?
Or maybe you have an excellent idea that you think I need to add.
Either way, let me know by leaving a comment below right now.

Mohamed Ouamer
Mohamed Ouamer
Mohamed Ouamer is a computer science teacher and a self-published author. He taught networking technologies and programming for more than fifteen years. While he loves to share knowledge and write, Mohamed's best passions include spending time with his family, visiting his parents, and learning new things.
Linkedin