OSPF basics — enabling OSPF, router-id, default route, and area assignment

A router that wants to run OSPF on VyOS 1.5 LTS does three things: it declares an OSPF process with set protocols ospf, it sets a stable router-id, and it tells the OSPF process which interfaces (or, more precisely, which networks) participate in which area. This lesson is the operator’s foundation in OSPF configuration on VyOS: the minimal configuration that produces a working adjacency with a neighbour, the reason every production deployment sets the router-id explicitly, and the four canonical ways to get a default route into the OSPF domain.

The minimal OSPF configuration

The smallest possible OSPF configuration on VyOS 1.5 LTS looks like this:

set protocols ospf area 0 network 10.0.0.0/24
set protocols ospf area 0 network 10.1.0.0/24

That is it. After commit; save, the ospfd daemon joins the OSPF domain on every interface whose primary or secondary address falls in 10.0.0.0/24 or 10.1.0.0/24, places that interface in area 0, and starts sending OSPF Hello packets out. If there is an OSPF-speaking neighbour on the link, an adjacency forms within a few seconds and the router begins participating in the link-state exchange.

flowchart LR
  subgraph "Router R1 (VyOS 1.5)"
    OS["ospfd<br/>process-id: local"]
    RID["router-id<br/>10.255.0.1"]
    A0["area 0.0.0.0"]
  end
  subgraph "interface eth0"
    E0["10.0.0.1/24"]
  end
  subgraph "interface eth1"
    E1["10.1.0.1/24"]
  end
  subgraph "interface eth2"
    E2["192.168.50.1/24"]
  end
  OS --> RID
  OS --> A0
  A0 -- "network 10.0.0.0/24" --> E0
  A0 -- "network 10.1.0.0/24" --> E1
  E2 -. "not matched by any network statement" .- OS

Notice that eth2 (192.168.50.0/24) does not appear in any network statement. OSPF will not run Hello packets out that interface; the interface stays passive to OSPF even though it is up. This is the canonical use of the network statement: it selects which interfaces participate in OSPF, by prefix match.

Why the router-id must be set explicitly

The OSPF router-id is a 32-bit value that uniquely identifies the router inside the OSPF domain. It appears in every OSPF Hello the router sends, in every Database Description packet, and in every LSA the router originates. Two routers with the same router-id in the same OSPF domain produce duplicate-LSA warnings and the LSDB cannot converge cleanly.

VyOS 1.5 LTS / FRR 10.x derive the router-id in this order if it is not set explicitly:

1. The highest IP address on a configured loopback interface.
2. The highest IP address on any active interface if no loopback exists.

This auto-derivation is convenient in a lab. In production it is a trap: a router whose loopback is added late, or whose interface addresses are renumbered, silently takes a new router-id. That new router-id invalidates the existing LSDB entries the router originated, the router restarts as a fresh participant, and every LSA it originated briefly flaps through the domain.

The fix is to set the router-id explicitly. The convention in every production deployment is to use a stable, dedicated loopback address that has nothing to do with the IGP topology — typically something in 10.255.0.0/16 reserved for router-ids.

set protocols ospf router-id 10.255.0.1
set protocols ospf area 0 network 10.0.0.0/24
set protocols ospf area 0 network 10.1.0.0/24
set protocols ospf area 0 network 10.255.0.0/24
commit
save

The third network statement ensures the loopback is part of OSPF as well, so the router-id is reachable as a /32 in the LSDB and other routers can ping the router-id for troubleshooting.

Area assignment: putting the right interfaces in the right area

Every interface that participates in OSPF belongs to exactly one area. The area is declared at the network statement that selects the interface, and every interface whose address falls within that network statement joins that area. An interface cannot be in two areas at once (that is what makes an ABR an ABR — it has interfaces in multiple areas).

flowchart TB
  subgraph "Router R2"
    subgraph "area 0"
      E0["eth0<br/>10.0.0.2/24"]
      E1["eth1<br/>10.1.0.2/24"]
    end
    subgraph "area 10 (remote site)"
      E2["eth2<br/>10.50.0.1/24"]
    end
    subgraph "area 20 (DMZ)"
      E3["eth3<br/>10.60.0.1/24"]
    end
  end
  N1["network 10.0.0.0/24 area 0"]
  N2["network 10.1.0.0/24 area 0"]
  N3["network 10.50.0.0/24 area 10"]
  N4["network 10.60.0.0/24 area 20"]
  N1 --> E0
  N2 --> E1
  N3 --> E2
  N4 --> E3

set protocols ospf area 0 network 10.0.0.0/24
set protocols ospf area 0 network 10.1.0.0/24
set protocols ospf area 10 network 10.50.0.0/24
set protocols ospf area 20 network 10.60.0.0/24

The above configuration makes R2 an ABR: it has interfaces in area 0 (backbone), area 10 (remote site), and area 20 (DMZ). R2’s Type-3 Summary LSAs flow between the areas; R2 is responsible for not turning any of those areas into a transit area. The lesson on OSPF area design (Part XX) covers the area-design discipline in detail.

Advertising a default route into OSPF

There are four canonical ways to advertise a default route (0.0.0.0/0) into an OSPF domain, and each has a different operational meaning.

The first three methods advertise a default route domain-wide. The fourth is scoped to a single area (and is covered in lesson xix-03).

The canonical production pattern at an upstream edge router that has a static default route toward the ISP is:

