Cisco IOS XE OSPFv3: Configure and Troubleshoot IPv6 Neighbors
When two IPv6 router interfaces can reach each other but a remote network is still missing from the routing table, changing the OSPF process blindly is a poor first move. An effective diagnosis separates interface state, OSPFv3 neighbor establishment, link-state information and the final forwarding decision.
In October 2026, Cisco’s currently tested CCNA 200-301 is v1.1. Its announced v2.0 starts testing on February 3, 2027 and explicitly calls for single-area OSPFv3 configuration for IPv6 alongside OSPFv2 for IPv4. The exercise below builds that forthcoming skill, without claiming v2.0 is already live. Commands are aligned to Cisco documentation but have not been executed on real routers in this editorial session.
Identify which of three network outcomes has failed
First, verify the routers have a usable IPv6 interface and can communicate on the expected link. Second, verify OSPFv3 interfaces in a compatible area have discovered one another and reached the neighbor state required by their network type. Third, examine whether each router learned and installed the remote prefix. A correct local IPv6 address does not prove an OSPFv3 adjacency, and a full adjacency does not prove every intended prefix is advertised and routable.
OSPFv3 normally uses IPv6 link-local communication with its neighbors. Link-local addresses are not a replacement for routing advertisements, and IPv6 addressing and Neighbor Discovery are distinct functions from OSPF. NDP handles local discovery and address-resolution behavior; OSPFv3 distributes topology and routing information. That difference explains why directly connected reachability can work while remote prefixes remain unavailable.
Plan a two-router single-area topology before configuring
Connect R1 GigabitEthernet0/0 directly to R2 GigabitEthernet0/0 in an isolated lab. Give R1 the shared-link address 2001:db8:12::1/64 and R2 2001:db8:12::2/64. Assign Loopback0 2001:db8:1::1/128 on R1 and 2001:db8:2::2/128 on R2. These addresses are from a documentation-only IPv6 range, not for use as public production routes.
Put both transit interfaces and both loopbacks into OSPF area 0 and assign distinct router IDs of 1.1.1.1 and 2.2.2.2. The IDs use 32-bit dotted-decimal notation even when the lab has no IPv4 interfaces. Local OSPF process ID 1 is used on both devices simply for readability; the local process number does not need to match between neighbors. Define the expected result before the commands: R1 should learn R2’s loopback prefix and R2 should learn R1’s.
Use one consistent IOS XE OSPFv3 configuration style
Cisco IOS XE supports the modern router ospfv3 process with address-family ipv6 unicast and an interface activation command such as ospfv3 1 ipv6 area 0. Older configurations using ipv6 router ospf and ipv6 ospf ... area exist, but copying pieces of both styles without release context can confuse troubleshooting. Cisco’s IOS XE OSPFv3 routing guide documents the modern process and operational command families.
The following are illustrative lab configurations for two routers that support this command style. Interface names and support must be verified on the actual simulator or IOS XE release; no execution is claimed here.
! R1 — offline example
ipv6 unicast-routing
router ospfv3 1
address-family ipv6 unicast
router-id 1.1.1.1
exit-address-family
interface GigabitEthernet0/0
ipv6 address 2001:db8:12::1/64
ospfv3 1 ipv6 area 0
no shutdown
interface Loopback0
ipv6 address 2001:db8:1::1/128
ospfv3 1 ipv6 area 0! R2 — offline example
ipv6 unicast-routing
router ospfv3 1
address-family ipv6 unicast
router-id 2.2.2.2
exit-address-family
interface GigabitEthernet0/0
ipv6 address 2001:db8:12::2/64
ospfv3 1 ipv6 area 0
no shutdown
interface Loopback0
ipv6 address 2001:db8:2::2/128
ospfv3 1 ipv6 area 0Keep the actual configuration and version visible in your lab notes. A wrong router ID, interface name or area should not be dismissed simply because a diagram appears symmetric. Production devices may already have route policies and active OSPF neighbors; work in a disposable topology rather than pasting this example into an operational router.
Verify interfaces, neighbors, database and installed routes separately
Start with the IPv6 interface status and check both ends. Then ask whether OSPFv3 sees a neighbor. Finally, check the link-state database and selected IPv6 routes. Cisco documents the read-only show ospfv3 command families; optional arguments may differ by platform. The commands below are prompts for real observation, not copied success transcripts.
show ipv6 interface brief
show ospfv3 interface
show ospfv3 neighbor
show ospfv3 database
show ipv6 route ospfA full OSPFv3 neighbor state demonstrates synchronization with a peer under the local network type; it does not by itself prove that the peer’s loopback has been advertised or selected for forwarding. If the neighbor is full but a remote loopback is not in the IPv6 routing table, inspect which interfaces participate, whether prefix information reached the database and whether another route is selected. Do not change metrics until the destination and adjacency are understood.
Read non-full neighbor states without hiding the problem
If no neighbor appears, begin with the interface being up, IPv6 processing, the OSPFv3 address family, area assignment and passive-interface settings. In Init, investigate whether the router receives a hello but is not recognized by its neighbor, including one-way filtering. ExStart or Exchange symptoms invite checks of MTU, network type and detailed negotiation evidence. Each state narrows the suspected layer; none licenses an indiscriminate process reset.
A persistent 2-Way state has a special interpretation on broadcast multiaccess networks. Two routers that are neither designated router nor backup may remain 2-Way with each other while each forms a full adjacency with the DR or BDR. On point-to-point relationships this DR election does not apply. Check the actual interface network type, number of participants and DR/BDR roles before calling every 2-Way entry broken. The forthcoming objective explicitly covers those distinctions as well as router identity.
Understand why 2-Way can be correct on a broadcast segment
A two-router lab is useful for learning one neighbor relationship, but a shared Ethernet segment with three or more routers introduces a different question. OSPF selects a designated router and a backup on a broadcast multiaccess network to avoid a full mesh of database adjacencies among every participant. Routers that are neither DR nor BDR can exchange hellos and recognize one another while their mutual state remains 2-Way. Treating every 2-Way entry as an outage leads to unnecessary configuration changes.
In a second disposable lab, connect three routers to one common Ethernet VLAN and examine the operational OSPF interface network type, designated-router identity, backup identity and neighbor roles. Decide which pairs should be fully adjacent before reading their actual output. Then compare with a genuine point-to-point connection: without broadcast DR/BDR election, its healthy neighbor relationship has a different expected shape. If network-type configuration is necessary, use supported syntax consistently at both ends rather than copying an old IPv6 OSPF command into a modern OSPFv3 address-family example.
The behavior also explains why a protocol state must be interpreted in context. An interface may be correctly configured but attached to the wrong VLAN, a neighbor can appear but fail to synchronize, and a full adjacency can still lack a route to the specific destination a client needs. No single green status indicator certifies all three layers.
Make the diagnosis reproducible with a short evidence record
When a lab fails, record the intended link addressing and area beside the observed values, not only the last error message. For the interface boundary, note up/down status, configured prefix and IPv6 processing on both routers. For adjacency, capture the local router ID, expected remote router ID, interface network type, area and neighbor state. For forwarding, record the remote loopback prefix, whether OSPFv3 knows it and whether the IPv6 routing table selected it.
These observations define different repairs. A down interface calls for correcting the link or administrative state; mismatched areas require aligning the intended routing domain; a stalled database exchange needs negotiation evidence; and a full adjacency with an absent remote loopback calls for examining which prefixes are advertised. Do not respond to every symptom by changing OSPF cost or restarting the process. Such changes may hide the original evidence and produce a new failure without solving the first.
After one justified change, re-run the same read-only commands and compare before and after. A repaired neighbor with no corresponding expected route is still incomplete. A route that is present but cannot carry traffic needs forwarding, filtering and return-path checks beyond OSPF neighbor formation. That closed-loop test is what makes a practical lab useful to a future network operator, rather than only an exercise in reproducing command syntax.
Separate a full adjacency from an absent remote prefix
In the two-router example, R1 should be able to learn 2001:db8:2::2/128 and R2 2001:db8:1::1/128, assuming the loopbacks participate and no other policy interferes. If a router reaches Full but lacks that route, investigate OSPFv3 database information, loopback activation, address family selection and route-table competition. A link-local OSPF neighbor address does not itself install a route to a remote global IPv6 prefix.
The existing single-area OSPF fundamentals article describes router IDs, LSAs, cost and the shortest-path model that remains useful here. This lesson owns the distinct IPv6 IOS XE configuration and neighbor-to-route troubleshooting task. Readers need to know which evidence belongs to adjacency, which describes the database, and which shows the forwarding path chosen by the device.
Test three reversible failures in a disposable lab
After obtaining a real baseline, change only one parameter per run. First place R2’s transit interface in the wrong area and inspect the resulting neighbor information; restore area 0 afterward. Second, introduce an incorrect duplicate router ID and examine the process and adjacency diagnostics; restore a unique ID before proceeding. Third, remove R2’s loopback from OSPFv3 while preserving the transit interface, then compare neighbor state to the remote route entry. Each exercise tests a different hypothesis.
Record the configuration changed, the actual observed command output, the expected protocol consequence and the evidence that confirms recovery. Avoid invented “FULL” transcripts or claims of measured timings when the commands have not been executed. This method rewards understanding rather than memorizing a screenshot. If link-level IPv6 is unhealthy, return to interface and link-local evidence before altering protocol timers or costs.
Study against the correct 200-301 exam version
A candidate testing by Cisco’s announced February 2, 2027 v1.1 deadline should still study against the current six-domain v1.1 blueprint. OSPFv3 configuration is a useful advance skill, not evidence that it is already the active v1.1 configuration requirement. For candidates taking the refreshed 200-301 v2.0 beginning February 3, 2027, this exercise supports its named single-area IPv6 OSPFv3 objective. Cisco can change the published blueprint, so verify the testing date and issuer topics before building a final study schedule.
The transferable outcome is precise: from two interface configurations and a few pieces of real output, determine whether a failure belongs to IPv6 interface reachability, OSPFv3 neighbor compatibility or missing learned prefixes. Restore the smallest justified configuration change and verify the selected route and traffic path. The commands in this article were source-checked, but no network simulator, router hardware or cloud service was operated in this editorial session.
