Skip to content
Log in Sign up My account

1.10.c Network Types and DR/BDR

Blueprint 1.10.c (i): Troubleshoot OSPF (v2/v3): Network types: point-to-point, multipoint, broadcast, nonbroadcast

  • The five OSPF network types (plus loopback), their defaults, timers and neighbor discovery
  • Which network types are compatible on the two ends of a link, and what a mismatch looks like
  • DR and BDR election, priority and the non-preemptive rule
  • Hub-and-spoke designs where the hub must be the DR
  • How the network type changes what is advertised (host routes, loopbacks, next hops)

The network type decides three things: whether a DR is elected, which hello and dead timers are used, and whether neighbors are discovered by multicast or configured by hand. A mismatch on any of these breaks the adjacency or, worse, lets the adjacency come up while routes silently fail to install. That second case is a favourite exam scenario because show ip ospf neighbor looks perfect.

The network types

Network type IOS keyword Default on DR/BDR Hello / dead Neighbor discovery
Broadcast broadcast Ethernet Yes 10 / 40 Automatic, multicast 224.0.0.5
Non-broadcast (NBMA) non-broadcast Frame Relay physical and multipoint interfaces (legacy) Yes 30 / 120 Manual: neighbor statements, unicast hellos
Point-to-point point-to-point Serial HDLC/PPP, GRE tunnels, point-to-point subinterfaces No 10 / 40 Automatic, multicast
Point-to-multipoint point-to-multipoint Never a default No 30 / 120 Automatic, multicast
Point-to-multipoint non-broadcast point-to-multipoint non-broadcast Never a default No 30 / 120 Manual: neighbor statements
Loopback (not configurable as such) Loopback interfaces No None No neighbors

Change the type per interface with ip ospf network <type> (OSPFv2) or ospfv3 network <type> (OSPFv3). Timers follow the type automatically unless you set ip ospf hello-interval or ip ospf dead-interval explicitly. If you set only the hello interval, IOS sets the dead interval to four times the hello.

The wait timer, shown as Wait 40 in show ip ospf interface, equals the dead interval. On a DR-capable network a router waits this long after the interface comes up before it takes part in the election, so it can learn of an existing DR first.

What each type advertises

Type What appears in the router's Type 1 LSA for the link Effect in neighbors' routing tables
Broadcast, non-broadcast A transit link to the DR; the subnet itself is described by the DR's Type 2 LSA One route for the subnet
Point-to-point A point-to-point link to the neighbor and a stub link for the subnet One route for the subnet
Point-to-multipoint A point-to-point link per neighbor and a /32 stub link for its own interface address A /32 host route for every router's interface on the segment, next hop is the advertising router
Loopback A /32 stub link, whatever mask is configured A /32 route, unless the loopback is set to point-to-point 
R3# show ip ospf interface Loopback30
Loopback30 is up, line protocol is up
  Internet Address 10.3.30.1/24, Area 0, Attached via Network Statement
  Process ID 1, Router ID 10.255.255.3, Network Type LOOPBACK, Cost: 1
  Loopback interface is treated as a stub Host

Exam trap

A loopback configured as /24 shows up on every other router as a /32. That is the default LOOPBACK network type, not a fault in summarization or redistribution. Use ip ospf network point-to-point on the loopback when a lab or ticket requires the real mask to be advertised.

Compatibility between the two ends

Two broad families exist: types that elect a DR (broadcast, non-broadcast) and types that do not (point-to-point, point-to-multipoint and its non-broadcast variant).

graph LR
  subgraph DRF ["DR family"]
    B["Broadcast 10/40"]
    NB["Non-broadcast 30/120"]
  end
  subgraph NDF ["No-DR family"]
    P["Point-to-point 10/40"]
    PM["Point-to-multipoint 30/120"]
  end
  B ---|"works if timers matched"| NB
  P ---|"works if timers matched"| PM
  B -.-|"FULL but routes missing"| P
  NB -.-|"FULL but routes missing"| PM
End A End B Default outcome With timers matched
Broadcast Broadcast Works Works
Broadcast Non-broadcast No neighbor (10/40 vs 30/120) Works; DR elected
Point-to-point Point-to-multipoint No neighbor (10/40 vs 30/120) Works; no DR
Broadcast Point-to-point Same timers, so the adjacency can reach FULL Routes over the link are missing
Non-broadcast or broadcast Point-to-multipoint No neighbor FULL but routes missing

Why routes go missing when one side expects a DR and the other does not: the broadcast side describes the link in its Type 1 LSA as a transit link to a DR, and the point-to-point side describes it as a point-to-point link to a router. During SPF, each link must be confirmed from both ends (the two-way check). The descriptions do not agree, so SPF cannot use the link and prefixes reached through it are left out of the routing table.