set protocols static route 0.0.0.0/0 next-hop 203.0.113.1
set protocols ospf default-information originate metric 10 metric-type 1
commit
save

The metric 10 sets the OSPF cost of the default route. The metric-type 1 makes the cost cumulative as the LSA traverses the OSPF domain (Type-1 external metrics add to the intra-area cost at every hop; Type-2 external metrics keep the original external cost). Type 1 is the right choice when downstream routers have different costs to reach the originating router; Type 2 is acceptable when the originating router is the only upstream.

How the result is validated

The operator must confirm four things after an OSPF configuration change.

show ip ospf                       # router-id, area summary, counts
show ip ospf neighbor              # adjacencies, state, dead timer
show ip ospf interface             # per-interface OSPF state, cost, network type
show ip route ospf                 # routes OSPF has installed in the RIB

A working baseline shows:

• router-id matches the value that was set (or the auto-derived one if not set — and the operator knows which it is).
• At least one neighbour in state Full.
• Every interface that should be in OSPF appears in show ip ospf interface with the expected area.
• show ip route ospf lists the prefixes the operator expects from the OSPF domain.

If a neighbour is stuck in Init, 2-Way, Exstart, or Exchange, the lesson on OSPF troubleshooting (Part XXII) covers the diagnosis. The basics are: matching area, matching network type, matching MTU, matching hello/dead timers, matching authentication.

sequenceDiagram
  participant Op as Operator
  participant Vy as VyOS configure mode
  participant Frr as FRR ospfd
  participant N as Neighbour

  Op->>Vy: set protocols ospf router-id 10.255.0.1
  Op->>Vy: set protocols ospf area 0 network 10.0.0.0/24
  Op->>Vy: set protocols ospf default-information originate
  Op->>Vy: commit
  Vy->>Frr: northbound API push
  Frr->>N: Hello packet
  N-->>Frr: Hello reply
  Frr->>N: DD exchange
  N-->>Frr: DD reply
  Frr->>N: LSR request
  N-->>Frr: LSU update
  Frr-->>Op: neighbour 10.0.0.2 is Full

How traffic actually flows

A host on 192.168.50.0/24 (behind R2, area 10) wants to reach 8.8.8.8 (Internet, via the upstream on R1, area 0).

1. The host sends a packet to its default gateway, 10.50.0.1 (R2).
2. R2’s RIB lookup matches 0.0.0.0/0 as an OSPF route. The next-hop is R1 (because R1 originated the Type-5 LSA for the default with default-information originate).
3. R2 forwards the packet to R1.
4. R1’s RIB lookup matches 0.0.0.0/0 as a static route. The next-hop is 203.0.113.1 (the ISP).
5. R1 forwards the packet out the upstream interface.

OSPF’s role in this flow is steps 1-3: it carries the default route from R1 to R2, and it provides the intra-domain next-hops R2 needs to reach R1.

How it fails

The production failure modes the engineer must recognise at the “OSPF basics” level:

• Router-id collision. Two routers have the same router-id. The LSDB has duplicate-LSA warnings; SPF computes oscillating paths. The fix is to set explicit router-ids and bounce one of the routers (clear ip ospf process) so the LSDB converges on the corrected identities.
• Loopback not in OSPF. The router-id is set to a loopback address, but the loopback subnet is not in any network statement. Other routers cannot ping the router-id, which makes the loopback useless for iBGP peering, telemetry source addresses, or troubleshooting.
• Interface in the wrong area. An interface is in area 0 but should be in area 10. The Type-1 LSAs it generates are flooded into the backbone instead of the remote area; the remote area sees the interface’s subnet as a Type-3 Summary LSA from the backbone, which works but loses the intra-area optimisation.
• Default route advertised without an upstream. A router has default-information originate always but its own default static route has been deleted. The router advertises a default route to the OSPF domain that points into a blackhole.
• Misplaced network statement. A network 10.0.0.0/8 statement picks up interfaces the operator did not intend. Customer-facing interfaces get joined to OSPF, adjacencies form on links the operator did not know were OSPF-speaking, and the LSDB grows unexpectedly.

Rollback

The recovery from a bad OSPF configuration:

• delete protocols ospf and commit; save removes the entire OSPF process. The interfaces stop sending Hello packets within the router-dead interval (default 40 seconds).
• rollback N inside configure reverts to a previous configuration revision. Use this when the bad change was specific and known.
• For a router-id change: the router-id is established at process start. Changing it requires clear ip ospf process (in vtysh) or reset ip ospf process (VyOS operational mode). The process restart tears down every adjacency and refloods every Type-1 LSA. Plan a maintenance window.
• For a bad default-route advertisement: delete protocols ospf default-information originate and commit; save. The Type-5 LSA is withdrawn within the LSA refresh cycle (default 30 minutes, but the withdrawal propagates immediately).

Cross-course references

The Linux course’s XIX-Linux-NetFoundations covers the kernel routing-table primitives OSPF installs routes into. The VyOS lessons vyos-xviii-01-link-state, vyos-xviii-02-neighbours-and-adjacency, vyos-xviii-04-areas, and vyos-xviii-05-dr-bdr cover the link-state, adjacency, area, and DR/BDR concepts this lesson builds on. The lesson vyos-xix-02-ospf-interface-config covers per-interface OSPF parameters. The lesson vyos-xix-04-ospf-redistribute covers the redistribution primitives used at the upstream edge.

Quiz