Hands-On Lab: Configuring the OSPF Router ID Manually

This hands-on lab manually sets a router's OSPF Router ID rather than relying on automatic selection from interface addresses, and verifies the change requires an OSPF process restart to take effect.

OSPF Router IDManual Router ID ConfigurationOSPF Process Reset

~3 min read · Updated Sep 22, 2026

Lab Objective

Observe a router's automatically selected OSPF Router ID, manually configure a specific Router ID instead, and verify the change requires the OSPF process to be cleared before taking effect.

Lab Purpose

By default, OSPF selects its Router ID from the highest active loopback address, or if none exists, the highest active physical interface address at process startup. Relying on this automatic selection can produce unpredictable Router IDs as interfaces are added or removed over time, making manual configuration a common best practice for stability and readability.

Lab Topology

R1 with interfaces:
  GigabitEthernet0/0: 192.168.1.1/24
  Loopback0: 172.16.1.1/32

OSPF process 1 already running

Task 1: Identify the Current Automatic Router ID

Determine what Router ID OSPF has automatically selected for R1.

Task 2: Manually Configure a Router ID

Set R1's OSPF Router ID explicitly to 1.1.1.1, a value with no relationship to any of its actual interface addresses.

Task 3: Verify the Configuration Does Not Yet Take Effect

Check the Router ID again immediately and confirm it has not changed, despite the new configuration being accepted.

Task 4: Clear the OSPF Process

Clear the OSPF process to force it to restart and apply the new Router ID.

Task 5: Verify the New Router ID Is Active

Confirm the manually configured Router ID is now in effect.

Solution and Verification

R1# show ip ospf | include Router ID

Routing Process "ospf 1" with ID 172.16.1.1
-- Automatically selected from the loopback
-- address, since a loopback is preferred
-- over a physical interface when present

R1(config)# router ospf 1
R1(config-router)# router-id 1.1.1.1

Reload or use "clear ip ospf process" command
for this to take effect

R1# show ip ospf | include Router ID

Routing Process "ospf 1" with ID 172.16.1.1
-- Unchanged -- the IOS warning shown above
-- was not just a formality; the new Router
-- ID genuinely has not taken effect yet

R1# clear ip ospf process

Reset ALL OSPF processes? [no]: yes

R1# show ip ospf | include Router ID

Routing Process "ospf 1" with ID 1.1.1.1
-- The manually configured Router ID is
-- now active

Key Takeaway

Changing the Router ID with the router-id command never takes effect immediately — it requires either a full reload or a clear ip ospf process to restart the OSPF process, which also temporarily tears down and rebuilds every neighbor adjacency on that router, a disruption worth planning for during a maintenance window rather than assuming the change applies instantly and harmlessly.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring Standard Numbered ACLs

This hands-on lab configures a standard numbered ACL to permit traffic from a specific subnet while denying everything else, applies it to the correct interface and direction, and verifies both permitted and denied traffic behave as expected.

Continue

Hands-On Lab: Configuring VRRP

This hands-on lab configures VRRP between two routers as the open-standard alternative to HSRP, using a real interface address as the virtual IP, and verifies Master/Backup roles and automatic failover behavior.

Continue

Hands-On Lab: Configure GLBP Redundancy

This hands-on lab configures GLBP between two routers to achieve load balancing across both routers simultaneously, verifying that different hosts receive different virtual MAC addresses and therefore route through different physical gateways.

Continue

Hands-On Lab: Implementing HSRP

This hands-on lab configures HSRP between two routers sharing a virtual gateway address, sets priority and preempt to control which router is active, and verifies automatic failover when the active router fails.

Continue

Hands-On Lab: Verifying the EIGRP Database

This hands-on lab examines the EIGRP topology table directly, identifying the successor and feasible successor for a destination network, and demonstrates how this underlying data explains what appears in the IP routing table.

Continue

Hands-On Lab: Summarizing Routes with EIGRP

This hands-on lab manually configures interface-level route summarization in EIGRP, advertising a single aggregated route instead of several specific subnets, and verifies the automatically created Null0 discard route that prevents summarization-related loops.

Continue