A 911 PSAP wants a stable OSPFv2 identity on clinic WAN routers so neighbor relationships do not churn when interfaces flap. What should they configure?
Select an answer to reveal the explanation.
Short Explanation
Think of the router ID as the name on the radio — you want one clear callsign, not a new nickname every time a cable wiggles. Pin a unique RID, often on a loopback.
Full Explanation
OSPFv2 router ID uniquely identifies a 911 PSAP router in the clinic WAN topology and in Type-1 router LSAs. If the RID is derived automatically from the highest up IPv4 interface address, a WAN or LAN flap that changes which address is best can force RID changes, confusing neighbor relationships, LSA identity, and troubleshooting during incidents when stability matters most. Configuring an explicit OSPFv2 router ID—commonly matching a stable loopback address—keeps identity unique and persistent across interface state changes while remaining under administrative control for every PSAP and clinic edge.
Relying only on the highest up interface IP invites renumbering whenever links change and is a classic source of OSPF “mystery” neighbor resets. Duplicating the same router ID on every PSAP router causes conflicts and breaks reliable OSPF operation because the domain cannot distinguish devices. Clearing the OSPF process hourly to refresh a random RID adds instability rather than preventing churn and is never an acceptable operational practice.
Exam caveat: after manually setting a router ID, an OSPF process restart (or carefully planned reload) may be required before the new RID becomes active—know that operational detail for lab and production. Operational check: set unique RIDs on each PSAP router, preferably tied to loopbacks that stay up, bounce a WAN interface, and confirm show ip ospf still reports the same RID with neighbor relationships that do not churn solely due to identity changes.