OSPFv3 configuration — router-id, area assignment, interface parameters, IPv6-only

The OSPFv3 configuration on VyOS 1.5 LTS lives under set protocols ospfv3. The block is parallel to set protocols ospf (OSPFv2) but not identical: there is no network statement, the per-interface parameters are scoped per-interface rather than per-area, and the redistribution syntax uses IPv6 prefix-lists.

This lesson covers the configuration tree in operational depth: the minimum configuration that produces an OSPFv3 adjacency, the explicit router-id, the per-interface parameters, the redistribution primitives, and the validation command set.

The minimum OSPFv3 configuration

The smallest working OSPFv3 configuration on VyOS 1.5 LTS:

set protocols ospfv3 parameters router-id 10.255.0.1
set protocols ospfv3 area 0 interface eth0
set protocols ospfv3 area 0 interface eth1
commit
save

Three lines. The router-id is configured explicitly (a 32-bit opaque value, here chosen from a /32 in the loopback range to match the operator’s OSPFv2 conventions even though the value is opaque). Two interfaces are placed into area 0. After commit, ospf6d starts sending OSPFv3 Hellos on both interfaces and forms adjacencies with any IPv6-speaking OSPFv3 neighbour on the link.

flowchart LR
  subgraph "VyOS 1.5 R1"
    O3["ospf6d process<br/>router-id 10.255.0.1"]
    A0["area 0"]
    E0["eth0 fe80::1 2001:db8:1::1/64"]
    E1["eth1 fe80::2 2001:db8:2::1/64"]
  end
  subgraph "R2 (neighbour)"
    O3R["ospf6d process<br/>router-id 10.255.0.2"]
    A0R["area 0"]
    E0R["eth0 fe80::2 2001:db8:1::2/64"]
  end
  O3 --> A0
  A0 --> E0
  A0 --> E1
  E0 -- "OSPFv3 Hello<br/>ff02::5 fe80::1" --> E0R
  E0R --> O3R

After the commit, the operator validates:

show ipv6 ospf6
# Router-ID: 10.255.0.1
# Area 0: interface eth0, interface eth1

show ipv6 ospf6 neighbor
# Neighbor ID     Pri   DeadTime  State/IfState         I/fState Duration
# 10.255.0.2        1    00:00:38 Full/DR               eth0     00:00:35

show ipv6 ospf6 interface eth0
# Interface eth0
#   Area 0, MTU 1500
#   Router-ID 10.255.0.1
#   Network Type: BROADCAST
#   Cost: 10
#   Link-local address: fe80::1

The adjacency forms. The router-id shows in the output (a 32-bit value), the link-local is the source address, the neighbour’s neighbour-id is the remote router’s router-id (not its link-local).

Router-id discipline

The router-id is a 32-bit opaque value in OSPFv3, not an IPv4 address. Production discipline says: configure it explicitly. The rationale:

• Stability across restarts. Without an explicit router-id, FRR derives it from the highest IPv4 address on the router, or from the highest loopback IPv4 address. If the IPv4 addressing changes (a new loopback, a configuration error), the router-id changes, every OSPFv3 session re-converges, every Type 1 LSA in the LSDB is regenerated.
• Uniqueness across the domain. Two OSPFv3 routers with the same router-id produce identical Type 1 LSAs and the LSDB diverges. The OSPFv3 router-id must be unique inside the OSPFv3 domain, just like OSPFv2.

# Production discipline: configure a stable /32 loopback address
# and use that as the OSPFv3 router-id

set interfaces loopback lo address 10.255.0.1/32

set protocols ospfv3 parameters router-id 10.255.0.1
commit
save

The loopback address is IPv4; the router-id is opaque. The operator chooses an IPv4 address because the convention is well-known and the operator already has IPv4 loopbacks configured. The router-id is not an IPv4 address; it is a 32-bit value the OSPFv3 protocol uses to identify the originating router.

Per-interface area assignment

The interface assignment is per-interface under the area:

set protocols ospfv3 area 0 interface eth0
set protocols ospfv3 area 0 interface eth1
set protocols ospfv3 area 1 interface eth2
set protocols ospfv3 area 1 interface eth3

There is no network statement in OSPFv3. The interface is enabled into the area; the protocol discovers the IPv6 prefixes via Type 8 and Type 9 LSAs.

