Hands-On Lab: Configuring OSPF on Broadcast Networks

This hands-on lab configures OSPF across an Ethernet segment with three routers, observing DR and BDR election in action and verifying how it differs fundamentally from the point-to-point behavior covered in the previous lab.

OSPF Broadcast Network TypeDR and BDR ElectionOSPF Priority

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

Lab Objective

Configure OSPF on an Ethernet segment shared by three routers, observe the DR and BDR election process, manually influence the outcome using OSPF priority, and verify the resulting neighbor states.

Lab Purpose

Unlike the point-to-point network type covered in the previous lab, a broadcast network type (the default on Ethernet interfaces) requires electing a Designated Router and Backup Designated Router to reduce the number of adjacencies needed among multiple routers sharing the same segment.

Lab Topology

R1, R2, R3 all connected to the same
Ethernet segment via Switch1

R1: 192.168.100.1/24
R2: 192.168.100.2/24
R3: 192.168.100.3/24

Task 1: Configure Basic Addressing

Configure all three routers' Ethernet interfaces on the shared segment.

Task 2: Enable OSPF on All Three Routers

Enable OSPF process 1 on all three routers, advertising the shared network into area 0.

Task 3: Verify the Network Type

Confirm the interface is recognized as a broadcast OSPF network type.

Task 4: Observe the Default DR/BDR Election

Identify which router became DR and which became BDR by default, based on Router ID.

Task 5: Influence the Election Using Priority

Set R3's OSPF priority higher than the others, then reset OSPF processes and observe whether R3 becomes the new DR.

Solution and Verification

R1(config)# interface gigabitethernet0/0
R1(config-if)# ip address 192.168.100.1 255.255.255.0
R1(config-if)# no shutdown

R2(config)# interface gigabitethernet0/0
R2(config-if)# ip address 192.168.100.2 255.255.255.0
R2(config-if)# no shutdown

R3(config)# interface gigabitethernet0/0
R3(config-if)# ip address 192.168.100.3 255.255.255.0
R3(config-if)# no shutdown

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

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

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

R1# show ip ospf interface gigabitethernet0/0

GigabitEthernet0/0 is up, line protocol is up
  Internet Address 192.168.100.1/24, Area 0
  Network Type BROADCAST, Cost: 1

R1# show ip ospf neighbor

Neighbor ID     Pri   State           Address         Interface
192.168.100.2   1     FULL/BDR        192.168.100.2   GigabitEthernet0/0
192.168.100.3   1     FULL/DR         192.168.100.3   GigabitEthernet0/0

-- By default, the router with the HIGHEST
-- Router ID wins DR election (here, R3 at
-- 192.168.100.3), with the next-highest
-- becoming BDR (R2) -- R1 sees itself as
-- neither, shown as DROTHER in its own status

-- Attempting priority to force R1 as DR
-- instead, for demonstration:
R1(config)# interface gigabitethernet0/0
R1(config-if)# ip ospf priority 200

R1(config-if)# shutdown
R1(config-if)# no shutdown

R1# show ip ospf neighbor

-- R1's priority change does NOT retroactively
-- displace the existing DR/BDR -- DR/BDR
-- election is non-preemptive, so R3 remains
-- DR even with R1's higher priority, until
-- R3 itself goes down and a genuinely new
-- election occurs

Key Takeaway

OSPF's DR/BDR election is deliberately non-preemptive: once a DR is elected, a newly configured higher-priority router does not automatically take over, even after resetting its own OSPF process — the existing DR only changes if it actually goes down, which is precisely why priority should be configured before a router first joins the segment rather than after a DR is already established.

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

مقالات مرتبط

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.

ادامه