Examkin

Question

Difficulty: Very hardOSPFv2 Neighbor Adjacencies and Router ID

Two Cisco routers, R1 and R2, are connected via their GigabitEthernet0/0 interfaces on the 192.168.12.0/24 subnet in OSPF Area 0.

R1 operational status:
- Loopback 0: IP 10.10.10.1/32 (up/up)
- Loopback 1: IP 172.16.1.1/32 (up/down)
- GigabitEthernet0/0: IP 192.168.12.1/24 (up/up, MTU 1500)
- OSPF Process 1 was initialized while only Loopback 0 was active. Later, the command `router-id 1.1.1.1` was added under `router ospf 1`, but `clear ip ospf process` has not been executed.

R2 operational status:
- Loopback 0: IP 10.20.20.1/32 (up/up)
- GigabitEthernet0/0: IP 192.168.12.2/24 (up/up, MTU 1400)
- Hello and Dead timers match R1 on GigabitEthernet0/0.

Which TWO statements accurately describe the OSPF operational state and Router ID behavior between R1 and R2?

  1. R1 currently uses 10.10.10.1 as its active OSPF Router ID because the `router-id` command requires clearing the OSPF process to take effect.Answer
  2. R1 and R2 will establish a neighbor relationship up to the 2-Way state but will remain stuck in the ExStart/Exchange state.Answer
  3. C
    R1 currently uses 172.16.1.1 as its active OSPF Router ID because it is the highest loopback IP address configured on the router.
  4. D
    R1 and R2 will remain stuck in the INIT state because MTU values must match during the initial Hello packet exchange.

Answer

R1 uses 10.10.10.1 as its active OSPF Router ID because the manual `router-id` configuration requires resetting the OSPF process, and the routers will successfully achieve 2-Way neighbor state but become stuck in ExStart/Exchange state due to the MTU mismatch on GigabitEthernet0/0.
The statement regarding R1 using 10.10.10.1 is correct because manual `router-id` commands under `router ospf` are non-preemptive and require an explicit process reset (`clear ip ospf process`) to replace an already active router ID. The statement regarding the routers reaching 2-Way state but stalling in ExStart/Exchange is correct because MTU is not checked in Hello packets (allowing 2-Way neighbor discovery), but MTU mismatches fail verification during Database Description (DBD) packet exchanges in ExStart state.

Step-by-Step Solution

1
Determine active OSPF Router ID for R1.
R1 selected 10.10.10.1 (Loopback 0) during process initialization. Adding `router-id 1.1.1.1` later is non-preemptive and does not take effect until `clear ip ospf process` is executed. Loopback 1 (172.16.1.1) is down and ignored.
OSPF Router ID election logic evaluates active (up/up) interfaces at process startup, and manual CLI configuration changes are non-preemptive.
2
Evaluate Hello packet negotiation parameters between R1 and R2.
Hello and Dead timers match, Area IDs match (Area 0), subnet masks match, and authentication matches. Both routers receive each other's Hello packets and transition through INIT to 2-Way state.
MTU parameters are not included in OSPF Hello packets and do not prevent 2-Way neighbor state formation.
3
Evaluate Database Description (DBD) exchange between R1 and R2.
During ExStart/Exchange state, routers exchange DBD packets containing interface MTU values. Because R1 (MTU 1500) and R2 (MTU 1400) mismatch, neither router accepts the slave/master DBD renegotiation, trapping adjacency progression in ExStart/Exchange.
Cisco IOS enforces strict MTU matching in DBD packets during OSPF ExStart/Exchange states.

Key Concept

OSPF Router ID Non-Preemptive Election and MTU Mismatch Adjacency Impact
Estimated Time:3m 0s
Rate this question

Topics

OSPFv2 Neighbor Adjacencies and Router ID

More questions from this topic