Duplicate router-id — Type 1 LSA conflict, why uniqueness matters, recovery

The OSPF router-id is the originator identifier in every Type 1 Router-LSA the router originates. Two routers with the same router-id produce Type 1 LSAs that are indistinguishable in the LSDB; the LSDB diverges; the OSPF domain fragments. The diagnostic is show ip ospf database self-originate; the fix is to set a unique router-id and bounce one OSPF process.

This lesson covers the protocol-level details, the diagnostic sequence, the recovery procedure, and the production playbook for router-id hygiene.

Why a unique router-id matters

The router-id is a 32-bit opaque value in OSPF. It identifies the originating router in every Type 1 Router-LSA. The LSDB uses the (router-id, LSA-type, LSA-id) tuple as the key; if two routers have the same router-id, they produce Type 1 LSAs with the same key, and the LSDB cannot distinguish them.

The operational consequence:

• Type 1 LSA conflict. Two routers with the same router-id originate Type 1 LSAs with the same Advertising Router. The LSDB stores both; SPF cannot tell which is the “real” originator; the SPF tree diverges.
• Adjacency flap. The duplicate router-id causes the LSDB to oscillate; the adjacency flaps between Full and Down.
• Duplicate-LSA warnings. FRR logs a warning every time a duplicate LSA is received.

flowchart LR
  subgraph "LSDB with duplicate router-id"
    A1["Type 1 Router-LSA<br/>Advertising Router: 10.255.0.1<br/>(from R1)"]
    A2["Type 1 Router-LSA<br/>Advertising Router: 10.255.0.1<br/>(from R2 with same router-id)"]
    A3["SPF sees two Type 1 from same Advertising Router<br/>Conflict"]
  end
  A1 --> A3
  A2 --> A3

How the router-id is derived

When set protocols ospf parameters router-id is not configured, FRR derives the router-id from:

1. The highest IPv4 address on a loopback interface, if any.
2. The highest IPv4 address on any interface, if no loopback.

This derivation is convenient but unstable: if the IPv4 addressing changes (a new loopback, a configuration error), the router-id changes. The Type 1 LSAs are regenerated; the LSDB re-converges; the adjacency flaps.

Production discipline says: always configure the router-id explicitly.

set protocols ospf parameters router-id 10.255.0.1
commit
save

Diagnostic sequence

The diagnostic for a duplicate router-id:

1. Confirm the adjacency is flapping. show ip ospf neighbor shows the neighbour oscillating between Full and Down.
2. Check the router-id on both sides. show ip ospf on both routers shows the router-id. If they match, the router-id is duplicated.
3. Check the LSDB. show ip ospf database self-originate shows the Type 1 LSAs originated by this router. If there are duplicates with the same Advertising Router, the router-id is duplicated.
4. Check the FRR logs. journalctl -u frr shows the duplicate-LSA warnings.

show ip ospf
# Router-ID: 10.255.0.1

# On the neighbour:
show ip ospf
# Router-ID: 10.255.0.1

# Same router-id. Conflict.

show ip ospf database self-originate
# Type 1 Router-LSA
#   Advertising Router: 10.255.0.1
#   ...

# Duplicate-LSA warning in journalctl
journalctl -u frr
# ospfd[1234]: Received duplicate Type-1 LSA from 10.0.0.2

The recovery procedure

The recovery from a duplicate router-id:

1. Set a unique router-id on one side. Choose a new router-id that is unique inside the OSPF domain.
2. Commit the change. commit; save.
3. Bounce the OSPF process on one side. vtysh -c 'clear ip ospf process'. The process restart tears down every adjacency and refloods every Type 1 LSA with the new router-id.

The configuration:

# On R2 (the side with the duplicate router-id)
set protocols ospf parameters router-id 10.255.0.2
commit
save
vtysh -c 'clear ip ospf process'

After the process restart:

show ip ospf
# Router-ID: 10.255.0.2

show ip ospf neighbor
# Neighbor 10.255.0.1, interface address 10.0.0.1
#   State: Full

show ip ospf database self-originate
# Type 1 Router-LSA
#   Advertising Router: 10.255.0.2
#   (no duplicates)

The adjacency is Full; the LSDB has the unique router-id.

