Skip to content
Log in Sign up My account

1.10.a OSPFv2, OSPFv3 and Address Families

Blueprint 1.10.a: Troubleshoot OSPF (v2/v3): Address families (IPv4, IPv6)

  • OSPFv2 for IPv4 and how it differs from OSPFv3
  • OSPFv3 in its two configuration styles: legacy ipv6 router ospf and router ospfv3 with address families
  • The OSPFv3 IPv4 address family (RFC 5838): why it still needs IPv6 on every link
  • Instance IDs, router IDs and the show commands that separate one address family from another
  • The failure symptoms that are unique to OSPFv3

ENARSI treats OSPFv2 and OSPFv3 as one topic with two transport stacks. Almost everything you learn about adjacency, areas and path selection carries over unchanged. What changes is how the protocol is enabled, how packets are addressed, how prefixes are carried in the LSDB and how authentication is done. Those differences are exactly where the exam hides faults, so this page concentrates on them.

OSPFv2 versus OSPFv3

Property OSPFv2 OSPFv3
Defined in RFC 2328 RFC 5340, address families in RFC 5838
Runs over IPv4, IP protocol 89 IPv6, next header 89
Routes carried IPv4 only IPv6, and IPv4 with the IPv4 address family
All-routers multicast 224.0.0.5 FF02::5
DR/BDR multicast 224.0.0.6 FF02::6
Packet source address Interface primary IPv4 address Interface IPv6 link-local address
Next hop in the RIB Neighbor IPv4 address Neighbor link-local address (IPv6 AF), neighbor IPv4 address (IPv4 AF)
Enabled by network statement or ip ospf <pid> area <a> Interface command only (ospfv3 <pid> ipv6 area <a> or ipv6 ospf <pid> area <a>)
Router ID 32-bit, dotted decimal 32-bit, dotted decimal (still chosen from IPv4 addresses)
Neighbor identified by IP address on broadcast/NBMA, RID on point-to-point Always the router ID
Subnet and mask check in hellos Yes, except on point-to-point links No, hellos carry no prefix information
Authentication In the OSPF header (null, plain text, MD5, HMAC-SHA) No header fields: IPsec AH/ESP, or the authentication trailer (RFC 7166)
Multiple instances per link No Yes, using the Instance ID field
Prefixes stored in Type 1 and Type 2 LSAs New Type 9 Intra-Area-Prefix LSA; Type 1 and 2 carry topology only
Administrative distance 110 110

The router ID point is the one that catches people. OSPFv3 carries IPv6 routes, but its router ID is still a 32-bit number. If the router has no IPv4 address on any interface, the process cannot pick one and does not start until you configure router-id by hand.

LSA names in OSPFv3

The LSA type numbers you know from OSPFv2 survive in OSPFv3 with new names, plus two new types. You will see the OSPFv3 names in show ospfv3 database.

OSPFv2 OSPFv3 equivalent Function code shown Scope
Type 1 Router Router LSA 0x2001 Area
Type 2 Network Network LSA 0x2002 Area
Type 3 Summary Inter-Area Prefix LSA 0x2003 Area
Type 4 ASBR Summary Inter-Area Router LSA 0x2004 Area
Type 5 External AS-External LSA 0x4005 AS
Type 7 NSSA Type-7 (NSSA) LSA 0x2007 Area
(none) Link LSA, Type 8 0x0008 Link-local
(none) Intra-Area Prefix LSA, Type 9 0x2009 Area

The Link LSA tells neighbors on one link the router's link-local address and the prefixes configured on that link. The Intra-Area Prefix LSA carries the prefixes that OSPFv2 used to embed in Type 1 and Type 2 LSAs. Separating topology from addressing means a prefix change no longer triggers a full SPF run, only a partial calculation.

Two ways to configure OSPFv3

IOS XE accepts two styles. Both produce OSPFv3 packets on the wire and they interoperate.

ipv6 unicast-routing
!
router ospfv3 1
 router-id 10.255.255.1
 !
 address-family ipv6 unicast
  passive-interface Loopback0
 exit-address-family
 !
 address-family ipv4 unicast
  passive-interface Loopback0
 exit-address-family
!
interface GigabitEthernet0/1
 ip address 10.1.12.1 255.255.255.252
 ipv6 address 2001:db8:1:2::1/64
 ospfv3 1 ipv6 area 0
 ospfv3 1 ipv4 area 0
 ospfv3 network point-to-point

