OSPF Area Design and a Duplicate Router ID
Your campus runs OSPF with three areas. Area 0 contains core routers R1 and R2. Area 1 is a stub area containing distribution routers R3 and R4. Area 2 contains access routers R5 and R6, hangs off R4, and has no physical link to area 0. The design team wants area 2 to have two paths to the backbone and proposes a virtual link between R3 (ABR for areas 0 and 1) and R4 (ABR for areas 1 and 2) across area 1. Separately, two new distribution switches, R7 and R8, were built from a common template and placed on the same VLAN in area 0. Their adjacencies to the core reset roughly every 40 seconds. show log messages records 'OSPF: Duplicate Router ID 10.0.0.1' immediately before each reset, and both switches have router-id 10.0.0.1 configured with no loopback addresses yet. The core is stable; only R7 and R8 flap.
1. The virtual-link proposal is rejected at design review. Explain why it cannot work as drawn, and give two alternatives that keep area 2 connected to the backbone.
Read the worked answer
A virtual link is a backbone extension: the two endpoints form an adjacency as if they were both in area 0, and the link's LSAs are carried across a transit area. That requires the transit area to pass backbone reachability information, including Type 4 summary LSAs that tell routers how to reach an ASBR. A stub area filters those LSAs and does not carry external or ASBR-summary information, so area 1 cannot serve as the transit area. Junos will reject the configuration rather than build a broken link.
Options that preserve the requirement:
- Convert area 1 from stub to a normal area. This restores the LSAs the virtual link needs, but gives up stub filtering throughout area 1.
- Add a physical link from R4 to R1 or R2 and place it in area 0.
- Collapse area 2 into area 1, removing the need for a third area and for the virtual link.
A GRE tunnel between R3 and R4 placed in area 0 is technically possible but adds an overlay and MTU risk; it is a workaround, not a clean area design.
2. Explain the R7/R8 resets and describe the least disruptive fix, including how you would verify it.
Read the worked answer
OSPF identifies a router by its router ID, not by interface address. Both switches were cloned with router-id 10.0.0.1, so each receives hellos that appear to come from itself or from a conflicting instance of the same router. Junos logs the duplicate and tears down or refuses the adjacency, which then retries, producing the 40-second cycle. The problem is not the VLAN or the timers; the core is stable because it has unique IDs.
Fix:
- Configure unique loopback addresses, for example 10.0.0.7/32 and 10.0.0.8/32, and set router-id to those addresses on R7 and R8 respectively.
- Clear the OSPF adjacencies (clear ospf neighbor) so the new IDs take effect immediately rather than at the next process restart.
- Verify with show ospf neighbor on R7, R8, and the core, and confirm the duplicate-ID message stops. Also check show ospf database to ensure no stale LSAs remain advertised under 10.0.0.1.
The underlying process failure is cloning a template that contains a unique identifier; router IDs and loopbacks should be per-device variables.