sequenceDiagram
  participant R1
  participant R2
  Note over R1,R2: Both have router-id 10.255.0.1<br/>Adjacency flaps
  R1->>R2: Type 1 (router-id 10.255.0.1)
  R2->>R1: Type 1 (router-id 10.255.0.1)
  Note over R1,R2: Conflict in LSDB
  Note over R2: Change router-id to 10.255.0.2<br/>Commit<br/>Bounce OSPF process
  R2->>R1: Type 1 (router-id 10.255.0.2)
  Note over R1,R2: LSDB converges<br/>Adjacency Full

Production playbook for router-id hygiene

The production playbook to prevent duplicate router-ids:

1. Allocate router-ids centrally. Maintain a registry of router-ids (e.g. an inventory spreadsheet, a CMDB, or an Ansible inventory). Every router gets a unique router-id from the registry.
2. Use a consistent convention. 10.255.0.<router-number> is a common convention. The operator’s runbook documents the convention.
3. Validate before deployment. Before deploying a new router, verify the router-id is unique in the OSPF domain: show ip ospf neighbor detail shows the existing router-ids.
4. Monitor for changes. journalctl -u frr logs the router-id at OSPF process start. Monitor for unexpected changes.
5. Use loopback for stability. The router-id is opaque; it does not need to be an IPv4 address. Using the loopback’s IPv4 address is convenient but tying the router-id to a specific loopback IP makes it easier to identify the router.

Multi-area and multi-process considerations

The router-id is unique inside the OSPF domain, not globally. A router can run OSPFv2 and OSPFv3 with the same router-id (10.255.0.1) because OSPFv2 and OSPFv3 are separate processes. The convention is to use the same router-id for both processes on the same router.

A router-id can also be reused across multiple OSPFv2 processes on the same router (if the operator runs more than one OSPFv2 process for VRF isolation, for example) as long as the processes do not share the same LSDB.

Diagnostic for related failures

Adjacency flap with no obvious cause

A common production failure: the OSPF adjacency flaps but show ip ospf neighbor shows no obvious cause. The diagnostic:

# Check the router-id
show ip ospf

# Check the LSDB for duplicates
show ip ospf database self-originate

# Check the FRR logs
journalctl -u frr | grep -i duplicate

If the router-id is duplicated, the FRR logs show the duplicate-LSA warnings.

Type 1 LSA with unexpected Advertising Router

A Type 1 LSA appears in the LSDB with an unexpected Advertising Router (a router-id the operator did not expect). The diagnostic:

# Show the Type 1 LSA in detail
show ip ospf database router <router-id>

# Cross-reference with the router-id registry
# Is this router-id allocated to a router?

If the router-id is not in the registry, it may be a misconfigured new router or a router that was supposed to be decommissioned.

Production failure modes

• Duplicate router-id (same as neighbour). The dominant failure. The fix is to set a unique router-id and bounce the OSPF process on one side.
• Router-id collision after a refactor. The operator changes the router-id on R1 to match R2 (without realising R2 has the same value). The fix is to choose a unique router-id.
• Derived router-id changes after restart. The operator configures a new loopback with a higher IPv4 address. FRR uses the new loopback IP as the router-id; the Type 1 LSAs regenerate; the adjacency flaps. The fix is to configure the router-id explicitly.
• Router-id assigned but not applied. The operator configures set protocols ospf parameters router-id but forgets to bounce the OSPF process. The router-id is in the configuration but the running OSPF process still uses the old router-id. The fix is to bounce the OSPF process.

Rollback

The rollback for a router-id change:

# Capture the running configuration
show configuration commands | save /tmp/ospf-rid-$(date +%s).txt

# Compare
compare

# Commit with a short confirm window
commit-confirm 5

# Rollback if needed
rollback 1
commit

# If the new router-id is committed but causes issues,
# revert and bounce the process
delete protocols ospf parameters router-id
set protocols ospf parameters router-id 10.255.0.1
commit
save
vtysh -c 'clear ip ospf process'

The process bounce is essential because the router-id is established at OSPF process start. Without the bounce, the running OSPF process keeps the old router-id.

Production discipline

Cross-course references

The OSPF fundamentals lesson vyos-xviii-02-neighbours-and-adjacency covers the neighbour state machine this lesson assumes. The OSPF configuration lesson vyos-xix-01-ospf-basics covers the router-id configuration. The OSPF troubleshooting lessons vyos-xxii-01-neighbour-stuck (neighbour-stuck states), vyos-xxii-03-area-mismatch (area mismatch), and vyos-xxii-06-missing-route (missing route) cover related failure modes. The OSPFv3 lesson vyos-xxi-02-ospfv3-config covers the OSPFv3 router-id (parallel concept).

Quiz