For a multi-area design, the ABR (the router with interfaces in multiple areas) is configured with area 0 interface ... for the backbone interfaces and area 1 interface ..., area 2 interface ..., etc. for the non-backbone areas. The ABR’s behaviour (Type 3 Summary generation, Type 7 to Type 5 translation for NSSA) follows the same rules as OSPFv2.

flowchart TB
  subgraph "ABR"
    ABR["ospf6d router-id 10.255.0.4"]
    E0["eth0 area 0<br/>fe80::1 2001:db8:0::1/64"]
    E1["eth1 area 1<br/>fe80::2 2001:db8:1::1/64"]
  end
  subgraph "Area 0 backbone"
    B0["R-BB<br/>router-id 10.255.0.1"]
  end
  subgraph "Area 1 stub"
    S1["R-S1<br/>router-id 10.255.0.5"]
  end
  ABR --> E0
  ABR --> E1
  E0 -- "OSPFv3" --> B0
  E1 -- "OSPFv3" --> S1

Per-interface parameters

The per-interface OSPFv3 parameters under set protocols ospfv3 interface eth0:

# A DMZ interface that should advertise its prefix but not form
# adjacencies with the (untrusted) DMZ segment:
set protocols ospfv3 area 0 interface eth2 passive

# A point-to-point transit link with manual cost for traffic-engineering:
set protocols ospfv3 area 0 interface eth3 network-type point-to-point
set protocols ospfv3 area 0 interface eth3 cost 5

# A high-priority interface to bias DR election:
set protocols ospfv3 area 0 interface eth0 priority 200

The instance-id parameter is a feature unique to OSPFv3. Multiple OSPFv3 processes can run on the same link by using different instance-ids; the instance-id is carried in the Hello packet and only neighbours with the same instance-id form an adjacency. This is the OSPFv3 equivalent of running multiple OSPFv2 processes with different process-ids.

Redistribution into OSPFv3

The redistribution primitives follow the OSPFv2 model, with IPv6 prefix-lists for the route-map:

# Define an IPv6 prefix-list for the prefixes to redistribute
set policy prefix-list6 CONNECTED-IPV6 rule 10 action permit
set policy prefix-list6 CONNECTED-IPV6 rule 10 prefix 2001:db8:99::/48
set policy prefix-list6 CONNECTED-IPV6 rule 10 ge 48
set policy prefix-list6 CONNECTED-IPV6 rule 20 action deny
set policy prefix-list6 CONNECTED-IPV6 rule 20 prefix '::/0'

# Define a route-map that uses the prefix-list
set policy route-map CONNECTED-INTO-OSPFv3 rule 10 action permit
set policy route-map CONNECTED-INTO-OSPFv3 rule 10 match ipv6 address prefix-list CONNECTED-IPV6
set policy route-map CONNECTED-INTO-OSPFv3 rule 10 set metric 20
set policy route-map CONNECTED-INTO-OSPFv3 rule 10 set metric-type type-2

# Apply the redistribution
set protocols ospfv3 redistribute connected route-map CONNECTED-INTO-OSPFv3
commit
save

The route-map sets a metric-type 2 (the OSPFv3 default for external routes) and a metric of 20 (overridable). The IPv6 prefix-list filters the prefixes that the redistribution block is allowed to advertise; without a route-map the redistribution advertises all connected routes, including the loopback and any test addresses.

flowchart LR
  subgraph "Connected routes (R1)"
    C1["2001:db8:99::/48<br/>connected"]
    C2["2001:db8:1::/64<br/>eth0 connected"]
    C3["2001:db8:2::/64<br/>eth1 connected"]
    C4["10.255.0.1/32<br/>loopback connected"]
  end
  subgraph "route-map CONNECTED-INTO-OSPFv3"
    R1["rule 10: match CONNECTED-IPV6<br/>set metric 20 type-2"]
    R2["rule default deny"]
  end
  subgraph "OSPFv3 LSDB"
    L1["Type 5 AS-External<br/>2001:db8:99::/48 metric 20"]
  end
  C1 --> R1
  C2 --> R1
  C3 --> R1
  C4 --> R1
  R1 -- "permit" --> L1
  R1 -- "deny (default)" --> R1

Without the route-map the redistribution would advertise all connected routes including the loopback, which the operator usually does not want.

Authentication

OSPFv3 abandoned the OSPFv2 built-in authentication. The mechanism is either IPsec AH/ESP on the OSPFv3 packets, or the OSPFv3 authentication trailer defined in RFC 7166.

