OSPF on Linux Part 4: Wiring LAB-LNX into the OSPF Deep Dive Lab

23 July 2026 Linux OSPF Routing Networking FRRouting

OSPF Deep Dive’s lab has stood at three routers since its Part 1: CORE-CSR (Cisco IOS-XE, 10.0.0.1), BRANCH-FGT (FortiGate, 10.0.0.2, originating Area 1), and EDGE-MX (Junos, 10.0.0.3, originating Area 2 across the virtual link Part 4 of that series built). Area 0 is where all three meet. This post adds a fourth router to that same Area 0: LAB-LNX, the Linux box configured with FRR in Part 3, router ID 10.0.0.4.

The new link

CORE-CSR gets a second Area 0 interface, a point-to-point link to LAB-LNX on 10.0.0.12/30, the same addressing style as the CORE-CSR link OSPF Deep Dive Part 7 already showed, network 10.0.0.0 0.0.0.3 area 0, just a different /30 in the same block:

! CORE-CSR, added alongside the existing Area 0 network statement
interface GigabitEthernet0/2
 ip address 10.0.0.13 255.255.255.252
 ip ospf 1 area 0

! LAB-LNX, from Part 3
router ospf
 ospf router-id 10.0.0.4
 network 10.0.0.12/30 area 0.0.0.0

Nothing about Area 1, Area 2, or the virtual link changes. LAB-LNX joins as a fourth backbone router, not a fourth area, which keeps this post about the adjacency itself rather than reopening the area-design discussion from OSPF Deep Dive Parts 2 and 4.

Down to Full, on the platform that shows you every step

The state machine is the same table from OSPF Deep Dive Part 1, Down, Init, 2-Way, ExStart, Exchange, Loading, Full, and FRR’s ospfd reports it with vtysh’s show ip ospf neighbor, the same command name IOS-XE uses, one of the direct payoffs of FRR’s Cisco-shaped CLI from Part 2:

LAB-LNX# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.0.0.1        1     Full/-          00:00:38    10.0.0.13       GigabitEthernet0/2:10.0.0.14

Full/- is worth reading carefully against the Cisco and FortiOS output from OSPF Deep Dive Part 11: the dash where a DR/BDR role would appear means this segment came up as point-to-point, no election, matching the network-type table from Part 1 of that series, a /30 with exactly two routers on it is the textbook case for treating it as point-to-point rather than broadcast.

Watching the states pass in real time is where FRR earns its keep for learning the protocol specifically, in a way none of the three appliances make easy. debug ospf adj on LAB-LNX prints every state transition to the log as it happens:

LAB-LNX# debug ospf adj
...
OSPF: NSM[10.0.0.13:10.0.0.1]: Init -> 2-Way
OSPF: NSM[10.0.0.13:10.0.0.1]: 2-Way -> ExStart
OSPF: NSM[10.0.0.13:10.0.0.1]: ExStart -> Exchange
OSPF: NSM[10.0.0.13:10.0.0.1]: Exchange -> Loading
OSPF: NSM[10.0.0.13:10.0.0.1]: Loading -> Full

That’s the abstract table from Part 1 of OSPF Deep Dive happening on screen, in order, on a link that took about a second to converge. Getting the equivalent view on CORE-CSR requires debug ip ospf adj and reading syslog; on FortiOS or Junos it means digging into diagnose output or traceoptions respectively. None of that is a knock on those platforms, appliance debug output is intentionally terser by default, it’s just a genuine advantage of doing the first pass of learning the state machine on Linux specifically, where the daemon’s own log is right there.

LSDB parity, across four platforms now

Once LAB-LNX reaches Full with CORE-CSR, it receives the full Area 0 LSDB, everything CORE-CSR, BRANCH-FGT, and EDGE-MX have already flooded between themselves, including the Type 3 summaries for Area 1’s 10.10.10.0/24 and whatever Area 2 has advertised through the virtual link. show ip ospf database on LAB-LNX should list the same LSAs, same sequence numbers, same originating router IDs, as get router info ospf database on BRANCH-FGT or show ospf database extensive on EDGE-MX:

LAB-LNX# show ip ospf database

       OSPF Router with ID (10.0.0.4)

                Router Link States (Area 0.0.0.0)

Link ID         ADV Router      Age  Seq#       CkSum  Link count
10.0.0.1        10.0.0.1        42   0x8000000c 0x4a1f 2
10.0.0.2        10.0.0.2        51   0x80000009 0x91b3 2
10.0.0.3        10.0.0.3        38   0x8000000e 0x2c7a 2
10.0.0.4        10.0.0.4        12   0x80000001 0x77e2 1

Four Router LSAs, one per router in Area 0 including LAB-LNX’s own, is the actual confirmation that this isn’t just an adjacency, it’s a synchronized database, the distinction OSPF Deep Dive Part 10 draws between a neighbor-state problem and an LSDB problem. show ip route ospf on LAB-LNX should then show a route toward Area 1’s 10.10.10.0/24 and whatever Area 2 originates, learned the same way CORE-CSR and BRANCH-FGT already learn it, an inter-area route via Type 3.

Part 5 turns this into a troubleshooting reference: the show commands mapped against all four platforms side by side, and the failure modes that are specific to running OSPF on Linux and don’t have an equivalent on any of the three appliances.