ipv6 unicast-routing
!
ipv6 router ospf 1
 router-id 10.255.255.1
 passive-interface Loopback0
!
interface GigabitEthernet0/1
 ipv6 address 2001:db8:1:2::1/64
 ipv6 ospf 1 area 0
 ipv6 ospf network point-to-point

The legacy ipv6 router ospf process can only carry IPv6. To carry IPv4 inside OSPFv3 you must use router ospfv3 and the IPv4 address family. Settings placed directly under router ospfv3 1 (outside an address family), such as router-id or area 1 stub, apply to both address families. Settings inside an address family apply only to that one. Interface commands written as ospfv3 <option> apply to every address family on the interface, while ospfv3 1 ipv4 <option> or ospfv3 1 ipv6 <option> narrows them.

Exam trap

OSPFv3 has no network command. If an exhibit shows network 10.1.12.0 0.0.0.3 area 0 under router ospfv3, the parser rejects it and that interface is not in OSPF. Every OSPFv3 interface needs its own ospfv3 <pid> {ipv4|ipv6} area <a> (or ipv6 ospf <pid> area <a>) command.

The IPv4 address family

RFC 5838 lets OSPFv3 carry IPv4 prefixes. Each address family runs as a separate OSPFv3 instance, identified by the Instance ID field in the OSPFv3 header:

Address family Instance ID range IOS XE default
IPv6 unicast 0 to 31 0
IPv4 unicast 64 to 95 64

Because they are separate instances, each address family has its own neighbor table, its own LSDB and its own SPF run. A neighbor can be FULL in the IPv6 address family and missing from the IPv4 address family at the same time. Treat them as two protocols that happen to share a configuration block.

The IPv4 address family still runs over IPv6. Hellos for the IPv4 instance are sent from the interface link-local address to FF02::5. That gives two hard requirements:

  1. ipv6 unicast-routing must be configured globally.
  2. Every interface in the IPv4 address family must have IPv6 enabled, so that it has a link-local address. An IPv6 global address does this automatically; ipv6 enable is enough on an IPv4-only link.

The IPv4 next hop for routes learned through the IPv4 address family is the neighbor's IPv4 interface address, which OSPFv3 learns from the neighbor's Link LSA. Routes appear in show ip route with the normal O, O IA, O E1 and O E2 codes and AD 110.

Exam trap

An OSPFv3 interface with an IPv4 address and no IPv6 address never sends a hello for the IPv4 address family. Nothing in show ip interface brief looks wrong. The clue is show ospfv3 interface reporting no link-local address, or the interface missing from the IPv4 section of show ospfv3 interface brief. The fix is ipv6 enable (plus ipv6 unicast-routing if that is missing too).

Instance IDs on the wire

You can run more than one instance of the same address family on a link with ospfv3 1 ipv6 area 0 instance 1. Neighbors only accept hellos with their own instance ID, so a mismatch means the routers ignore each other silently. Nothing appears in show ospfv3 neighbor and the hello counters keep increasing on both sides. On the exam, if one router shows Instance ID 1 and the other Instance ID 0 in show ospfv3 interface, that is the fault.

Verification

Neighbors per address family

R1# show ospfv3 neighbor

          OSPFv3 1 address-family ipv4 (router-id 10.255.255.1)

Neighbor ID     Pri   State           Dead Time   Interface ID    Interface
10.255.255.2      0   FULL/  -        00:00:36    4               GigabitEthernet0/1

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

Neighbor ID     Pri   State           Dead Time   Interface ID    Interface
10.255.255.2      0   FULL/  -        00:00:31    4               GigabitEthernet0/1
10.255.255.3      0   FULL/  -        00:00:39    5               GigabitEthernet0/2

Read it address family by address family. Here R3 is a neighbor in the IPv6 address family only. Either R3 has no IPv4 address family on that link, or R1's Gi0/2 is not in the IPv4 address family. Notice the column Interface ID where OSPFv2 shows the neighbor's IP address. OSPFv3 neighbors are always identified by router ID.

Interface detail

