LEARN. PRACTICE. GROW.Identifiers with different roles
In OSPFv3, router ID remains a 32-bit identifier, commonly displayed as four dotted numbers. It does not need conversion into an IPv6 address. An interface also has an identifier, while Instance ID distinguishes instances on the same link. Do not confuse these fields with a platform CLI’s local process number. For an adjacency, confirm values actually used on the link and the area, as well as timers, configured authentication and network type. A matching inventory name does not prove compatibility of transmitted parameters.
Case: local connectivity without neighbors
A fictional change leaves R1 with Instance ID 0 and R2 with Instance ID 1 on the same transit. Directly connected IPv6 addresses still answer ping, but received OSPFv3 packets do not belong to the expected instance. After convergence, the route to the remote loopback disappears. The next action should compare both endpoints’ configuration rather than replace the service IPv6 address without evidence. Correct Instance ID according to the approved design and observe adjacency, route installation and a probe. Different values are not always mistakes: they can intentionally separate communities that should not form this adjacency.
A scoped link-local next hop
On the normal links in this exercise, OSPFv3 uses link-local addresses for control communication. A route to 2001:db8:2::1/128 can point to fe80::... through eth0. That is normal: the remote destination need not share the scope of the neighbor address used as next hop. Retain the interface alongside the link-local address because its meaning is limited to that link. A probe to a link-local neighbor requires the correct scope; by itself, it does not prove remote-prefix advertisement or a return path to the application source. Virtual links have different rules and are outside this lab.
Topology and prefixes are different
OSPFv3 separates topology information from prefix information. Link-LSAs have link-local scope and carry information such as the link-local address and associated prefixes. Intra-Area-Prefix-LSAs associate prefixes with topology within an area; Inter-Area-Prefix-LSAs advertise reachability between areas. Do not look for every IPv6 prefix in the router-LSA as if it were simply a copy of the OSPFv2 format. If adjacency is Full but a /128 disappeared, check whether the address remains configured, its advertisement, and route selection and installation. Restarting the process can destroy evidence without restoring the missing address.
Syntax and address families
The executable example uses FRRouting 10.4.5: router ospf6 and interface ipv6 ospf6 commands. Cisco IOS XE documentation presents router ospfv3 and address-family configuration, with differences from historical syntax. OSPFv3 can support IPv4 and IPv6 through address-family extensions; version 3 does not mean every platform carries IPv6 only. In this lab, however, IPv4 uses OSPFv2 and IPv6 uses OSPFv3. Confirm support and syntax on the target platform before migrating. FRR execution does not validate IOS XE commands or migration of existing configurations.
# FRRouting 10.4.5, disposable lab only
configure terminal
router ospf6
ospf6 router-id 1.1.1.1
exit
interface eth0
ipv6 ospf6 area 0
ipv6 ospf6 instance-id 0
end
show ipv6 ospf6 neighbor
show ipv6 ospf6 database
show ipv6 route
An IPv6 route via fe80::... and eth0 is normal; router ID 2.2.2.2 is not the service IPv6 address.
Common pitfalls
Confusing local process and Instance ID; omitting the interface for a link-local next hop; looking for prefixes only in router-LSAs.
Related topics: Dual stack: diagnosis and acceptance by family · OSPFv2: areas and summarization
Identify each field by its role and observe adjacency, advertisement and forwarding separately.
Reference: FRRouting OSPFv3 · 350-401 ENCOR v1.2, effective 2026-03-19; core component of CCNP Enterprise