An airport authority clones a router template and later sees odd OSPF adjacency and LSA behavior across civic edge devices. Which requirement was most likely violated?
Select an answer to reveal the explanation.
Short Explanation
Cloning boxes without changing the OSPF router ID is like giving two planes the same tail number—databases and neighbor relationships get confused fast. Make every RID unique.
Full Explanation
When an airport authority clones a router template and later sees odd OSPF adjacency and LSA behavior across civic edge devices, the most likely violated requirement is that each OSPF router must have a unique router ID within the OSPF domain. Duplicate RIDs confuse neighbor identification, DBD exchange, and LSA origination because OSPF uses the RID as a critical identity in the LSDB. Template clones that copy loopbacks or explicit router-id commands without uniquifying them are a classic operational failure mode—hence the correct diagnosis. Requiring every OSPF process ID to match the BGP ASN is false; process IDs are locally significant and unrelated to BGP AS numbers. Forcing all routers to share one router ID so DR election becomes deterministic is the opposite of correct practice and causes the very instability observed. Setting hello intervals to zero when router IDs collide is invalid and does not remediate RID duplication. Exam caveat: RID selection often follows highest loopback or explicit router-id; cloning images without a per-device RID plan is an ENARSI-relevant ops footgun. Operational check: inventory show ip ospf on every edge device for RID uniqueness; correct duplicates with a documented RID scheme (often loopback-based); clear OSPF processes in a controlled window and verify stable Full adjacencies and coherent LSA advertising router fields.