OSPFv3 Configuration on Cisco IOS XE

This is the hands-on half of our OSPFv3 coverage: a complete dual-stack configuration on Cisco IOS XE, from ipv6 unicast-routing to verified end-to-end reachability, with every capture from a live CML lab. If you want the theory first (what changed from OSPFv2, how the LSA model works, why next hops are link-local), start with OSPFv3 Explained and come back. Both posts live in the OSPF and IPv6 clusters.

The Lab

R1 and R2 run dual stack: OSPFv2 for IPv4 and OSPFv3 for IPv6 on the same links (the common transition design). The R1-R2 primary link carries 10.0.12.0/24 and 2001:db8:12::/64; loopbacks are N.N.N.N and 2001:db8::N/128. A second R1-R2 link will host an OSPFv3 IPv4 address family adjacency later in the post.

Step 1: Enable IPv6 Routing

IOS XE does not route IPv6 by default, and this omission produces the classic silent failure (interfaces up, neighbors absent, nothing logged):

R1(config)# ipv6 unicast-routing

Step 2: Address the Interfaces

R1(config)# interface Ethernet0/1
R1(config-if)# ipv6 address 2001:db8:12::1/64
!
R1(config)# interface Loopback0
R1(config-if)# ipv6 address 2001:db8::1/128

Configuring any global IPv6 address also generates the link-local FE80:: address that OSPFv3 actually speaks over. On links where you want OSPFv3 without a global prefix (pure transit), ipv6 enable alone creates the link-local address and is sufficient.

Step 3: The OSPFv3 Process and Address Family

Modern IOS XE uses the router ospfv3 block with explicit address families (the older ipv6 router ospf syntax still parses but funnels into the same machinery; pick the AF form for anything new):

R1(config)# router ospfv3 1
R1(config-router)# router-id 1.1.1.1
R1(config-router)# address-family ipv6 unicast

Set the router ID explicitly. It is still a 32-bit value, and a router with no IPv4 addresses configured cannot derive one, refusing to start the process until you provide it (the error, when you finally spot it, reads "%OSPFv3: Router process 1 could not pick a router-id").

Step 4: Enable Per Interface (No network Statements)

OSPFv3 drops the network statement entirely; membership is declared on the interface, which most engineers find more legible anyway:

R1(config)# interface Ethernet0/1
R1(config-if)# ospfv3 1 ipv6 area 0
!
R1(config)# interface Loopback0
R1(config-if)# ospfv3 1 ipv6 area 0

Repeat the equivalents on R2 with router-id 2.2.2.2. Costs, priorities, and timers hang off the same interface commands (ospfv3 cost, ospfv3 priority, ospfv3 hello-interval), mirroring their v2 counterparts.

Step 5: Verify the Adjacency and Routes

R1# show ospfv3 neighbor

          OSPFv3 1 address-family ipv6 (router-id 1.1.1.1)

Neighbor ID     Pri   State           Dead Time   Interface ID    Interface
2.2.2.2           1   FULL/DR         00:00:35    1               Ethernet0/1

Same states, same DR/BDR election as v2 (expect ~40 seconds of 2WAY/DROTHER during election on a fresh Ethernet segment before declaring anything broken). The routing table shows the v3 signature, link-local next hops:

R1# show ipv6 route ospf
O   2001:DB8::2/128 [110/10]
     via FE80::A8BB:CCFF:FE00:1C00, Ethernet0/1
O   2001:DB8:23::/64 [110/20]
     via FE80::A8BB:CCFF:FE00:1C00, Ethernet0/1

R1# ping 2001:db8::4
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/4/9 ms

(That last ping crosses a redistribution boundary into an EIGRPv6 domain; the OE2 externals it rides are covered in the redistribution guide.)

Step 6: The IPv4 Address Family (Yes, Really)

The same OSPFv3 process can carry IPv4 prefixes (RFC 5838 address families). The catch that stops most first attempts: the transport is still IPv6 link-local, so the interface needs an IPv6 presence even if it will only ever advertise IPv4 routes. On our second R1-R2 link:

R1(config)# router ospfv3 1
R1(config-router)# address-family ipv4 unicast
R1(config-router-af)# exit
R1(config-router)# exit
R1(config)# interface Ethernet0/2
R1(config-if)# ipv6 enable
R1(config-if)# ospfv3 1 ipv4 area 0

Mirror it on R2, and the process now reports two independent adjacencies, one per family:

R1# show ospfv3 neighbor

          OSPFv3 1 address-family ipv4 (router-id 1.1.1.1)
Neighbor ID     Pri   State           Dead Time   Interface ID    Interface
2.2.2.2           1   FULL/DR         00:00:33    3               Ethernet0/2

          OSPFv3 1 address-family ipv6 (router-id 1.1.1.1)
Neighbor ID     Pri   State           Dead Time   Interface ID    Interface
2.2.2.2           1   FULL/DR         00:00:35    1               Ethernet0/1

