This network type is used on networks that have no broadcast/multicast capability, such as frame-relay, ATM, SMDS, & X.25. The key point is that these layer 2 protocols are unable to send broadcasts/multicasts. To show how critical this is, please see the diagram below.

– In the top (Ethernet) network, if R1 wanted to send some data to R2, then R1 would send a broadcast ARP with a layer 3 destination of 10.0.0.2 in order to discover the mac address of R2’s Fa0/0 interface. R1 would then forward the data to this MAC address.

– In the second diagram (Frame-Relay) R3 is unable to send that broadcast ARP (like we could in the Ethernet scenario above). MAC addresses are only used on Ethernet networks, whereas Frame-relay uses the concept of DLCI’s at layer 2. So R3’s WAN interface must be statically configured with the layer 2 DLCI that it needs to use in order to reach R4 (commands such as #frame-relay map ip 10.0.0.4 304, or #frame-relay interface-dlci 304 (if using inverse-arp) could be used to achieve that). The point here is that it is not possible to send any layer 2 broadcasts across a frame-relay network.

The OSPF Non-broadcast network deals with this kind type of network by unicasting all types of OSPF packets (eg: Hellos, LSA’s, LSU’s etc), over the frame-relay network instead of multicasting them. Let’s step through an example topology (below). The hub, R1, is going to be the DR, and the other two routers are spokes.

R1#
interface Serial0/0/0
ip address 10.0.0.1 255.255.255.0
encapsulation frame-relay
ip traffic-export apply MyProfile
ip ospf network non-broadcast
ip ospf priority 100
frame-relay map ip 10.0.0.2 102
frame-relay map ip 10.0.0.3 103
no frame-relay inverse-arp
!
router ospf 1
router-id 1.1.1.1
network 10.0.0.0 0.0.0.255 area 0
neighbor 10.0.0.2
neighbor 10.0.0.3

R2#
interface Serial0/0/0
ip address 10.0.0.2 255.255.255.0
encapsulation frame-relay
ip ospf network non-broadcast
ip ospf priority 0
frame-relay map ip 10.0.0.3 201
frame-relay map ip 10.0.0.1 201
no frame-relay inverse-arp
!
router ospf 1
router-id 2.2.2.2
network 10.0.0.0 0.0.0.255 area 0

R3#
interface Serial1/0
ip address 10.0.0.3 255.255.255.0
encapsulation frame-relay
ip ospf network non-broadcast
ip ospf priority 0
frame-relay map ip 10.0.0.1 301
frame-relay map ip 10.0.0.2 301
no frame-relay inverse-arp
!
router ospf 1
router-id 3.3.3.3
network 10.0.0.0 0.0.0.255 area 0
The key thing to remember is that the neighbor command is restricted to the DR & BDR only . If you try and configure a neighbor statement on a DROthers router, the parser will accept the command, but the #sh run output will not display the neighbor statement. The neighbor command allows the router to send hello’s to those specific neighbors. Those messages are sent as unicast messages. The reason the neighbor command is only required on one side between neighbors, is because hello’s are sent if hellos are received. Hello’s are sent every 30 seconds by default on this network type, or upon receiving an hello packet. So therefore, hello’s will be able to be exchanged between the two neighbors.

In the config you will also see I’ve opted to exclude the “broadcast” keyword on the end of the frame-relay map statements (more info on that topic here). The reason being, there is no broadcast/multicast traffic sent by OSPF on this network. I’ll show a packet capture on R1’s s0/0/0 interface, and you will see the OSPF messages are sent as unicast packets as opposed to multicast packets. I’m gonna add a new network into OSPF so that you can see everything is sent as unicast messages.

R3#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#interface Loopback6
R3(config-if)# ip address 6.6.6.6 255.255.255.255
R3(config-if)# ip ospf network point-to-point
R3(config-if)#exit
R3(config)#router ospf 1
R3(config-router)#network 6.6.6.6 0.0.0.0 area 0
Below is the packet capture taken at the same time this configuration was applied.

So as you can see. All IP address in the destination field are unicast for all types of OSPF packets.

One last note about this network type is that it’s typical in a full mesh/partial mesh design. If we wanted to provide connectivity between R2 and R3 directly, we would simply just change the frame-relay map statements to the statements shown below:

R3#
interface Serial1/0
no frame-relay map ip 10.0.0.2 301
frame-relay map ip 10.0.0.2 302
R2#
interface Serial1/0
no frame-relay map ip 10.0.0.3 201
frame-relay map ip 10.0.0.3 203
This won’t actually cause R2 and R3 to become OSPF neighbors, however, it will allow traffic to go directly between them rather than via R1. It’s important to remember that only the DR/BDR are able to create OSPF neighbors and adjacencies to the other routers. So it’s not possible to create the OSPF adjacency between R2 & R3 unless we remove the #ip ospf priority command and configure a priority greater than 0 on one of them. This will allow one of the routers to be elected BDR, and thus allow the adjacency to be formed.

What I mean by adjacency and neighbor by the way, is that in this network type, all the DROthers will create a DR/FULL relationship in the #sh ip ospf neighbor output. Whereas a DROther to DROther will stay at 2-way. The reason why is because with OSPF, there is an assumption made that if you can reach the DR, then this implies you can also reach any of the DROthers. The idea is that you no longer need to create P2P relationships with every single DROther router, thus significantly reducing the number of OSPF neighbor adjacencies that are required. Instead the DR creates just one type 2 LSA that represents that entire part of the network.

Quick Facts

– All OSPF packets are sent unicast to each neighbor

– Default timers are Hello 30 secs, Dead 120 secs

– DR/BDR election occurs.

– DR/BDR must be connected to all other routers

– Neighbor statements must be manually configured on the DR/BDR routers

– Typical in a full mesh network, although it can be used in a hub and spoke design (as provided in my example)