Lab Objective
Configure OSPF on the same DMVPN hub-and-spoke topology used in the previous EIGRP lab, explicitly setting the tunnel interface's OSPF network type to point-to-multipoint, and verify neighbor relationships form correctly and routes propagate without the complications a mismatched network type would introduce.
Lab Purpose
OSPF's default network type on a multipoint GRE tunnel interface is non-broadcast, discussed earlier in this series, which requires manual neighbor statements — impractical on a DMVPN cloud where spokes register and de-register dynamically via NHRP. Point-to-multipoint, also covered earlier in this series, restores automatic neighbor discovery and avoids DR/BDR election entirely, making it the standard choice for OSPF over DMVPN.
Lab Topology
Same DMVPN topology as the previous EIGRP
lab, with EIGRP removed and OSPF configured
instead:
Hub ---- Tunnel0 (mGRE): 172.16.200.1/24
Spoke1 ---- Tunnel0: 172.16.200.2/24
Spoke2 ---- Tunnel0: 172.16.200.3/24Task 1: Remove the Previous EIGRP Configuration
Remove EIGRP from all three routers, as the topology transitions to OSPF for this lab.
Task 2: Configure the Tunnel Interface's OSPF Network Type
Set the tunnel interface to point-to-multipoint network type on the hub and both spokes.
Task 3: Enable OSPF on the Tunnel and LAN Interfaces
Enable OSPF area 0 on the hub, both spokes, including their respective LANs.
Task 4: Verify Neighbor Relationships Form Without DR/BDR Election
Confirm the hub forms neighbor relationships with both spokes, with no DR or BDR role assigned to either.
Task 5: Verify Routes Propagate Correctly
Confirm each spoke's LAN is learned by the hub and by the other spoke.
Solution and Verification
Hub(config)# no router eigrp 100
Spoke1(config)# no router eigrp 100
Spoke2(config)# no router eigrp 100Hub(config)# interface tunnel0
Hub(config-if)# ip ospf network point-to-multipoint
Spoke1(config)# interface tunnel0
Spoke1(config-if)# ip ospf network point-to-multipoint
Spoke2(config)# interface tunnel0
Spoke2(config-if)# ip ospf network point-to-multipoint
-- Setting this explicitly is essential --
-- leaving the tunnel at its default
-- non-broadcast network type would require
-- manual neighbor statements for every
-- spoke, defeating the purpose of DMVPN's
-- dynamic spoke registration entirelyHub(config)# router ospf 1
Hub(config-router)# network 172.16.200.0 0.0.0.255 area 0
Hub(config-router)# network 192.168.10.0 0.0.0.255 area 0
Spoke1(config)# router ospf 1
Spoke1(config-router)# network 172.16.200.0 0.0.0.255 area 0
Spoke1(config-router)# network 192.168.11.0 0.0.0.255 area 0
Spoke2(config)# router ospf 1
Spoke2(config-router)# network 172.16.200.0 0.0.0.255 area 0
Spoke2(config-router)# network 192.168.12.0 0.0.0.255 area 0Hub# show ip ospf neighbor
Neighbor ID Pri State Dead Time Interface
2.2.2.2 0 FULL/ - 00:01:45 Tunnel0
3.3.3.3 0 FULL/ - 00:01:52 Tunnel0
-- Both spokes formed neighbor relationships
-- automatically -- the "-" in place of a
-- DR/BDR role confirms point-to-multipoint
-- correctly skipped that election entirely,
-- treating each spoke relationship as its
-- own point-to-point adjacencyHub# show ip route ospf
O 192.168.11.0/24 [110/1001] via 172.16.200.2, Tunnel0
O 192.168.12.0/24 [110/1001] via 172.16.200.3, Tunnel0
-- Both spoke LANs learned dynamically via
-- OSPF, requiring no manual neighbor
-- configuration anywhere in the topologySpoke1# show ip route ospf
O 192.168.10.0/24 [110/1001] via 172.16.200.1, Tunnel0
O 192.168.12.0/24 [110/1002] via 172.16.200.1, Tunnel0
-- Spoke1 learned both the hub's LAN and
-- Spoke2's LAN, the latter routed via the
-- hub since basic OSPF over DMVPN, like
-- basic EIGRP over DMVPN in the previous
-- lab, does not build direct spoke-to-spoke
-- shortcuts on its ownKey Takeaway
Point-to-multipoint is the network type specifically suited to DMVPN's dynamic hub-and-spoke registration model, discussed conceptually in an earlier lab covering OSPF network types — it avoids both the manual neighbor statements non-broadcast would require and the unnecessary DR/BDR election broadcast mode would introduce, making it the standard, near-universal choice for running OSPF over an mGRE-based DMVPN tunnel regardless of how many spokes dynamically join or leave the cloud over time.