R1# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
10.255.255.4      0   FULL/  -        00:00:36    10.1.4.4        GigabitEthernet0/2

R1# show ip route 10.4.40.0
% Subnet not in table

R1# show ip ospf interface brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Gi0/2        1     0               10.1.4.1/30        1     P2P   1/1
R4# show ip ospf interface brief
Interface    PID   Area            IP Address/Mask    Cost  State Nbrs F/C
Gi0/0        1     0               10.1.4.4/30        1     DR    1/1

The neighbor is FULL, but R1 reports P2P while R4 reports DR. That pairing is the giveaway.

Exam trap

When an exhibit shows a FULL adjacency and a missing route, compare the State column of show ip ospf interface brief on both ends before you look at filtering. P2P on one side and DR, BDR or DROTH on the other is a network type mismatch.

DR and BDR election

On broadcast and non-broadcast segments, every router forms a FULL adjacency only with the DR and BDR, which cuts the number of adjacencies and LSA floods. DROTHERs send LSUs to 224.0.0.6 (FF02::6 for OSPFv3), the DR and BDR listen, and the DR refloods to 224.0.0.5 (FF02::5).

Election rules:

  1. The highest interface priority wins. The range is 0 to 255 and the default is 1. Priority 0 means the router never becomes DR or BDR.
  2. A tie is broken by the highest router ID.
  3. The election is not preemptive. A router with a better priority that joins later does not take over. It waits until the DR fails (then the BDR is promoted and a new BDR is elected) or until the OSPF processes are restarted.
  4. If every router on the segment has priority 0, there is no DR. Every neighbor stays in 2WAY/DROTHER and no adjacency reaches FULL.
R1# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
10.255.255.2      1   FULL/BDR        00:00:37    10.0.123.2      GigabitEthernet0/0
10.255.255.3    100   FULL/DR         00:00:34    10.0.123.3      GigabitEthernet0/0
10.255.255.5      0   2WAY/DROTHER    00:00:31    10.0.123.5      GigabitEthernet0/0

From R1's point of view (itself a DROTHER), the DR and BDR are FULL and the other DROTHER stays in 2WAY. That is healthy. To force a specific router to be DR, raise its priority and lower or zero the others, then reset the process with clear ip ospf process on the current DR and BDR if you need the change to happen now. Clearing only the DR just promotes the BDR, and the new router becomes BDR.

graph TB
  SW["Switch, 10.0.123.0/24, Area 0"]
  R1["R1 pri 1, DROTHER"] --- SW
  R2["R2 pri 1, BDR"] --- SW
  R3["R3 pri 100, DR"] --- SW
  R5["R5 pri 0, DROTHER"] --- SW

Hub-and-spoke on a multiaccess network

On an NBMA cloud (or a DMVPN hub-and-spoke that uses the broadcast type), spokes can reach only the hub. If a spoke becomes DR, other spokes cannot reach it, LSAs are not flooded and routes go missing. The hub must be the DR and there must be no BDR on the spokes:

! Hub: non-broadcast with neighbor statements
interface Serial0/0
 ip address 10.9.0.1 255.255.255.0
 ip ospf network non-broadcast
 ip ospf priority 255
router ospf 1
 neighbor 10.9.0.2
 neighbor 10.9.0.3
!
! Each spoke
interface Serial0/0
 ip address 10.9.0.2 255.255.255.0
 ip ospf network non-broadcast
 ip ospf priority 0

The neighbor statements are required for the non-broadcast type because nothing is multicast. They are needed on the router that will send the first hellos (the hub). Spokes reply with unicast hellos to the hub once they hear from it. A router waiting for a configured neighbor shows it in the ATTEMPT state.

Point-to-multipoint avoids the DR problem entirely. Every spoke forms an adjacency with the hub, the hub advertises /32 host routes for each spoke's interface, and routes from one spoke to another point to the hub as next hop. That is why it suits partial-mesh designs. The price is the 30/120 timers, which must match on all routers, and the extra /32 routes.

Exam trap

The neighbor router command is only meaningful for non-broadcast and point-to-multipoint non-broadcast. Configuring neighbor statements on a broadcast or point-to-point Ethernet link does nothing useful. If an exhibit shows neighbor commands but the interface type is broadcast, the statements are not the fault, so look for something else.

Point-to-point on Ethernet

Many networks set ip ospf network point-to-point on router-to-router Ethernet links. The benefits are no DR election, no wait timer at startup (faster convergence) and no Type 2 LSA for the link. The catch is that point-to-point supports one neighbor. If a third router appears on that VLAN, the adjacency becomes unstable. Use point-to-point only on links that really connect two routers, and make sure both ends agree.

