OSPF interface configuration — network type, timers, MTU, passive

The network statement selects which interfaces run OSPF and which area they belong to. The per-interface configuration under set protocols ospf interface controls how OSPF behaves on each of those interfaces: the network type, the timers, the MTU handling, the passive flag, and the cost. Every one of these parameters has a matching requirement at the other end of the adjacency — a mismatch produces a silent failure that does not surface as an error, only as a neighbour that never reaches Full.

This lesson covers the per-interface parameters that production OSPF deployments actually use, why the matching requirement exists, and the failure modes that surface when the matching requirement is broken.

The per-interface configuration block

set protocols ospf interface eth0
set protocols ospf interface eth0 network-type point-to-point
set protocols ospf interface eth0 hello-interval 10
set protocols ospf interface eth0 dead-interval 40
set protocols ospf interface eth0 cost 10
set protocols ospf interface eth0 passive disable
set protocols ospf interface eth0 mtu-ignore

The configuration tree accepts a per-interface block. Each parameter is optional; the operator sets only what the deployment needs. The defaults (broadcast network type, 10-second hello, 40-second dead, auto-cost based on bandwidth, MTU-aware) are the right values for the majority of Ethernet segments.

flowchart TB
  subgraph "Per-interface block: set protocols ospf interface <IFNAME>"
    NT["network-type<br/>broadcast | point-to-point | nbma | point-to-multipoint"]
    HI["hello-interval<br/>seconds (default 10)"]
    DI["dead-interval<br/>seconds (default 40)"]
    C["cost<br/>1-65535 (default = auto)"]
    P["passive<br/>default: passive-disable when matched by network statement"]
    MTU["mtu-ignore<br/>default: mtu-checked"]
    PR["priority<br/>0-255 (default 1)"]
    AUTH["authentication<br/>plaintext | md5 (covered in xix-05)"]
  end
  NT --> B((Adjacency
behaviour))
  HI --> B
  DI --> B
  C --> B
  P --> B
  MTU --> B
  PR --> B
  AUTH --> B

The matching requirement is the most important property of OSPF interface parameters. Hello packets carry the network type, the hello interval, the dead interval, the area, the authentication (if configured), and the subnet mask. If any of these fields disagrees between the two ends of a link, no adjacency forms.

Network type — broadcast vs point-to-point

OSPF’s network type controls two things: how the protocol discovers neighbours and whether a Designated Router is elected.

The default on Ethernet (eth*) interfaces is broadcast. On sub-interfaces (eth0.10) the default is broadcast as well. On point-to-point logical interfaces (GRE tunnels, WireGuard, WireGuard-style VTI) the operator should explicitly set point-to-point — otherwise DR election runs on a link that has exactly two endpoints, wastes cycles, and forces the operator to think about BDR failover on a link that has no failover semantics.

set protocols ospf interface wg0 network-type point-to-point
set protocols ospf interface eth0.100 network-type point-to-point

flowchart LR
  subgraph Broadcast["broadcast - default on Ethernet"]
    R1[R1] --- R2[R2]
    R2 --- R3[R3]
    R1 --- R3
    D["DR / BDR election"]
  end
  subgraph P2P["point-to-point"]
    P1[P1] --- P2[P2]
    N["no DR/BDR<br/>adjacency on demand"]
  end

Hello and dead timers

OSPF sends Hello packets every hello-interval seconds. If a neighbour does not hear a Hello within dead-interval seconds, it declares the neighbour dead and runs SPF to recompute paths. The defaults are 10 seconds and 40 seconds — the relationship is exactly dead = 4 * hello in the default, and that relationship is not enforced by OSPF, so an operator can pick any two values that satisfy dead > hello.

set protocols ospf interface eth0.10 hello-interval 10
set protocols ospf interface eth0.10 dead-interval 40

The two timers must match at both ends of the adjacency. A Hello from R1 with hello-interval=10 and a Hello from R2 with hello-interval=30 produce no adjacency; the mismatch is silent.

MTU — the EXSTART failure mode

OSPF’s Database Description (DD) exchange requires both ends to agree on the interface MTU. If R1 has MTU 1500 and R2 has MTU 1400, the adjacency does not leave the EXSTART state — DD packets are sent, but the master / slave negotiation fails because the DD packet size exceeds the peer’s interface MTU.

The diagnostic sequence:

show ip ospf neighbor        # neighbour stuck in ExStart
show ip ospf interface       # both interfaces have different MTU
show ip ospf neighbor detail # the "interface MTU" line shows the disagreement

The fix is to align the MTU. The pragmatic production options:

1. Match the MTU. Change the lower side to match the higher side. This is the right answer when both ends are under the operator’s control.
2. mtu-ignore. Configure set protocols ospf interface eth0 mtu-ignore on one end to make OSPF skip the MTU check during DD exchange. This is the right answer when the MTU mismatch is intentional (e.g. a service provider tunnel with a fixed MTU of 1400 and an Ethernet side of 1500) and the operator has independently validated that no packet larger than 1400 bytes needs to traverse the link.

Passive interfaces

A passive interface runs OSPF (its address is in the LSDB as a stub network) but does not send Hello packets out the interface. The interface cannot form adjacencies; the subnet is advertised into OSPF as a Type-1 stub network attached to the router.

