Hands-On Lab: Configuring OSPF Point-to-Multipoint Networks

This hands-on lab configures OSPF using the point-to-multipoint network type on a hub-and-spoke topology, comparing this approach against the manual neighbor statements required for non-broadcast networks in the previous lab.

OSPF Point-to-MultipointAutomatic Neighbor DiscoveryHub-and-Spoke OSPF

~3 دقیقه مطالعه · آخرین به‌روزرسانی ۳۱ شهریور ۱۴۰۵

Lab Objective

Configure OSPF using the point-to-multipoint network type on a hub-and-spoke topology, verify neighbors are discovered automatically without manual neighbor statements, and confirm no DR/BDR election occurs.

Lab Purpose

The non-broadcast network type covered in the previous lab requires manually configuring every neighbor relationship and still elects a DR/BDR. Point-to-multipoint offers an alternative specifically suited to hub-and-spoke topologies: it treats the network as a collection of point-to-point links, restoring automatic neighbor discovery while still supporting multiple spokes on a shared subnet.

Lab Topology

Hub-and-spoke topology (same physical layout
as the non-broadcast lab):

R1 (hub): 172.21.100.1/24
R2 (spoke): 172.21.100.2/24
R3 (spoke): 172.21.100.3/24

R2 and R3 still have no direct connectivity
to each other, only to R1

Task 1: Configure Basic Addressing

Configure all three routers with their addresses on the shared subnet.

Task 2: Enable OSPF and Set the Network Type

Enable OSPF on all three routers, setting the interface network type to point-to-multipoint rather than non-broadcast.

Task 3: Verify Automatic Neighbor Discovery

Confirm neighbors form automatically without any neighbor command being configured.

Task 4: Verify No DR/BDR Election Occurs

Confirm the neighbor table shows no DR or BDR role, unlike the non-broadcast configuration in the previous lab.

Solution and Verification

R1(config)# interface serial0/0/0
R1(config-if)# ip address 172.21.100.1 255.255.255.0
R1(config-if)# ip ospf network point-to-multipoint
R1(config-if)# no shutdown

R2(config)# interface serial0/0/0
R2(config-if)# ip address 172.21.100.2 255.255.255.0
R2(config-if)# ip ospf network point-to-multipoint
R2(config-if)# no shutdown

R3(config)# interface serial0/0/0
R3(config-if)# ip address 172.21.100.3 255.255.255.0
R3(config-if)# ip ospf network point-to-multipoint
R3(config-if)# no shutdown

R1(config)# router ospf 1
R1(config-router)# network 172.21.100.0 0.0.0.255 area 0

R2(config)# router ospf 1
R2(config-router)# network 172.21.100.0 0.0.0.255 area 0

R3(config)# router ospf 1
R3(config-router)# network 172.21.100.0 0.0.0.255 area 0

-- No neighbor commands configured anywhere,
-- unlike the non-broadcast lab

R1# show ip ospf neighbor

Neighbor ID     Pri   State           Address
172.21.100.2     1     FULL/  -        172.21.100.2
172.21.100.3     1     FULL/  -        172.21.100.3
-- Neighbors formed automatically with no
-- manual neighbor statements required, and
-- the "-" in place of DR/BDR confirms no
-- election occurred at all -- point-to-multipoint
-- treats this shared subnet as a set of
-- individual point-to-point relationships

Key Takeaway

Point-to-multipoint combines the best of both previous network types: it restores automatic neighbor discovery, avoiding the manual neighbor statements non-broadcast requires, while also skipping DR/BDR election entirely, treating each spoke relationship as its own independent point-to-point adjacency — making it frequently the preferred choice for hub-and-spoke topologies over plain non-broadcast configuration.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه