Examkin

Question

Difficulty: HardOSPFv2 Neighbor Adjacencies and Router ID

An administrator is configuring OSPFv2 on Router R1. The router has no explicit 'router-id' command under its OSPF process, but has the following active interfaces:
- Loopback0: 172.16.1.1/32
- Loopback1: 10.200.1.1/32
- GigabitEthernet0/0: 10.0.0.1/24 (configured with 'ip ospf 1 area 0')

Directly connected on GigabitEthernet0/0 is Router R2, which has its OSPF process configured with an explicit 'router-id 172.16.1.1' and GigabitEthernet0/0 (10.0.0.2/24) in Area 0. When both routers attempt to form an adjacency, R1 shows R2 stuck in the INIT state, and R2 logs report duplicate OSPF packets.

Based on OSPF election logic and neighbor requirements, why is the neighbor relationship stuck in this state?

  1. R1 selected 172.16.1.1 as its Router ID because it has the highest IP address among active loopback interfaces, causing a duplicate Router ID conflict with R2.Answer
  2. B
    R1 selected 10.200.1.1 as its Router ID because Loopback1 was configured after Loopback0, causing an OSPF area identifier mismatch between the neighbors.
  3. C
    R1 selected 10.0.0.1 as its Router ID because physical interfaces override loopback interfaces when OSPF is enabled directly on the interface, causing a DR/BDR election priority failure.
  4. D
    R1 selected 10.200.1.1 as its Router ID because OSPF defaults to selecting the lowest active loopback IP address, causing MTU negotiation to fail during Hello exchange.

Answer

R1 selected 172.16.1.1 as its Router ID because it has the highest IP address among active loopback interfaces, causing a duplicate Router ID conflict with R2.
The correct answer identifies that R1 automatically selects 172.16.1.1 as its Router ID because 172.16.1.1 is the highest IP address among its active loopback interfaces (172.16.1.1 vs 10.200.1.1). Because R2 has an explicit Router ID of 172.16.1.1, both routers share the same Router ID on the segment. Routers with duplicate Router IDs ignore or reject each other's Hello packets and fail to list each other as valid neighbors, causing the relationship to remain stuck in the INIT state.

Step-by-Step Solution

1
Determine the OSPF Router ID selection logic on R1.
Since no explicit 'router-id' command is configured, R1 checks active loopback interfaces. It compares Loopback0 (172.16.1.1) and Loopback1 (10.200.1.1). Because 172.16.1.1 is numerically higher than 10.200.1.1, R1 selects 172.16.1.1 as its OSPF Router ID.
OSPF Router ID election order is: 1) Explicit 'router-id' command, 2) Highest IP address among active loopbacks, 3) Highest IP address among active physical interfaces.
2
Compare R1's Router ID with R2's Router ID.
R2 is explicitly configured with OSPF Router ID 172.16.1.1. Both R1 and R2 are using the identical Router ID (172.16.1.1) on the same network segment.
Duplicate OSPF Router IDs on the same segment prevent routers from establishing bi-directional communication.
3
Analyze the impact of duplicate Router IDs on OSPF neighbor state.
When R2 receives Hello packets from R1 with a source Router ID identical to its own, it discards them or fails to list R1 as a valid neighbor. R1 receives Hello packets but never sees its own Router ID listed in R2's Hello packet neighbor field, keeping the state stuck in INIT.
Transitioning from INIT to 2-WAY requires a router to see its own Router ID in the received Hello packet's neighbor list.

Key Concept

OSPFv2 Router ID Election Hierarchy and Duplicate Router ID Neighbor Behaviors
Rate this question

Topics

OSPFv2 Neighbor Adjacencies and Router ID

More questions from this topic