The canonical use is a LAN segment where only one OSPF router exists. For example, a /24 DMZ segment with one router — there is no neighbour to discover; making the interface passive keeps the LSDB clean and avoids the operator wondering why a Hello is being sent into a segment where nothing responds.

set protocols ospf area 0 network 10.60.0.0/24
set protocols ospf interface eth0.60 passive

The network 10.60.0.0/24 statement puts eth0.60 into OSPF and advertises the subnet. The interface eth0.60 passive block suppresses Hello packets on that interface.

flowchart LR
  subgraph "active interface"
    R1A["R1<br/>Hello out"] --- N1["neighbour<br/>Hello in"]
    ADJ["adjacency: Full"]
  end
  subgraph "passive interface"
    R1P["R1<br/>no Hello out"] --- H["hosts on DMZ<br/>no OSPF"]
    LSA["LSA: stub network 10.60.0.0/24<br/>attached to R1"]
  end

Cost on the interface

The interface cost is the OSPF metric assigned to the link. The operator can set it explicitly or rely on the auto-cost calculation. Auto-cost is reference-bandwidth / link-bandwidth, default reference-bandwidth = 100 Mbps, default link bandwidth is the interface’s reported speed.

set protocols ospf interface eth0 cost 10
set protocols ospf auto-cost reference-bandwidth 1000

The cost value is the per-hop metric for that interface. SPF sums the costs along the path; the lowest-cost path is preferred. Cost is the single most important knob the operator has for OSPF traffic-engineering. Lesson xix-06 covers cost tuning in detail.

How the result is validated

show ip ospf interface                     # every OSPF interface with its parameters
show ip ospf interface eth0                # one interface in detail
show ip ospf neighbor                      # adjacencies and their state
show ip ospf neighbor detail               # including MTU, timer, network type

A working baseline shows:

• Every interface that should be in OSPF appears with the expected area, network type, hello/dead timers, and cost.
• Every adjacency is in state Full.
• The Interface MTU line in show ip ospf neighbor detail matches the actual interface MTU (or mtu-ignore is set).
• Passive interfaces do not appear in the neighbour list but their subnet does appear in the LSDB as a stub network.

How traffic actually flows

OSPF’s interface configuration has no direct effect on packet forwarding. The router forwards packets based on the FIB, which is built from the LSDB. The interface configuration affects how the LSDB is built (what adjacencies form, what timers govern neighbour liveness, what MTU the DD exchange accepts) — which in turn determines which prefixes are reachable through this router.

A subtle operational point: setting network-type point-to-point does not change the data-plane forwarding. It only changes whether DR election runs and whether Hello packets include the network-mask field. The choice of network type is about protocol behaviour, not packet forwarding.

How it fails

The production failure modes the engineer must recognise at the per-interface level:

• Network type mismatch. R1 has broadcast, R2 has point-to-point. No adjacency. Diagnose with show ip ospf neighbor detail and look at the network type on each side.
• Hello/dead timer mismatch. R1 has 10/40, R2 has 30/120. No adjacency. Diagnose with show ip ospf neighbor detail and look at the timer fields.
• MTU mismatch without mtu-ignore. R1 has 1500, R2 has 1400. Adjacency stuck in EXSTART. Diagnose with show ip ospf neighbor detail and look at Interface MTU.
• Passive on a link that should have an adjacency. Both sides set passive. No adjacency. The only evidence is the empty neighbour list.
• Cost too high to be useful. An interface has cost 1000; SPF prefers a 100-km fibre path over a 5-km copper path with cost 1000. The path is technically valid; the routing policy is wrong.
• Hello/dead timer shorter than the link can support. On a high-latency satellite link (RTT 1500 ms), a 1-second Hello interval produces Hello packets that arrive later than 1 second, and the neighbour declares the link dead. The operator must tune to the link’s actual RTT, not assume the LAN defaults work everywhere.

Rollback

The recovery from a bad per-interface OSPF configuration:

• Network type change. delete protocols ospf interface eth0 network-type reverts to the default (broadcast on Ethernet). The adjacency tears down and re-forms.
• Timer change. delete protocols ospf interface eth0 hello-interval and the same for dead-interval revert to 10/40.
• MTU-ignore removal. delete protocols ospf interface eth0 mtu-ignore re-enables the MTU check; if the MTU is still mismatched, the adjacency will go to EXSTART.
• Passive removal. delete protocols ospf interface eth0 passive resumes Hello packets; the adjacency forms within the dead interval.

For all of these, commit; save applies, and rollback N inside configure reverts to a known-good revision.

Cross-course references

The VyOS lessons vyos-xviii-02-neighbours-and-adjacency and vyos-xviii-05-dr-bdr cover the adjacency state machine and DR election that the network-type parameter controls. The lesson vyos-xix-01-ospf-basics covers the OSPF basics this lesson extends. The lesson vyos-xix-05-ospf-authentication covers the authentication parameters that are also part of the per-interface configuration block. The Linux course’s XV-Linux-NetConfig covers the MTU primitives that mtu-ignore interacts with.

Quiz