On VyOS 1.5 LTS the configuration for the OSPFv3 authentication trailer:

set protocols ospfv3 area 0 authentication ipsec spi 256 protocol esp
set protocols ospfv3 area 0 authentication ipsec spi 256 algorithm sha1
set protocols ospfv3 area 0 authentication ipsec spi 256 key ascii SECRET
commit
save

The spi 256 value identifies the Security Parameter Index; both routers in the area must use the same SPI. The algorithm and key must match.

sequenceDiagram
  participant R1
  participant R2
  R1->>R2: OSPFv3 Hello<br/>SPI 256, SHA1, KEY=SECRET
  Note over R1,R2: Mismatch: SPI different<br/>Adjacency fails
  R1->>R2: OSPFv3 Hello<br/>SPI 256, SHA1, KEY=SECRET
  Note over R1,R2: Match: Adjacency forms

The alternative is IPsec transport-mode with manual keying, which requires an encryption-domain block matching the OSPFv3 packets.

Validation

The validation command set:

show ipv6 ospf6
# Router-ID, areas, interfaces

show ipv6 ospf6 neighbor
# Adjacencies with state, dead-time, interface

show ipv6 ospf6 interface eth0
# Per-interface: area, MTU, network-type, cost, link-local

show ipv6 ospf6 database
# LSDB summary

show ipv6 ospf6 database router self-originate
# Type 1 LSAs originated by this router

show ipv6 ospf6 database intra-prefix
# Type 9 Intra-Area-Prefix LSAs

show ipv6 ospf6 database external
# Type 5 AS-External LSAs

show ipv6 route ospf6
# IPv6 routes via OSPFv3

show ipv6 ospf6 border-routers
# ABR / ASBR router-id list

traceroute 2001:db8:1::2
# Validate the path the traffic takes

A working baseline shows:

• Every interface is in the expected area with the expected parameters.
• Every neighbour has Full state and a stable dead-time.
• The LSDB has Type 1, Type 8, Type 9 LSAs for the local topology.
• The RIB has the expected IPv6 routes via OSPFv3.
• traceroute follows the expected path.

Production failure modes

• Missing router-id. The operator forgets set protocols ospfv3 parameters router-id. FRR derives one from the highest IPv4 address, which may be unstable. The fix is the explicit router-id.
• Wrong area assignment. An interface is in area 1 but expected in area 0. The adjacency forms in the wrong area. The fix is delete protocols ospfv3 area 1 interface eth0 followed by set protocols ospfv3 area 0 interface eth0.
• Passiveness on the wrong side. The operator marks eth0 passive, expecting only eth1 to form adjacencies. The eth0 interface does not send Hellos; the adjacency fails. The fix is removing the passive flag on the intended-active interface.
• Redistribution loop. OSPFv3 is redistributed into BGP and BGP is redistributed back into OSPFv3. The operator recognises the loop and removes one of the redistribution blocks.
• Authentication mismatch. The OSPFv3 authentication trailer is configured on R1 but not R2. The Hellos are silently dropped. The fix is aligning the configuration on both sides.
• Instance-id mismatch. R1 has instance-id 1, R2 has the default instance-id 0. The Hellos do not match. The fix is aligning the instance-id.

Rollback

The OSPFv3 rollback path:

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

# Compare
compare

# Commit with a short confirm window
commit-confirm 5

# Rollback if needed
rollback 1
commit

For a router-id change, the OSPFv3 process restart:

vtysh -c 'clear ipv6 ospf6 process'

The process restart tears down every OSPFv3 adjacency and refloods every Type 1 LSA. The operator plans this for a maintenance window.

Production discipline

Cross-course references

The IPv6 lessons vyos-xi-01-ipv6-fundamentals, vyos-xi-02-ipv6-addressing, and vyos-xi-06-ipv6-troubleshoot cover the IPv6 primitives this lesson assumes. The OSPF configuration lessons vyos-xix-01-ospf-basics, vyos-xix-02-ospf-interface-config, and vyos-xix-04-ospf-redistribute cover the OSPFv2 idioms; the OSPFv3 idioms are parallel but not identical. The OSPFv3 concept lesson vyos-xxi-01-ospfv3-concept covers the protocol-level changes this lesson builds on. The OSPFv3 troubleshooting lesson vyos-xxi-04-ospfv3-troubleshoot covers failure modes specific to OSPFv3 configuration.

Quiz