R1# show ospfv3 interface brief
Interface    PID   Area            AF         Cost  State Nbrs F/C
Et0/2        1     0               ipv4       10    BDR   1/1
Lo0          1     0               ipv6       1     LOOP  0/0
Et0/1        1     0               ipv6       10    BDR   1/1

Each AF maintains its own LSDB and runs its own SPF. If you are also running OSPFv2 (as this lab is), remember both protocols offer IPv4 routes at AD 110; advertise a given prefix from one of them, not both, or accept that the RIB will arbitrate and your paths may surprise you during migration.

Common Failures, In the Order You Will Hit Them

Authentication, Briefly

OSPFv3 has no in-protocol password fields; IOS XE offers IPsec-based authentication per interface or per area (ospfv3 authentication ipsec spi 500 sha1 <key>, or the newer key-chain based ospfv3 authentication key-chain). Deploy it interface by interface with matched SPIs and keys on both ends; a mismatch presents as hellos sent and silently ignored, so confirm with show ospfv3 interface which reports the authentication state per link.

Tuning: The Interface Knobs You Will Actually Use

All the operational OSPF tuning you know from v2 exists as ospfv3 interface commands. Costs steer paths (ospfv3 cost 100 makes a backup link a backup); network type changes skip DR election on router-to-router Ethernet (ospfv3 network point-to-point, worth doing on every p2p link for faster adjacency and a cleaner LSDB); hello and dead intervals tighten detection (ospfv3 hello-interval 1, ospfv3 dead-interval 4), though the modern answer to fast failure detection is BFD rather than aggressive hellos:

interface Ethernet0/1
 bfd interval 300 min_rx 300 multiplier 3
 ospfv3 bfd

That pairs OSPFv3 with the same sub-second detection we measured for OSPFv2 in the BFD deep dive (0.58 seconds versus a 34 second dead timer, same mechanism, same one-liner registration). Passive interfaces work per process (passive-interface Ethernet0/0 under the AF) with the same caveat as v2: a passive interface advertises its prefix but hides hello-level problems, so keep it for true edge segments.

Multi-Area OSPFv3

Areas behave exactly as in v2, declared per interface. A branch router with a backbone uplink and a stub LAN:

interface Ethernet0/1
 ospfv3 1 ipv6 area 0
!
interface Ethernet0/3
 ospfv3 1 ipv6 area 10
!
router ospfv3 1
 address-family ipv6 unicast
  area 10 stub no-summary

Stub, totally stubby, and NSSA all exist with identical semantics; inter-area prefixes travel as type 3 Inter-Area Prefix LSAs instead of v2's summary LSAs, which changes the LSDB display but not the design rules. ABR placement, area sizing, and summarization strategy (area 10 range) carry over from your v2 instincts unchanged; the OSPF pillar covers those design fundamentals.

Dual-Stack Reality: Running v2 and v3 Together

This lab intentionally runs OSPFv2 and OSPFv3 on the same interfaces, because that is what most production dual-stack networks do for years. Operationally treat them as two networks that happen to share cables. Failure domains differ (an MTU mismatch can kill v3 adjacency while v2 stays up, since v6 path MTU behavior differs), verification differs (show ip ospf neighbor versus show ospfv3 neighbor, and nothing cross-references them), and change control should name both explicitly. A pre-change snapshot that captures both neighbor tables plus both route tables takes thirty seconds and turns "IPv6 broke sometime this month" into "IPv6 broke at 14:02 during the change".

FAQ

Do I need network statements anywhere in OSPFv3?

No, they do not exist. Interface commands are the only enablement path, which also means there is no wildcard-mask puzzle and no accidentally-matched interface: what you enabled is exactly what runs.

Can one interface join both the IPv4 and IPv6 address families?

Yes: ospfv3 1 ipv4 area 0 and ospfv3 1 ipv6 area 0 stack on the same interface, forming one adjacency per family over the shared link-local transport.

Why does show ipv6 ospf still work?

It aliases into the same OSPFv3 machinery for the IPv6 AF (legacy command lineage). Standardize on the show ospfv3 forms, which display all address families and match the config syntax.

How do I advertise a default route in OSPFv3?

Same as v2: default-information originate (optionally always) under the relevant address family on the router that owns egress.

Key Takeaways

The OSPFv3 build order that avoids every classic trap: enable ipv6 unicast-routing, address the interfaces (or ipv6 enable for link-local only), create router ospfv3 with an explicit router ID and address family, then join interfaces with ospfv3 1 ipv6 area 0. There are no network statements; everything is interface-scoped. The IPv4 AF works the same way and still requires IPv6 link-local transport. Verify with show ospfv3 neighbor, show ospfv3 interface brief, and show ipv6 route ospf, and expect FE80:: next hops everywhere. Theory and LSA details live in OSPFv3 Explained; the wider protocol family is mapped in the OSPF pillar and the IP Routing cluster.