OSPFv3 notes

The same network types and rules apply to OSPFv3. Commands use the ospfv3 prefix (ospfv3 network point-to-point, ospfv3 priority 0, ospfv3 hello-interval 5), and show ospfv3 interface reports the type and state. OSPFv3 neighbors are always known by router ID, and the DR is shown by router ID in show ospfv3 interface. For the non-broadcast type, OSPFv3 neighbor commands are entered under the interface with the neighbor's link-local address (ipv6 ospf neighbor FE80::2 in the legacy style).

Lab: network type break/fix

Topology: R1, R2 and R3 share VLAN 123 (10.0.123.0/24) in area 0 with R3 intended as DR. R1 also has a point-to-point Ethernet link to R4 (10.1.4.0/30). R4 advertises Loopback40 (10.4.40.1/24) and must appear on R2 as a /24.

graph LR
  SW["VLAN 123<br/>10.0.123.0/24"]
  R1["R1<br/>.1"] -- "Gi0/0" --- SW
  R2["R2<br/>.2"] -- "Gi0/0" --- SW
  R3["R3 DR<br/>.3"] -- "Gi0/0" --- SW
  R1 -- "Gi0/2 10.1.4.0/30 P2P" --- R4["R4<br/>Lo40 10.4.40.1/24"]

Baseline

! R3
interface GigabitEthernet0/0
 ip address 10.0.123.3 255.255.255.0
 ip ospf priority 100
 ip ospf 1 area 0
!
! R1
interface GigabitEthernet0/0
 ip address 10.0.123.1 255.255.255.0
 ip ospf 1 area 0
interface GigabitEthernet0/2
 ip address 10.1.4.1 255.255.255.252
 ip ospf network point-to-point
 ip ospf 1 area 0
!
! R4
interface Loopback40
 ip address 10.4.40.1 255.255.255.0
 ip ospf network point-to-point
 ip ospf 1 area 0
interface GigabitEthernet0/0
 ip address 10.1.4.4 255.255.255.252
 ip ospf network point-to-point
 ip ospf 1 area 0

Verify: show ip ospf neighbor on R2 shows R3 as FULL/DR and R1 as FULL/BDR or FULL/DROTHER; show ip route 10.4.40.0 on R2 returns an O route with mask /24.

Tickets

  1. R4's LAN appears as a /32. Fault: R4 Loopback40 no ip ospf network point-to-point. Proof: show ip ospf interface Lo40 says Network Type LOOPBACK. Fix: restore the command.
  2. FULL but R4's routes are gone. Fault: R4 Gi0/0 no ip ospf network point-to-point. Proof: brief output shows P2P on R1 and DR on R4. Fix: match the type on both ends.
  3. R3 is not DR after a reload of R3. Fault: reload R3 only. Proof: R1 or R2 is now DR even though R3 has priority 100. Explanation: non-preemptive election. Fix: clear ip ospf process on both the current DR and BDR so that R3 wins the new election (in production, schedule it).
  4. Nobody is FULL on VLAN 123. Fault: ip ospf priority 0 on R1, R2 and R3. Proof: every neighbor is 2WAY/DROTHER. Fix: give at least R3 a non-zero priority.
  5. R2 drops off VLAN 123. Fault: R2 Gi0/0 ip ospf network point-to-multipoint. Proof: show ip ospf interface Gi0/0 shows Hello 30, Dead 120, and the debug shows mismatched hello parameters. Fix: return to broadcast.
  6. Stretch ticket. On R1 and R4, set ip ospf network non-broadcast on the R1 to R4 link with no neighbor statements. Observe that nothing forms. Add neighbor 10.1.4.4 under R1's process and watch R4 move through ATTEMPT (on R1) to FULL. Remove it all afterwards.

Quick check

Which two network types elect a DR, and what are their default hello timers?

Broadcast (10 seconds hello, 40 dead) and non-broadcast (30 seconds hello, 120 dead). Point-to-point and both point-to-multipoint types do not elect a DR.

R1 is point-to-point and R2 is broadcast on the same Ethernet link. Timers are default. What do you expect?

Both types use 10/40, so the adjacency can reach FULL. Routes learned across that link do not install, because the two routers describe the link differently in their Type 1 LSAs and SPF fails the two-way check.

A router with priority 200 is added to a segment that already has a DR with priority 1. What happens?

Nothing changes. The DR election is not preemptive. The new router becomes DROTHER (or BDR if there was no BDR) and only takes over after the DR and BDR fail or the process is reset.

References