R1# show ospfv3 interface GigabitEthernet0/1
GigabitEthernet0/1 is up, line protocol is up
  Link Local Address FE80::1, Interface ID 4
  Internet Address 10.1.12.1/30
  Area 0, Process ID 1, Instance ID 64, Router ID 10.255.255.1
  Network Type POINT_TO_POINT, Cost: 1
  Transmit Delay is 1 sec, State POINT_TO_POINT
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
  Neighbor Count is 1, Adjacent neighbor count is 1
    Adjacent with neighbor 10.255.255.2

The output repeats for each address family the interface belongs to. Check four things: the link-local address exists, the instance ID matches the neighbor, the area matches, and the network type and timers match.

Process and routes

R1# show ospfv3 | include address-family|Router ID|area border|boundary
 OSPFv3 1 address-family ipv4
 Router ID 10.255.255.1
 OSPFv3 1 address-family ipv6
 Router ID 10.255.255.1

R1# show ipv6 route ospf
O   2001:DB8:2:3::/64 [110/2]
     via FE80::2, GigabitEthernet0/1
OI  2001:DB8:4:4::/64 [110/3]
     via FE80::2, GigabitEthernet0/1

R1# show ip route | include ^O
O        10.2.3.0/30 [110/2] via 10.1.12.2, 00:04:10, GigabitEthernet0/1

IPv6 OSPF routes use the codes O, OI, OE1, OE2, ON1 and ON2, and always point to a link-local next hop. If you see a global unicast next hop on an OSPFv3 route, something else (a static route or another protocol) installed it.

Failure symptoms unique to OSPFv3

graph TB
  S["OSPFv3 neighbor missing"] --> Q1{"Router ID set or IPv4 address present?"}
  Q1 -->|"No"| F1["NORTRID: process not running"]
  Q1 -->|"Yes"| Q2{"ipv6 unicast-routing and link-local on interface?"}
  Q2 -->|"No"| F2["No hellos sent"]
  Q2 -->|"Yes"| Q3{"Interface in this address family?"}
  Q3 -->|"No"| F3["Add ospfv3 pid ipv4 or ipv6 area"]
  Q3 -->|"Yes"| Q4{"Instance ID, area, timers, stub flag, auth match?"}
  Q4 -->|"No"| F4["Fix the mismatch"]
  Q4 -->|"Yes"| F5["Check ACL, passive-interface, MTU like OSPFv2"]
Symptom Likely cause Proof
%OSPFv3-4-NORTRID log, no neighbors at all No IPv4 address on the router and no router-id show ospfv3 shows no router ID
IPv6 neighbor FULL, IPv4 neighbor missing on the same link Interface not in the IPv4 address family on one side, or IPv4 AF passive show ospfv3 interface brief
No neighbors in either address family on an IPv4-only link No IPv6 on the interface, so no link-local source show ipv6 interface brief shows the interface unassigned
Both routers send hellos, neither sees the other Instance ID mismatch show ospfv3 interface, compare Instance ID
Neighbor up, but IPv6 prefixes on the link not advertised Prefix missing on the interface, or ipv6 address with the wrong prefix length show ospfv3 database prefix
Routers with different global prefixes on the link still become FULL Normal. OSPFv3 does not check the subnet, only the link show ospfv3 neighbor
OSPFv3 IPsec authentication configured, neighbor never appears SPI or key mismatch, or no crypto image show crypto ipsec sa, see the authentication page

Exam trap

Two routers on the same link with global addresses 2001:db8:1:2::1/64 and 2001:db8:9:9::2/64 still become FULL in OSPFv3. Hellos use link-local addresses and carry no prefix. Each router advertises its own /64, both prefixes appear in the LSDB, and the misaddressing shows up only as a reachability problem later. Do not rule out a misaddressed link just because the adjacency is FULL.

Mixing OSPFv2 and the OSPFv3 IPv4 address family

You can run OSPFv2 and the OSPFv3 IPv4 address family on the same router. They are completely separate routing processes with separate databases. If both learn the same IPv4 prefix, both offer it to the RIB at AD 110 and the lower metric wins. This is legal but confusing, and a migration that runs both can produce odd path choices. The clean design is one protocol per address family per link. When troubleshooting, show ip protocols lists every running process and is the fastest way to see that two are active.

Lab: dual-stack OSPFv3 break/fix

Topology: three IOSv routers in a line. R1 and R2 run both address families. R3 also runs both address families toward R2.

