Hands-On Lab: Configuring OSPF on Non-Broadcast Networks

This hands-on lab configures OSPF over a non-broadcast multi-access topology using manually specified neighbor statements, since this network type cannot rely on multicast hello packets to automatically discover neighbors.

OSPF Non-Broadcast Network TypeManual Neighbor StatementNBMA Configuration

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

Lab Objective

Configure OSPF across a non-broadcast multi-access (NBMA) topology using the neighbor command to manually define adjacencies, since automatic multicast-based discovery does not function on this network type.

Lab Purpose

Unlike the broadcast network type covered in an earlier lab, NBMA networks (historically Frame Relay, still relevant conceptually for hub-and-spoke topologies) cannot rely on OSPF's normal multicast hello mechanism to discover neighbors automatically, requiring administrators to manually specify who the neighbors are.

Lab Topology

Hub-and-spoke NBMA topology:

R1 (hub): 172.20.100.1/24
R2 (spoke): 172.20.100.2/24
R3 (spoke): 172.20.100.3/24

All three share the same logical subnet but
R2 and R3 have no direct connectivity to each
other, only to R1 (a defining NBMA characteristic)

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, explicitly setting the interface network type to non-broadcast.

Task 3: Manually Define Neighbors on the Hub

On R1, manually specify both R2 and R3 as OSPF neighbors.

Task 4: Manually Define the Neighbor on Each Spoke

On R2 and R3, manually specify R1 as their OSPF neighbor.

Task 5: Verify Adjacencies Form Correctly

Confirm R1 forms adjacencies with both spokes, and that R2 and R3 correctly point only toward R1.

Solution and Verification

R1(config)# interface serial0/0/0
R1(config-if)# ip address 172.20.100.1 255.255.255.0
R1(config-if)# ip ospf network non-broadcast
R1(config-if)# no shutdown

R2(config)# interface serial0/0/0
R2(config-if)# ip address 172.20.100.2 255.255.255.0
R2(config-if)# ip ospf network non-broadcast
R2(config-if)# no shutdown

R3(config)# interface serial0/0/0
R3(config-if)# ip address 172.20.100.3 255.255.255.0
R3(config-if)# ip ospf network non-broadcast
R3(config-if)# no shutdown

R1(config)# router ospf 1
R1(config-router)# network 172.20.100.0 0.0.0.255 area 0
R1(config-router)# neighbor 172.20.100.2
R1(config-router)# neighbor 172.20.100.3

-- Since non-broadcast networks still elect a
-- DR/BDR like broadcast networks, but cannot
-- discover neighbors via multicast, R1's
-- higher priority makes it the natural DR
-- choice for this hub-and-spoke design

R2(config)# router ospf 1
R2(config-router)# network 172.20.100.0 0.0.0.255 area 0
R2(config-router)# neighbor 172.20.100.1

R3(config)# router ospf 1
R3(config-router)# network 172.20.100.0 0.0.0.255 area 0
R3(config-router)# neighbor 172.20.100.1

R1# show ip ospf neighbor

Neighbor ID     Pri   State           Address
172.20.100.2     1     FULL/DROTHER    172.20.100.2
172.20.100.3     1     FULL/DROTHER    172.20.100.3
-- R1 correctly sees both spokes as full
-- neighbors, despite R2 and R3 having no
-- direct connectivity to each other

Key Takeaway

The neighbor command exists specifically because NBMA networks cannot use multicast hello discovery — without it, no adjacency would ever form regardless of how correctly everything else is configured, since OSPF simply has no other way to learn who its potential neighbors are on this network type.

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

مقالات مرتبط

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.

ادامه