graph LR
  R1["R1<br/>Lo0 10.255.255.1"] -- "Gi0/1 10.1.2.0/30<br/>2001:db8:1:2::/64" --- R2["R2<br/>Lo0 10.255.255.2"]
  R2 -- "Gi0/2 10.2.3.0/30<br/>2001:db8:2:3::/64" --- R3["R3<br/>Lo0 10.255.255.3"]

Baseline (R2 shown; R1 and R3 mirror it)

hostname R2
ipv6 unicast-routing
!
interface Loopback0
 ip address 10.255.255.2 255.255.255.255
 ipv6 address 2001:db8:ffff::2/128
 ospfv3 1 ipv4 area 0
 ospfv3 1 ipv6 area 0
!
interface GigabitEthernet0/1
 ip address 10.1.2.2 255.255.255.252
 ipv6 address 2001:db8:1:2::2/64
 ospfv3 network point-to-point
 ospfv3 1 ipv4 area 0
 ospfv3 1 ipv6 area 0
 no shutdown
!
interface GigabitEthernet0/2
 ip address 10.2.3.2 255.255.255.252
 ipv6 address 2001:db8:2:3::2/64
 ospfv3 network point-to-point
 ospfv3 1 ipv4 area 0
 ospfv3 1 ipv6 area 0
 no shutdown
!
router ospfv3 1
 router-id 10.255.255.2
 address-family ipv4 unicast
 exit-address-family
 address-family ipv6 unicast
 exit-address-family

Verify: on R2, show ospfv3 neighbor lists R1 and R3 in both address families. On R1, show ip route 10.255.255.3 and show ipv6 route 2001:db8:ffff::3 both return OSPF routes. Save with copy run flash:ospfv3-base.cfg.

Tickets

Have a lab partner (or a script) apply one fault at a time. Diagnose from show output before you look at the configuration.

  1. R3 IPv4 loopback unreachable, IPv6 fine. Fault: on R3 Gi0/0, remove ospfv3 1 ipv4 area 0. Expected evidence: R2 show ospfv3 neighbor shows R3 only under address-family ipv6. Fix: re-add the interface command.
  2. Everything to R3 fails after an "IPv6 clean-up". Fault: on R3 Gi0/0, no ipv6 address (removes the link-local too). Expected evidence: R3 has no OSPFv3 neighbors in either address family, show ospfv3 interface Gi0/0 reports no link-local address. Fix: restore the IPv6 address or add ipv6 enable.
  3. New router R3 never joins. Fault: on R3, remove router-id and remove every IPv4 address (Lo0 and Gi0/0). Expected evidence: the console logs %OSPFv3-4-NORTRID. Fix: router ospfv3 1 then router-id 10.255.255.3, then clear ospfv3 process.
  4. Hellos sent, nobody listens. Fault: on R2 Gi0/2, change to ospfv3 1 ipv6 area 0 instance 1. Expected evidence: show ospfv3 interface Gi0/2 on R2 shows Instance ID 1, R3 shows Instance ID 0, and no IPv6 neighbor forms. Fix: remove the instance keyword.
  5. Global unicast reachability broken but adjacency FULL. Fault: on R3, change Gi0/0 to 2001:db8:3:2::2/64. Expected evidence: neighbor FULL, but R1 cannot ping 2001:db8:2:3::2 and show ipv6 route on R1 now has two /64s for the link. Fix: correct the address.

After each fix, rerun the baseline verification. Write the single show command that would have found the fault fastest. That list is your exam toolkit.

Quick check

A router runs router ospfv3 1 with only address-family ipv4 unicast. Its interfaces have IPv4 addresses only. Why are there no neighbors?

OSPFv3 runs over IPv6 even for the IPv4 address family. Hellos are sourced from the IPv6 link-local address, so ipv6 unicast-routing must be enabled and each interface needs IPv6 enabled (ipv6 enable is enough).

Which instance ID does IOS XE use by default for the OSPFv3 IPv4 address family, and why does it matter?
  1. The IPv6 address family uses 0 by default. Each address family is a separate instance with its own neighbors and LSDB, and neighbors only accept hellos with a matching instance ID.
OSPFv3 on an IPv6-only router logs NORTRID. What is the fix?

Configure router-id x.x.x.x under router ospfv3 (or ipv6 router ospf). The router ID is a 32-bit value that is normally taken from an IPv4 address, and this router has none.

References