IPv6 Routing — OSPFv3 & EIGRPv6 Configuration, Adjacency & Verification

IPv6 does not simply bolt onto existing IPv4 routing protocols — it requires dedicated protocol versions rebuilt from the ground up to handle 128-bit addresses, link-local next-hops, and IPv6-native multicast. OSPFv3 is not merely OSPF with larger address fields. It was redesigned to be address-family agnostic: the same OSPFv3 process can carry both IPv6 and IPv4 topology information simultaneously using address-family containers. The fundamental algorithmic core (Dijkstra SPF, LSA flooding, area hierarchy) is identical to OSPFv2 — but the configuration model, the LSA types, the authentication mechanism, and the neighbour discovery method are all different.

EIGRPv6 undergoes an equally significant evolution. The classic router eigrp [asn] model with network statements is replaced — or supplemented — by the named EIGRP mode, which provides a unified configuration hierarchy for both IPv4 and IPv6 address families under a single named EIGRP process. EIGRPv6 uses IPv6 link-local addresses as next-hops (just like OSPFv3), which means the IPv6 routing table shows link-local next-hops alongside the specific interface — a combination that confuses engineers who expect to see global unicast next-hops.

This lab walks through the complete IPv6 routing setup: enabling ipv6 unicast-routing, assigning global unicast and link-local addresses, configuring OSPFv3 using both the classic interface-level method and the address-family method, configuring EIGRPv6 in named mode, verifying neighbour adjacency, and interpreting the IPv6 routing table. For IPv6 address fundamentals see IPv6 Basic Configuration. For the IPv4 equivalents of these protocols see OSPF Multi-Area Configuration and EIGRP Configuration. For IPv6 summarization and prefix aggregation see Route Summarization & Aggregation.

1. Core Concepts — IPv6 Routing Protocol Differences

OSPFv2 vs OSPFv3 — Key Differences

Feature	OSPFv2 (IPv4)	OSPFv3 (IPv6)
RFC	RFC 2328	RFC 5340
Address family	IPv4 only	Originally IPv6; extended to carry both AF (address families) via RFC 5838
Network statements	`network [prefix] [wildcard] area [n]` under router process	No network statements — interfaces are enabled directly with `ipv6 ospf [pid] area [n]`
Neighbour discovery	Uses interface's IPv4 address for Hello sourcing	Uses IPv6 link-local address — global unicast not required for neighbour formation
Next-hop in routing table	Global unicast or directly connected IPv4 next-hop	IPv6 link-local next-hop — shown as `FE80::/10` address via interface
Router ID	Highest loopback IP or highest active interface IP (IPv4)	Must be configured manually if no IPv4 addresses exist — OSPFv3 RID is still a 32-bit dotted-decimal value
Authentication	Built-in MD5 or plain text via `ip ospf authentication`	Uses IPsec AH/ESP on the interface — `ipv6 ospf authentication ipsec`
LSA types added	Types 1–5 (plus 7 for NSSA) — see OSPF Areas & LSAs	New: Type 8 (Link LSA — link-local address + on-link prefixes) and Type 9 (Intra-Area Prefix LSA — replaces address info stripped from Type 1/2)
Address info in LSAs	IPv4 prefixes embedded in Router and Network LSAs (Type 1/2)	Prefix information separated into Type 8/9 LSAs — Type 1/2 carry only topology (no addresses)
Configuration model	Process-centric: `router ospf [pid]` with network statements	Interface-centric (classic) or address-family mode (modern)

EIGRPv4 vs EIGRPv6 — Key Differences

Feature	EIGRPv4 (Classic)	EIGRPv6 / Named Mode
Process activation	`router eigrp [asn]` + `network` statements	Classic: `ipv6 router eigrp [asn]` + `ipv6 eigrp [asn]` on each interface. Named: `router eigrp [name]` with `address-family ipv6`
Shutdown behaviour	Active by default	Classic EIGRPv6: requires `no shutdown` under `ipv6 router eigrp` — shutdown by default
Next-hop	Global unicast IPv4	IPv6 link-local — displayed as `FE80::xx` via interface in routing table
Multicast address	224.0.0.10	FF02::A (all EIGRP routers multicast)
Router ID	Highest loopback or interface IPv4	Same 32-bit dotted-decimal RID — manually configured if no IPv4 addresses
Auto-summary	IOS 12.x: on by default. IOS 15.x: off by default	Not applicable — IPv6 has no classful boundaries
Named mode advantage	N/A	Single process for both IPv4 and IPv6; consistent configuration hierarchy; supports advanced features (wide metrics, add-paths)

Link-Local Next-Hops — Why They Appear in the IPv6 Routing Table

  IPv6 routing protocols (OSPFv3, EIGRPv6, RIPng) use LINK-LOCAL addresses
  (FE80::/10) as the source and next-hop for routing protocol messages.

  WHY LINK-LOCAL:
    Link-local addresses are automatically generated on every IPv6-enabled
    interface — they exist even if no global unicast address is configured.
    This means two routers can form OSPF or EIGRP adjacency using only
    link-local addresses, with no global unicast addresses needed on the
    transit link (common for point-to-point WAN links).

  WHAT THIS MEANS IN THE ROUTING TABLE:
    show ipv6 route will show entries like:
    O  2001:DB8:1::/48 [110/2]
         via FE80::1, GigabitEthernet0/0

    The next-hop is a link-local address (FE80::1) — it is ONLY meaningful
    in the context of the specified interface (Gi0/0).
    FE80::1 on Gi0/0 and FE80::1 on Gi0/1 are DIFFERENT next-hops.
    The interface is MANDATORY — the routing table always shows both.

  WHY NOT GLOBAL UNICAST NEXT-HOPS:
    When OSPFv3/EIGRPv6 sends updates, the source address is the
    link-local address. The receiving router learns the neighbour's
    link-local address and uses it as the next-hop in the routing table.
    Global unicast addresses are advertised as PREFIXES to reach,
    not as next-hops to forward through.

Router ID requirement for OSPFv3 and EIGRPv6: Both OSPFv3 and EIGRPv6 require a 32-bit Router ID in dotted-decimal format — the same as their IPv4 counterparts. If the router has IPv4 addresses configured, the RID is auto-selected (highest loopback, then highest active interface). In an IPv6-only router with no IPv4 addresses at all, the RID cannot be auto-selected — the process will not start. You must explicitly configure router-id [x.x.x.x] under the routing process. Best practice: always configure explicit Router IDs using loopback-style addresses (e.g., 1.1.1.1, 2.2.2.2) for unambiguous identification. For IPv6 address type fundamentals including link-local vs global unicast, see IPv6 Link-Local vs Global Addresses and IPv6 Neighbour Discovery.

2. Lab Topology

                    ┌──────────────────────────────────────────────────┐
                    │               OSPFv3 Area 0 (Backbone)           │
                    │                                                  │
    OSPF Area 1     │  NetsTuts_R1                NetsTuts_R2          │  OSPF Area 2
    EIGRPv6 AS 100  │  RID: 1.1.1.1               RID: 2.2.2.2        │  EIGRPv6 AS 100
                    │  Lo0: 2001:DB8:0:1::1/128   Lo0: 2001:DB8:0:2::2/128
                    │                                                  │
       ┌────────────┤  Gi0/0                      Gi0/0  ├────────────┐
       │            │  2001:DB8:10:12::1/64        2001:DB8:10:12::2/64
       │            │  Link-local: FE80::1         Link-local: FE80::2│
       │            └──────────────────────────────────────────────────┘
       │                         (Area 0 backbone link)
       │
  NetsTuts_R1                                          NetsTuts_R2
  Gi0/1: 2001:DB8:10:1::1/64 (Area 1)       Gi0/1: 2001:DB8:10:2::2/64 (Area 2)
  Gi0/2: 2001:DB8:10:3::1/64 (EIGRP AS100)  Gi0/2: 2001:DB8:10:4::2/64 (EIGRP AS100)
  Lo1:   2001:DB8:1::/48 (Area 1 prefix)    Lo1:   2001:DB8:2::/48 (Area 2 prefix)

                    ┌──────────────────────────────────────────────────┐
                    │                NetsTuts_R3                       │
                    │                RID: 3.3.3.3                      │
                    │  Gi0/0: 2001:DB8:10:3::3/64 (EIGRP link to R1)  │
                    │  Gi0/1: 2001:DB8:10:4::3/64 (EIGRP link to R2)  │
                    │  Lo0:   2001:DB8:0:3::3/128                      │
                    │  Lo1:   2001:DB8:3::/48 (EIGRP-only prefix)     │
                    └──────────────────────────────────────────────────┘

  ROUTING DESIGN:
    OSPFv3:  R1 ↔ R2 in Area 0; R1 has Area 1 stub; R2 has Area 2 stub
    EIGRPv6: R1 ↔ R3 ↔ R2 triangle; R3 loopback advertised via EIGRP
    Both protocols run simultaneously; redistribution optional

3. Step 1 — Enable IPv6 Routing and Assign Addresses

Global IPv6 Routing Enable (All Routers)

! ── MUST be done before any IPv6 routing protocol works ─────────
! ── Default state: IPv6 unicast routing is DISABLED on Cisco IOS ─

NetsTuts_R1(config)#ipv6 unicast-routing
!                   ^^^^^^^^^^^^^^^^^^^^
!    Enables IPv6 packet forwarding between interfaces.
!    Without this, the router processes IPv6 traffic addressed
!    TO ITSELF but does NOT forward IPv6 packets between interfaces.
!    This is the single most common reason IPv6 routing fails.

! ── Verify it is enabled ─────────────────────────────────────────
NetsTuts_R1#show ipv6 cef
! If CEF shows prefixes, ipv6 unicast-routing is on.
! If "IPv6 CEF is not running" → ipv6 unicast-routing not configured.

Interface Address Assignment — R1

! ── Configure global unicast addresses and explicit link-locals ──
NetsTuts_R1(config)#interface Loopback0
NetsTuts_R1(config-if)#ipv6 address 2001:DB8:0:1::1/128
NetsTuts_R1(config-if)#exit

NetsTuts_R1(config)#interface Loopback1
NetsTuts_R1(config-if)#ipv6 address 2001:DB8:1::/48
!                                    ^^^^^^^^^^^^^^
!    Loopback with /48 — advertised as an OSPFv3 prefix into Area 1
NetsTuts_R1(config-if)#exit

NetsTuts_R1(config)#interface GigabitEthernet0/0
NetsTuts_R1(config-if)#description R1-to-R2-Area0-backbone
NetsTuts_R1(config-if)#ipv6 address 2001:DB8:10:12::1/64
NetsTuts_R1(config-if)#ipv6 address FE80::1 link-local
!                                    ^^^^^^^
!    Explicit link-local — simplifies verification and troubleshooting.
!    Default EUI-64 link-locals are long and hard to type in pings.
NetsTuts_R1(config-if)#no shutdown
NetsTuts_R1(config-if)#exit

NetsTuts_R1(config)#interface GigabitEthernet0/1
NetsTuts_R1(config-if)#description R1-Area1-stub-segment
NetsTuts_R1(config-if)#ipv6 address 2001:DB8:10:1::1/64
NetsTuts_R1(config-if)#ipv6 address FE80::1 link-local
NetsTuts_R1(config-if)#no shutdown
NetsTuts_R1(config-if)#exit

NetsTuts_R1(config)#interface GigabitEthernet0/2
NetsTuts_R1(config-if)#description R1-to-R3-EIGRPv6
NetsTuts_R1(config-if)#ipv6 address 2001:DB8:10:3::1/64
NetsTuts_R1(config-if)#ipv6 address FE80::1 link-local
NetsTuts_R1(config-if)#no shutdown
NetsTuts_R1(config-if)#exit

Interface Address Assignment — R2

NetsTuts_R2(config)#ipv6 unicast-routing
NetsTuts_R2(config)#interface Loopback0
NetsTuts_R2(config-if)#ipv6 address 2001:DB8:0:2::2/128
NetsTuts_R2(config-if)#exit

NetsTuts_R2(config)#interface Loopback1
NetsTuts_R2(config-if)#ipv6 address 2001:DB8:2::/48
NetsTuts_R2(config-if)#exit

NetsTuts_R2(config)#interface GigabitEthernet0/0
NetsTuts_R2(config-if)#description R2-to-R1-Area0-backbone
NetsTuts_R2(config-if)#ipv6 address 2001:DB8:10:12::2/64
NetsTuts_R2(config-if)#ipv6 address FE80::2 link-local
NetsTuts_R2(config-if)#no shutdown
NetsTuts_R2(config-if)#exit

NetsTuts_R2(config)#interface GigabitEthernet0/1
NetsTuts_R2(config-if)#description R2-Area2-stub-segment
NetsTuts_R2(config-if)#ipv6 address 2001:DB8:10:2::2/64
NetsTuts_R2(config-if)#ipv6 address FE80::2 link-local
NetsTuts_R2(config-if)#no shutdown
NetsTuts_R2(config-if)#exit

NetsTuts_R2(config)#interface GigabitEthernet0/2
NetsTuts_R2(config-if)#description R2-to-R3-EIGRPv6
NetsTuts_R2(config-if)#ipv6 address 2001:DB8:10:4::2/64
NetsTuts_R2(config-if)#ipv6 address FE80::2 link-local
NetsTuts_R2(config-if)#no shutdown
NetsTuts_R2(config-if)#exit

Interface Address Assignment — R3

NetsTuts_R3(config)#ipv6 unicast-routing
NetsTuts_R3(config)#interface Loopback0
NetsTuts_R3(config-if)#ipv6 address 2001:DB8:0:3::3/128
NetsTuts_R3(config-if)#exit

NetsTuts_R3(config)#interface Loopback1
NetsTuts_R3(config-if)#ipv6 address 2001:DB8:3::/48
NetsTuts_R3(config-if)#exit

NetsTuts_R3(config)#interface GigabitEthernet0/0
NetsTuts_R3(config-if)#description R3-to-R1-EIGRPv6
NetsTuts_R3(config-if)#ipv6 address 2001:DB8:10:3::3/64
NetsTuts_R3(config-if)#ipv6 address FE80::3 link-local
NetsTuts_R3(config-if)#no shutdown
NetsTuts_R3(config-if)#exit

NetsTuts_R3(config)#interface GigabitEthernet0/1
NetsTuts_R3(config-if)#description R3-to-R2-EIGRPv6
NetsTuts_R3(config-if)#ipv6 address 2001:DB8:10:4::3/64
NetsTuts_R3(config-if)#ipv6 address FE80::3 link-local
NetsTuts_R3(config-if)#no shutdown
NetsTuts_R3(config-if)#exit

! ── Verify address assignment ────────────────────────────────────
NetsTuts_R1#show ipv6 interface brief
GigabitEthernet0/0     [up/up]
    FE80::1                                ← link-local (explicit)
    2001:DB8:10:12::1                      ← global unicast
GigabitEthernet0/1     [up/up]
    FE80::1
    2001:DB8:10:1::1
GigabitEthernet0/2     [up/up]
    FE80::1
    2001:DB8:10:3::1
Loopback0              [up/up]
    2001:DB8:0:1::1
Loopback1              [up/up]
    2001:DB8:1::

Configuring explicit link-local addresses (FE80::1, FE80::2, FE80::3) rather than relying on EUI-64 auto-generated ones is strongly recommended in lab and production environments. EUI-64 link-locals are derived from the interface MAC address and look like FE80::20C:29FF:FE3A:7B1C — difficult to type in ping commands, hard to memorise, and different on every platform. Explicit link-locals are predictable, easy to document, and the same across physical router replacement. The same explicit link-local (FE80::1) can be reused on multiple interfaces of the same router — link-locals are only unique per-link, so FE80::1 on Gi0/0 and FE80::1 on Gi0/1 are completely independent addresses.

4. Step 2 — OSPFv3 Configuration (Classic Interface Method)

The classic OSPFv3 configuration method activates OSPFv3 directly on each interface using the ipv6 ospf [process-id] area [area-id] command. There are no network statements. Each interface is individually assigned to a process and area. This is the most direct method and maps cleanly to per-interface control.

R1 — OSPFv3 Process and Interface Assignment

! ── Step 1: Create the OSPFv3 process and set Router ID ──────────
NetsTuts_R1(config)#ipv6 router ospf 1
!                   ^^^^^^^^^^^^^^^^
!    'ipv6 router ospf' creates the OSPFv3 process
!    Process ID 1 — local significance only (same as OSPFv2)

NetsTuts_R1(config-rtr)#router-id 1.1.1.1
!                        ^^^^^^^^^^^^^^^^
!    32-bit RID in dotted-decimal — MANDATORY if no IPv4 addresses
!    Best practice: always configure explicitly

NetsTuts_R1(config-rtr)#exit

! ── Step 2: Assign interfaces to OSPFv3 areas ────────────────────
! ── Note: done under the INTERFACE, not under the router process ──

NetsTuts_R1(config)#interface GigabitEthernet0/0
NetsTuts_R1(config-if)#ipv6 ospf 1 area 0
!                       ^^^^^^ ^ ^^^^^^
!                    command pid  area backbone
!                    ↑ This activates OSPFv3 on this interface

NetsTuts_R1(config-if)#exit

NetsTuts_R1(config)#interface GigabitEthernet0/1
NetsTuts_R1(config-if)#ipv6 ospf 1 area 1
!                                    ^^^^
!                              Area 1 — stub area for branch segment
NetsTuts_R1(config-if)#exit

NetsTuts_R1(config)#interface Loopback0
NetsTuts_R1(config-if)#ipv6 ospf 1 area 0
!                                    area 0 — loopback in backbone
NetsTuts_R1(config-if)#exit

NetsTuts_R1(config)#interface Loopback1
NetsTuts_R1(config-if)#ipv6 ospf 1 area 1
!                                    area 1 — branch prefix in area 1
NetsTuts_R1(config-if)#exit

! ── Optional: set OSPFv3 interface cost ──────────────────────────
NetsTuts_R1(config)#interface GigabitEthernet0/0
NetsTuts_R1(config-if)#ipv6 ospf cost 10
NetsTuts_R1(config-if)#exit

! ── Optional: passive interface (no Hellos on stub LAN) ──────────
NetsTuts_R1(config)#ipv6 router ospf 1
NetsTuts_R1(config-rtr)#passive-interface GigabitEthernet0/1
!                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
!    No OSPFv3 Hellos sent on Gi0/1 — prefix still advertised
!    Same concept as OSPFv2 passive-interface
NetsTuts_R1(config-rtr)#exit

R2 — OSPFv3 Process and Interface Assignment

NetsTuts_R2(config)#ipv6 router ospf 1
NetsTuts_R2(config-rtr)#router-id 2.2.2.2
NetsTuts_R2(config-rtr)#exit

NetsTuts_R2(config)#interface GigabitEthernet0/0
NetsTuts_R2(config-if)#ipv6 ospf 1 area 0         ! Backbone link to R1
NetsTuts_R2(config-if)#exit

NetsTuts_R2(config)#interface GigabitEthernet0/1
NetsTuts_R2(config-if)#ipv6 ospf 1 area 2         ! Area 2 stub segment
NetsTuts_R2(config-if)#exit

NetsTuts_R2(config)#interface Loopback0
NetsTuts_R2(config-if)#ipv6 ospf 1 area 0
NetsTuts_R2(config-if)#exit

NetsTuts_R2(config)#interface Loopback1
NetsTuts_R2(config-if)#ipv6 ospf 1 area 2
NetsTuts_R2(config-if)#exit

NetsTuts_R2(config)#ipv6 router ospf 1
NetsTuts_R2(config-rtr)#passive-interface GigabitEthernet0/1
NetsTuts_R2(config-rtr)#exit

R1 is an OSPFv3 ABR — it connects Area 0 (backbone via Gi0/0) and Area 1 (stub via Gi0/1). R2 is also an ABR connecting Area 0 and Area 2. The OSPFv3 process ID (1) is locally significant — both routers use process ID 1 but they could use different IDs and still form adjacency. The area IDs in the ipv6 ospf [pid] area [n] command must match between neighbours on the same link. The Router ID must be unique within the OSPF domain — using 1.1.1.1 and 2.2.2.2 makes the topology self-documenting.

5. OSPFv3 Address-Family Mode (Modern Method)

IOS 15.x introduced OSPFv3 address-family mode, which mirrors the structure of named EIGRP. A single OSPFv3 process can carry both IPv4 and IPv6 topology under separate address-family containers. This is the recommended method for new deployments and is required when running OSPFv3 for IPv4 (OSPFv3 AF mode replaces OSPFv2 when the requirement is protocol standardisation).

! ── OSPFv3 Address-Family Method (modern IOS 15.x+) ──────────────
! ── Replaces the classic 'ipv6 ospf' interface command ────────────

NetsTuts_R1(config)#router ospf 1
!                   ^^^^^^^^^^^^
!    Note: 'router ospf' (not 'ipv6 router ospf') in AF mode
!    The same process handles both IPv4 and IPv6 AFs

NetsTuts_R1(config-router)#router-id 1.1.1.1
!
! ── Define IPv6 address-family ───────────────────────────────────
NetsTuts_R1(config-router)#address-family ipv6 unicast
NetsTuts_R1(config-router-af)#area 1 range 2001:DB8:1::/48
!                                          ^^^^^^^^^^^^^^^^^^^
!              OSPFv3 IPv6 summarization — same concept as OSPFv2 area range
!              Summarizes Area 1 IPv6 prefixes into Area 0
NetsTuts_R1(config-router-af)#exit
NetsTuts_R1(config-router)#exit

! ── Assign interfaces via ospfv3 command (AF mode uses different cmd)
NetsTuts_R1(config)#interface GigabitEthernet0/0
NetsTuts_R1(config-if)#ospfv3 1 ipv6 area 0
!                      ^^^^^^^           ^^^
!               'ospfv3' keyword  address family  area
!               NOT 'ipv6 ospf' — that is the classic method

NetsTuts_R1(config)#interface GigabitEthernet0/1
NetsTuts_R1(config-if)#ospfv3 1 ipv6 area 1
NetsTuts_R1(config-if)#exit

! ── IMPORTANT: Classic and AF methods are NOT compatible ─────────
! ── Do NOT mix 'ipv6 ospf' and 'ospfv3' on the same router ───────
! ── Choose one method and use it consistently ────────────────────

! ── Dual-stack: run both IPv4 and IPv6 under one process ─────────
NetsTuts_R1(config)#interface GigabitEthernet0/0
NetsTuts_R1(config-if)#ospfv3 1 ipv4 area 0    ! IPv4 AF in OSPFv3
NetsTuts_R1(config-if)#ospfv3 1 ipv6 area 0    ! IPv6 AF in OSPFv3
NetsTuts_R1(config-if)#exit
! ← One process carries both — removes need for separate OSPFv2 process

The choice between classic (ipv6 ospf) and AF mode (ospfv3) is a design decision that affects the entire router — they cannot be mixed on the same process. For IPv6-only deployments on modern IOS, either method works. For dual-stack deployments where you want a single unified OSPF process for both address families, the AF mode is the only option. The classic method is simpler to understand and still widely used on CCNP lab exams.

6. Step 3 — EIGRPv6 Configuration (Named Mode)

Named EIGRP mode is the recommended modern approach for both IPv4 and IPv6 EIGRP. A single named process (router eigrp [name]) contains separate address-family sections for IPv4 and IPv6. Interface-level activation is handled within the af-interface sub-configuration. Named mode also unlocks advanced features unavailable in classic mode: wide metrics (64-bit), add-paths, and per-AF stub configuration.

R1 — EIGRPv6 Named Mode

! ── Named EIGRP process ──────────────────────────────────────────
NetsTuts_R1(config)#router eigrp NETSTUTS
!                                ^^^^^^^^
!    Process name — locally significant, any string

NetsTuts_R1(config-router)#address-family ipv6 unicast autonomous-system 100
!                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
!                           IPv6 address family, AS number 100
!                           (AS number must match on all EIGRP neighbours)

NetsTuts_R1(config-router-af)#eigrp router-id 1.1.1.1
!                              ^^^^^^^^^^^^^^^^^^
!    32-bit RID — mandatory if no IPv4 addresses exist

! ── Interface-level configuration ────────────────────────────────
NetsTuts_R1(config-router-af)#af-interface GigabitEthernet0/2
!                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
!    Configure EIGRP parameters for specific interface

NetsTuts_R1(config-router-af-interface)#hello-interval 5
NetsTuts_R1(config-router-af-interface)#hold-time 15
NetsTuts_R1(config-router-af-interface)#exit

! ── Passive interface (no Hellos — prefix still advertised) ──────
NetsTuts_R1(config-router-af)#af-interface Loopback1
NetsTuts_R1(config-router-af-interface)#passive-interface
NetsTuts_R1(config-router-af-interface)#exit

! ── Network statement (activate EIGRP on matching interfaces) ─────
NetsTuts_R1(config-router-af)#network 2001:DB8::/32
!                              ^^^^^^^^^^^^^^^^^^^^^^^^^
!    Activate EIGRPv6 on all interfaces with addresses in 2001:DB8::/32
!    This covers Gi0/2 (2001:DB8:10:3::/64) and Loopback1 (2001:DB8:1::/48)

NetsTuts_R1(config-router-af)#exit
NetsTuts_R1(config-router)#exit

R2 — EIGRPv6 Named Mode

NetsTuts_R2(config)#router eigrp NETSTUTS
NetsTuts_R2(config-router)#address-family ipv6 unicast autonomous-system 100
NetsTuts_R2(config-router-af)#eigrp router-id 2.2.2.2

NetsTuts_R2(config-router-af)#af-interface GigabitEthernet0/2
NetsTuts_R2(config-router-af-interface)#hello-interval 5
NetsTuts_R2(config-router-af-interface)#hold-time 15
NetsTuts_R2(config-router-af-interface)#exit

NetsTuts_R2(config-router-af)#af-interface Loopback1
NetsTuts_R2(config-router-af-interface)#passive-interface
NetsTuts_R2(config-router-af-interface)#exit

NetsTuts_R2(config-router-af)#network 2001:DB8::/32
NetsTuts_R2(config-router-af)#exit
NetsTuts_R2(config-router)#exit

R3 — EIGRPv6 Named Mode (Hub of EIGRP Triangle)

NetsTuts_R3(config)#router eigrp NETSTUTS
NetsTuts_R3(config-router)#address-family ipv6 unicast autonomous-system 100
NetsTuts_R3(config-router-af)#eigrp router-id 3.3.3.3

NetsTuts_R3(config-router-af)#af-interface GigabitEthernet0/0
NetsTuts_R3(config-router-af-interface)#hello-interval 5
NetsTuts_R3(config-router-af-interface)#hold-time 15
NetsTuts_R3(config-router-af-interface)#exit

NetsTuts_R3(config-router-af)#af-interface GigabitEthernet0/1
NetsTuts_R3(config-router-af-interface)#hello-interval 5
NetsTuts_R3(config-router-af-interface)#hold-time 15
NetsTuts_R3(config-router-af-interface)#exit

NetsTuts_R3(config-router-af)#af-interface Loopback1
NetsTuts_R3(config-router-af-interface)#passive-interface
NetsTuts_R3(config-router-af-interface)#exit

NetsTuts_R3(config-router-af)#network 2001:DB8::/32
NetsTuts_R3(config-router-af)#exit
NetsTuts_R3(config-router)#exit

Classic EIGRPv6 Method (Legacy — for reference)

! ── LEGACY method — shown for comparison / older IOS ─────────────
! ── Named mode is preferred for new deployments ──────────────────

! ── Step 1: Create the IPv6 EIGRP process ────────────────────────
NetsTuts_R1(config)#ipv6 router eigrp 100
!                   ^^^^^^^^^^^^^^^^^^^^
NetsTuts_R1(config-rtr)#eigrp router-id 1.1.1.1

! ── CRITICAL: Classic EIGRPv6 is SHUTDOWN by default ─────────────
NetsTuts_R1(config-rtr)#no shutdown
!                        ^^^^^^^^^^^
!    Without this, the EIGRP process is administratively down.
!    This is the #1 reason classic EIGRPv6 fails to form adjacency.
NetsTuts_R1(config-rtr)#exit

! ── Step 2: Activate on each interface (no network statements) ────
NetsTuts_R1(config)#interface GigabitEthernet0/2
NetsTuts_R1(config-if)#ipv6 eigrp 100
!                       ^^^^^^^^^^^^
!    Activates EIGRP AS 100 on this interface
NetsTuts_R1(config-if)#exit

NetsTuts_R1(config)#interface Loopback1
NetsTuts_R1(config-if)#ipv6 eigrp 100
NetsTuts_R1(config-if)#exit

! ── KEY DIFFERENCE FROM NAMED MODE:
!    Classic: activate per-interface with 'ipv6 eigrp [asn]'
!    Named:   activate via 'network' statement or per-interface in af-interface
!    Classic: requires 'no shutdown' under 'ipv6 router eigrp'
!    Named:   active by default when address-family is configured

7. OSPFv3 Authentication with IPsec

OSPFv3 removed the built-in authentication mechanism present in OSPFv2 and instead relies on IPv6's native security extension: IPsec. OSPFv3 authentication uses IPsec AH (Authentication Header) for integrity-only protection or IPsec ESP (Encapsulating Security Payload) for both integrity and encryption. This provides stronger security than OSPFv2's MD5 but requires more configuration.

! ── OSPFv3 AH authentication — integrity only (no encryption) ────
! ── Applied per-interface or per-area ─────────────────────────────

! ── Method 1: Per-area authentication (under ospf process) ────────
NetsTuts_R1(config)#ipv6 router ospf 1
NetsTuts_R1(config-rtr)#area 0 authentication ipsec spi 256 sha1 hex
!                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
!    AH with SHA-1, SPI 256
!    Key must be 40 hex chars for SHA-1
123456789012345678901234567890123456789A
!    ↑ 40 hex chars = 160-bit SHA-1 key
NetsTuts_R1(config-rtr)#exit

! ── Method 2: Per-interface authentication ───────────────────────
NetsTuts_R1(config)#interface GigabitEthernet0/0
NetsTuts_R1(config-if)#ipv6 ospf authentication ipsec spi 256 sha1 hex
123456789012345678901234567890123456789A
NetsTuts_R1(config-if)#exit

! ── OSPFv3 ESP encryption + authentication ────────────────────────
NetsTuts_R1(config)#interface GigabitEthernet0/0
NetsTuts_R1(config-if)#ipv6 ospf encryption ipsec spi 300 esp aes-cbc 128 hex
!                                                                  ^^^
!    AES-128 encryption
A1B2C3D4E5F60718293A4B5C6D7E8F901A2B3C4D5E6F70819293A4B5C6D7E8F9
! ↑ 32 hex chars = 128-bit AES key
!    Then add authentication (SHA-1 or MD5):
NetsTuts_R1(config-if)#ipv6 ospf encryption ipsec spi 300 esp aes-cbc 128 hex
A1B2C3D4E5F60718293A4B5C6D7E8F901A2B3C4D5E6F70819293A4B5C6D7E8F9 sha1 hex
123456789012345678901234567890123456789A
NetsTuts_R1(config-if)#exit

! ── NOTE: SPI and keys must match identically on BOTH ends ────────
! ── If they differ, OSPFv3 adjacency will not form ────────────────
! ── Verify: show crypto ipsec sa | show ipv6 ospf neighbor ────────

The SPI (Security Parameter Index) is a 32-bit number that identifies the IPsec security association. Both routers on a link must configure the same SPI value and identical keys. The SPI range 256–4294967295 is available for manual configuration. SPIs below 256 are reserved for system use. In practice, many engineers use OSPFv3 without authentication in internal networks (relying on network segmentation for security) and enable IPsec authentication only on inter-datacenter or DMZ connections.

8. Step 4 — Full Verification

OSPFv3 Neighbour Verification

! ── show ospfv3 neighbor ─────────────────────────────────────────
NetsTuts_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/BDR        00:00:33    4               GigabitEthernet0/0
!               ^^^   ^^^^            ^^^^^^^^
!     Neighbour's RID (dotted-decimal)
!                     FULL = complete adjacency
!                           DR/BDR election result on multi-access link
!                                     Time remaining before hold expires

! ── Alternate command (classic method) ────────────────────────────
NetsTuts_R1#show ipv6 ospf neighbor
! (identical output — both commands work for classic OSPFv3)

! ── Detailed neighbour output ────────────────────────────────────
NetsTuts_R1#show ospfv3 neighbor detail
Neighbor 2.2.2.2
    In the area 0 via interface GigabitEthernet0/0
    Neighbor: interface-id 4, link-local address FE80::2  ← neighbour's link-local
    Neighbor priority is 1, State is FULL, 6 state changes
    DR is 2.2.2.2 BDR is 1.1.1.1
    Options is 0x000013  -R  -E  V6-Bit
    Dead timer due in 00:00:32
    Neighbor is up for 00:08:44
    Index 1/1/1, retransmission queue length 0, number of retransmission 0
    First 0x0(0)/0x0(0)/0x0(0) Next 0x0(0)/0x0(0)/0x0(0)
    Last retransmission scan length is 0, maximum is 0
    Last retransmission scan time is 0 msec, maximum is 0 msec

OSPFv3 Database — New LSA Types

! ── show ospfv3 database ─────────────────────────────────────────
NetsTuts_R1#show ospfv3 database

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

                Router Link States (Area 0)

ADV Router       Age         Seq#        Fragment ID  Link count  Bits
 1.1.1.1         156         0x80000003  0            1           B  ← ABR (B bit)
 2.2.2.2         143         0x80000003  0            1           B  ← ABR (B bit)

                Net Link States (Area 0)

ADV Router       Age         Seq#        Link ID    Rtr count
 2.2.2.2         143         0x80000001  4          2

                Inter Area Prefix Link States (Area 0)

ADV Router       Age         Seq#        Prefix
 1.1.1.1         134         0x80000001  2001:DB8:1::/48     ← Area 1 prefix in Area 0
 2.2.2.2         127         0x80000001  2001:DB8:2::/48     ← Area 2 prefix in Area 0

                Link (Type-8) Link States (Area 0)

ADV Router       Age         Seq#        Link ID    Interface
 1.1.1.1         156         0x80000001  3          GigabitEthernet0/0
 2.2.2.2         143         0x80000001  4          GigabitEthernet0/0
! ← Type 8 Link LSA: carries link-local address + on-link prefixes

                Intra Area Prefix Link States (Area 0)

ADV Router       Age         Seq#        Link ID    Ref lstype  Ref LSID
 1.1.1.1         156         0x80000002  0          0x2001      0
 2.2.2.2         143         0x80000001  0          0x2001      0
! ← Type 9 Intra-Area-Prefix LSA: carries actual IPv6 prefixes
!   (In OSPFv3, prefixes are SEPARATED from Router/Network LSAs)

IPv6 Routing Table — OSPFv3 Routes

NetsTuts_R1#show ipv6 route ospf
IPv6 Routing Table - default - 12 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
       B - BGP, R - RIP, H - NHRP, I1 - ISIS L1, I2 - ISIS L2
       IA - ISIS interarea, IS - ISIS summary, D - EIGRP, EX - EIGRP external
       ND - ND Default, NDp - ND Prefix, DCE - Destination, NDr - Redirect
       RL - RPL, O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1
       OE2 - OSPF ext 2, ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2

O   2001:DB8:0:2::2/128 [110/2]
     via FE80::2, GigabitEthernet0/0      ← R2's loopback via link-local next-hop
OI  2001:DB8:2::/48 [110/3]
     via FE80::2, GigabitEthernet0/0      ← Inter-area (OI) prefix from Area 2

! ── KEY: Link-local next-hop FE80::2 via Gi0/0 ───────────────────
! ── NOT a global unicast next-hop — this is OSPFv3/EIGRPv6 norm ──

NetsTuts_R1#show ipv6 route
IPv6 Routing Table - default - 16 entries
C   2001:DB8:10:12::/64 [0/0]
     via GigabitEthernet0/0, directly connected
L   2001:DB8:10:12::1/128 [0/0]
     via GigabitEthernet0/0, receive
O   2001:DB8:0:2::2/128 [110/2]
     via FE80::2, GigabitEthernet0/0
OI  2001:DB8:2::/48 [110/3]
     via FE80::2, GigabitEthernet0/0
D   2001:DB8:3::/48 [90/130816]
     via FE80::3, GigabitEthernet0/2    ← EIGRPv6 route via R3's link-local
D   2001:DB8:0:3::3/128 [90/130816]
     via FE80::3, GigabitEthernet0/2
L   FF00::/8 [0/0]
     via Null0, receive                  ← Multicast — always present

EIGRPv6 Neighbour Verification

! ── show ipv6 eigrp neighbors ────────────────────────────────────
NetsTuts_R1#show ipv6 eigrp neighbors
EIGRP-IPv6 VR(NETSTUTS) Address-Family Neighbors for AS(100)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
0   Link-local address:     Gi0/2                    14 00:12:33    8   200   0  15
    FE80::3
! ← Neighbour address is link-local FE80::3 on Gi0/2

! ── Named mode output includes VR(name) prefix ───────────────────
! ── Classic mode shows: "EIGRP-IPv6 Neighbors for AS(100)"  ──────

! ── Detailed neighbour information ──────────────────────────────
NetsTuts_R1#show ipv6 eigrp neighbors detail
EIGRP-IPv6 VR(NETSTUTS) Address-Family Neighbors for AS(100)
H   Address                 Interface              Hold Uptime
0   Link-local address:     Gi0/2                    12 00:12:33
    FE80::3
   Version 23.0/2.0, Retrans: 1, Retries: 0, Prefixes: 3
   Topology-ids from peer - 0
   Topologies advertised to peer:   base
   Last startup serial 0

EIGRPv6 Topology Table

! ── show ipv6 eigrp topology ─────────────────────────────────────
NetsTuts_R1#show ipv6 eigrp topology
EIGRP-IPv6 VR(NETSTUTS) Topology Table for AS(100)/ID(1.1.1.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status

P   2001:DB8:3::/48, 1 successors, FD is 130816
        via FE80::3 (130816/128256), GigabitEthernet0/2   ← R3 is successor
P   2001:DB8:0:3::3/128, 1 successors, FD is 130816
        via FE80::3 (130816/128256), GigabitEthernet0/2
P   2001:DB8:10:4::/64, 1 successors, FD is 130816
        via FE80::3 (130816/128256), GigabitEthernet0/2
P   2001:DB8:2::/48, 1 successors, FD is 259072
        via FE80::3 (259072/130816), GigabitEthernet0/2   ← R2's prefix via R3

Verification Command Summary

Command	Protocol	What It Shows	Key Field to Check
`show ipv6 interface brief`	Both	All IPv6 addresses per interface — link-local and global unicast	State [up/up]; link-local FE80:: present; global addresses assigned
`show ospfv3 neighbor`	OSPFv3	OSPFv3 adjacency table — neighbour RID, state, dead timer, interface	State = FULL/DR or FULL/BDR or FULL/ — any FULL state = healthy
`show ospfv3 database`	OSPFv3	All LSA types — Router, Network, Inter-Area-Prefix, Link (T8), Intra-Area-Prefix (T9)	Type 8 (Link) and Type 9 (Intra-Area-Prefix) are OSPFv3-specific; verify both present
`show ipv6 ospf interface [int]`	OSPFv3 classic	OSPFv3 interface details — area, cost, DR/BDR, Hello/dead timers	Area assignment matches topology design; cost correct; DR/BDR elected
`show ipv6 eigrp neighbors`	EIGRPv6	EIGRPv6 neighbour table — link-local address, interface, hold time, SRTT	Neighbour address = FE80:: link-local; Q Cnt = 0 (no stuck queued packets)
`show ipv6 eigrp topology`	EIGRPv6	EIGRP topology table for IPv6 — successors, FD, AD per prefix	All prefixes in Passive (P) state; FD values reasonable; successors present
`show ipv6 route`	Both	Complete IPv6 routing table — C, L, O, OI, D, S prefixes	O/OI routes for OSPFv3; D routes for EIGRPv6; next-hop = FE80:: via interface
`show ipv6 route ospf`	OSPFv3	OSPFv3-only routes — O (intra-area) and OI (inter-area)	OI routes = inter-area prefixes from other areas; via link-local next-hop
`show ipv6 protocols`	Both	All active IPv6 routing protocols — process IDs, RIDs, interfaces, neighbours	Protocol name; router ID; interfaces with protocol enabled; neighbour count
`ping ipv6 [address]`	Both	End-to-end IPv6 reachability test	5/5 success rate; use source address to test specific paths

9. Complete Configuration Reference & Key Points

Full IPv6 Routing Configuration — R1 (OSPFv3 + EIGRPv6 Named)

! ════════════════ R1 Complete Configuration ══════════════════════
ipv6 unicast-routing        ! MUST be first — enables IPv6 forwarding
!
! ─── Interfaces ──────────────────────────────────────────────────
interface Loopback0
 ipv6 address 2001:DB8:0:1::1/128
!
interface Loopback1
 ipv6 address 2001:DB8:1::/48
 ipv6 ospf 1 area 1
!
interface GigabitEthernet0/0
 description R1-to-R2-Area0
 ipv6 address 2001:DB8:10:12::1/64
 ipv6 address FE80::1 link-local
 ipv6 ospf 1 area 0
 no shutdown
!
interface GigabitEthernet0/1
 description R1-Area1-stub
 ipv6 address 2001:DB8:10:1::1/64
 ipv6 address FE80::1 link-local
 ipv6 ospf 1 area 1
 no shutdown
!
interface GigabitEthernet0/2
 description R1-to-R3-EIGRP
 ipv6 address 2001:DB8:10:3::1/64
 ipv6 address FE80::1 link-local
 no shutdown
!
! ─── OSPFv3 ──────────────────────────────────────────────────────
ipv6 router ospf 1
 router-id 1.1.1.1
 passive-interface GigabitEthernet0/1
!
! ─── EIGRPv6 Named Mode ──────────────────────────────────────────
router eigrp NETSTUTS
 address-family ipv6 unicast autonomous-system 100
  eigrp router-id 1.1.1.1
  af-interface GigabitEthernet0/2
   hello-interval 5
   hold-time 15
  exit-af-interface
  af-interface Loopback1
   passive-interface
  exit-af-interface
  network 2001:DB8::/32
 exit-address-family

IPv6 Routing Protocol Command Reference

Command	Mode	Protocol	Purpose
`ipv6 unicast-routing`	Global config	All	Enable IPv6 packet forwarding between interfaces. Required before any IPv6 routing protocol works.
`ipv6 address FE80:: link-local`	Interface config	All	Assign explicit link-local address. Recommended over auto-generated EUI-64 link-locals.
`ipv6 router ospf [pid]`	Global config	OSPFv3 classic	Create OSPFv3 process. Configure router-id, passive-interfaces, and summarization here.
`router-id [x.x.x.x]`	Router/AF config	OSPFv3, EIGRPv6	Set 32-bit router ID. Mandatory on IPv6-only routers. Best practice always.
`ipv6 ospf [pid] area [n]`	Interface config	OSPFv3 classic	Activate OSPFv3 on this interface and assign to specified area. Replaces network statements.
`ospfv3 [pid] ipv6 area [n]`	Interface config	OSPFv3 AF mode	AF-mode equivalent of `ipv6 ospf area`. Used when process created with `router ospf`.
`ipv6 ospf cost [n]`	Interface config	OSPFv3	Override interface cost for OSPFv3 metric calculation.
`area [n] range [prefix/len]`	Router OSPFv3 config	OSPFv3	Summarize IPv6 prefixes from area n as they cross the ABR. Same logic as OSPFv2 area range.
`ipv6 ospf authentication ipsec spi [n] sha1 hex [key]`	Interface config	OSPFv3	Enable IPsec AH authentication on this interface. SPI and key must match on both ends.
`router eigrp [name]`	Global config	EIGRPv6 named	Create named EIGRP process. Name is locally significant.
`address-family ipv6 unicast autonomous-system [asn]`	Router EIGRP config	EIGRPv6 named	Enter IPv6 address-family. ASN must match on all neighbours.
`network [ipv6-prefix]`	AF config	EIGRPv6 named	Activate EIGRPv6 on interfaces matching the prefix. Advertise matching connected prefixes.
`ipv6 router eigrp [asn]`	Global config	EIGRPv6 classic	Create classic EIGRPv6 process. Requires `no shutdown` to activate.
`ipv6 eigrp [asn]`	Interface config	EIGRPv6 classic	Activate classic EIGRPv6 on this interface. No network statements in classic mode.

Key Points & Exam Tips

ipv6 unicast-routing is the first command — always. Without it, the router processes IPv6 traffic addressed to itself but does not forward IPv6 packets between interfaces. No IPv6 routing protocol will work. Every IPv6 routing lab should begin with this command on every router. It is a global configuration command — not per-interface.
OSPFv3 uses interface-level activation, not network statements. In OSPFv2, you activate OSPF by listing network ranges under the router process. In OSPFv3 (classic method), you activate OSPF directly on the interface with ipv6 ospf [pid] area [n]. The router process only contains the router-id, passive interfaces, and summarization — not the interface-to-area mappings.
IPv6 routing table next-hops are link-local addresses. Both OSPFv3 and EIGRPv6 use link-local addresses as next-hops. show ipv6 route shows entries like via FE80::2, GigabitEthernet0/0. The interface name is mandatory — link-local addresses are only scoped to a single link and are meaningless without their interface context.
Classic EIGRPv6 is shutdown by default. When you create a classic EIGRPv6 process with ipv6 router eigrp [asn], it is administratively shut down. You must issue no shutdown under the process before it forms any adjacencies. Named mode EIGRP does not have this limitation — it activates automatically when the address-family is configured.
Router ID must be manually set on IPv6-only routers. OSPFv3 and EIGRPv6 use a 32-bit dotted-decimal Router ID — the same format as IPv4. The RID is auto-selected from IPv4 addresses if they exist. On an IPv6-only router with no IPv4 addresses configured, the process cannot start without an explicit router-id [x.x.x.x] command.
OSPFv3 authentication uses IPsec, not built-in MD5. OSPFv2 supports authentication directly with ip ospf authentication md5. OSPFv3 removed this built-in mechanism and uses IPv6's native IPsec framework (AH for integrity, ESP for encryption). Both routers on a link must configure identical SPI numbers and keys.
OSPFv3 adds two new LSA types. Type 8 (Link LSA) carries the link-local address and on-link prefixes for each interface. Type 9 (Intra-Area-Prefix LSA) carries the actual IPv6 prefixes that are connected to the router — this information was embedded in Type 1/2 LSAs in OSPFv2 but is separated out in OSPFv3 to keep the topology LSAs address-family agnostic. See OSPF Areas & LSAs for the OSPFv2 baseline.
OSPFv3 classic and AF mode cannot be mixed on the same router. Interfaces using ipv6 ospf [pid] area [n] (classic) and interfaces using ospfv3 [pid] ipv6 area [n] (AF mode) in the same OSPFv3 process will conflict. Choose one method per router and apply it consistently across all interfaces.
On the CCNP exam: know the differences between OSPFv2 and OSPFv3 configuration models (network statements vs interface commands), the mandatory ipv6 unicast-routing command, why link-local addresses appear as next-hops, the OSPFv3 Type 8 and Type 9 LSA additions, the classic EIGRPv6 shutdown requirement, and named mode EIGRP structure. For IPv6 address assignment methods (SLAAC vs DHCPv6) see IPv6 DHCPv6 & SLAAC. For single-area OSPFv2 baseline see OSPF Single-Area Configuration.

Related Labs: IPv6 routing builds directly on IPv6 addressing fundamentals. Review IPv6 Basic Configuration for address types, EUI-64, and prefix assignment before this lab. For the IPv4 OSPF multi-area design that OSPFv3 mirrors see OSPF Multi-Area Configuration. For EIGRP concepts that apply to EIGRPv6 (DUAL, feasible distance, feasible successor) see EIGRP Configuration. For IPv6 summarization in OSPFv3 using the same area range concept see Route Summarization & Aggregation. For dual-stack gateway redundancy with FHRP on IPv6 segments see FHRP — HSRP vs VRRP vs GLBP.

TEST WHAT YOU LEARNED

1. An engineer configures OSPFv3 on R1 with `ipv6 ospf 1 area 0` on GigabitEthernet0/0 and sets router-id 1.1.1.1, but R2 shows no OSPFv3 neighbour entry for R1. R2's configuration looks correct. What is the most likely cause?

A. The router IDs conflict — both routers are using 1.1.1.1 B. ipv6 unicast-routing is not configured on R1 (or R2). Without this global command, IPv6 forwarding is disabled — OSPFv3 Hellos sent by R1 are processed for the router itself but are never forwarded or responded to in the context of the routing process. The OSPFv3 process cannot form adjacency because IPv6 routing is not enabled at the system level. This is the single most common reason IPv6 routing protocol adjacency fails on a freshly configured router. C. OSPFv3 requires a manual network statement — the ipv6 ospf area interface command alone is insufficient D. The process ID must be the same on both routers — if R2 uses process ID 2, adjacency cannot form

Correct answer is B. The missing ipv6 unicast-routing command is the most frequent and most impactful misconfiguration in IPv6 routing labs. On Cisco IOS, IPv6 unicast routing is disabled by default — this is a deliberate design choice, unlike IPv4 where routing is enabled once interfaces are configured. Without ipv6 unicast-routing: the router accepts IPv6 packets addressed to its own IPv6 addresses (it responds to pings, SSH, etc.), but it does not forward IPv6 packets received on one interface out another interface. This means OSPFv3 Hellos arriving on Gi0/0 may be processed locally (R1 hears R2's Hellos), but R1 cannot actually participate as a routing entity — it won't complete the adjacency formation or exchange LSAs. The fix is simple: ipv6 unicast-routing under global config on every router. Option D is a common misconception — OSPFv3 process IDs are locally significant (like OSPFv2) and do not need to match between neighbours. Two routers using different process IDs can still form OSPFv3 adjacency as long as their area assignments, hello/dead timers, and authentication match.

2. The IPv6 routing table on R1 shows: `O 2001:DB8:2::/48 [110/3] via FE80::2, GigabitEthernet0/0`. An engineer questions why the next-hop is a link-local address instead of a global unicast address. What is the correct explanation?

A. This indicates a misconfiguration — OSPFv3 should use global unicast next-hops. The link-local next-hop suggests R2's global unicast address is missing B. Link-local next-hops only appear when the interface is unnumbered — numbered interfaces always use global unicast next-hops C. The link-local next-hop indicates the route is learned via the Data Link layer, not through OSPFv3 D. This is correct and expected behaviour. OSPFv3 (and EIGRPv6) source all routing protocol messages from the interface's link-local address (FE80::/10). When R1 learns routes from R2, R2's link-local address on the shared link (FE80::2) is used as the next-hop in R1's routing table. Link-local addresses exist on every IPv6-enabled interface automatically — they are available even if no global unicast address is configured, enabling routing adjacency on transit links without allocating global prefixes. The interface name (GigabitEthernet0/0) is mandatory alongside the link-local address because link-locals are link-scoped — FE80::2 is only meaningful within the context of Gi0/0.

Correct answer is D. Link-local next-hops in the IPv6 routing table are not a misconfiguration — they are the designed behaviour of all IPv6 routing protocols (OSPFv3, EIGRPv6, RIPng, IS-IS for IPv6). The design rationale is elegant: link-local addresses (FE80::/10 range) are automatically generated on every IPv6-enabled interface via stateless address autoconfiguration. This means two routers can exchange routing information using only link-local addresses, without any globally routable address configured on the transit link. This is especially valuable for point-to-point WAN links where allocating a /64 global unicast prefix just for a router-to-router link wastes address space. The routing entry via FE80::2, GigabitEthernet0/0 tells the router: "to reach 2001:DB8:2::/48, send packets with destination MAC derived from FE80::2 (via NDP), out GigabitEthernet0/0." The interface qualifier is critical — without it, the link-local address is ambiguous (FE80::2 could exist on any interface). A router performing an IPv6 forwarding decision must specify both the link-local next-hop AND the exit interface to uniquely identify the next-hop router.

3. What is the fundamental difference between how OSPFv2 and OSPFv3 are activated on interfaces, and what does this mean for the role of the router process configuration?

A. In OSPFv2, interfaces are activated via network [prefix] [wildcard] area [n] statements under router ospf [pid] — the process centrally manages which interfaces participate. In OSPFv3 (classic method), there are no network statements — each interface is individually activated with ipv6 ospf [pid] area [n] directly on the interface. The router process (ipv6 router ospf [pid]) only contains global parameters: router-id, passive interfaces, summarization (area range), and redistribution. Interface-to-area assignments are distributed across interface configurations rather than centralised in the routing process. B. OSPFv3 uses the same network statement method as OSPFv2 — the only difference is that IPv6 prefix/length notation is used instead of IPv4 wildcard notation C. OSPFv3 requires both a network statement AND an interface command — they serve different functions D. OSPFv3 is always configured via address-family mode — the classic interface command method is not available

Correct answer is A. This interface-centric vs process-centric distinction is one of the most important configuration differences between OSPFv2 and OSPFv3 and is a high-frequency exam topic. In OSPFv2: you configure everything under router ospf [pid]. The network statements implicitly define which interfaces participate and in which areas. The interface itself has no OSPF-specific configuration (unless you're tuning costs, timers, or authentication). In OSPFv3 classic: the ipv6 router ospf [pid] process is minimal — it only contains router-id, passive-interface, area range (summarization), and stub/NSSA area declarations. All interface activation and area assignment is done under each interface with ipv6 ospf [pid] area [n]. This means to audit which interfaces are running OSPFv3 and in which areas, you must examine each interface's configuration rather than looking at a centralised network statement list. Some engineers find this more verbose; others prefer the explicit per-interface control. Both methods achieve the same functional result — it's purely a configuration model difference. The AF mode (ospfv3) uses yet another approach: interfaces are activated with ospfv3 [pid] ipv6 area [n], which is similar to classic but uses the ospfv3 keyword instead of ipv6 ospf.

4. An engineer configures classic EIGRPv6 on R1 (`ipv6 router eigrp 100`) and activates it on Gi0/0 (`ipv6 eigrp 100`), but no adjacency forms with R2. R2's configuration is identical. What critical step is missing?

A. EIGRPv6 requires a network statement under the router process — interface-only activation is insufficient B. The router ID must be configured as an IPv6 address, not a 32-bit dotted-decimal value C. Classic EIGRPv6 processes are administratively shut down by default. The no shutdown command must be issued under ipv6 router eigrp 100 to activate the process. Without it, the process exists in the configuration but does not send or receive EIGRP messages on any interface. This is unique to classic EIGRPv6 — EIGRPv4 and named-mode EIGRP are active by default. D. EIGRPv6 uses a different multicast address than EIGRPv4 — the interface must have the multicast address manually configured

Correct answer is C. The shutdown-by-default behaviour of classic EIGRPv6 is one of the most tested and most commonly forgotten details in IPv6 routing configuration. When you create an EIGRPv6 process with ipv6 router eigrp 100, IOS places the process in a shutdown state. It is present in the configuration, it has a router-id (if configured), but it does not participate in any routing activity. You must issue no shutdown within the ipv6 router eigrp configuration context to activate it. Evidence of this state: show ipv6 protocols will show the EIGRPv6 process as "EIGRP-IPv6 Protocol for AS(100)" but with no neighbours and an "is shutdown" or similar indicator. show ipv6 eigrp neighbors returns empty. The interface with ipv6 eigrp 100 will show EIGRP enabled on it, but no Hellos are sent. Named EIGRP mode does not have this problem — when you configure the address-family and network statements, the process is automatically active. This is one of the reasons Cisco introduced named mode — to eliminate these confusing activation inconsistencies between IPv4 and IPv6 EIGRP behaviour.

5. OSPFv3 introduces two new LSA types not present in OSPFv2: Type 8 and Type 9. What information does each carry, and why was this separation necessary?

A. Type 8 carries external routes; Type 9 carries inter-area routes — they replace Types 5 and 3 respectively in the IPv6 domain B. Type 8 carries router adjacency information; Type 9 carries DR/BDR election data for multi-access segments C. Both Type 8 and Type 9 are for authentication only — they carry the IPsec SA parameters for OSPFv3 secured links D. Type 8 (Link LSA) carries the router's link-local address and the list of IPv6 prefixes on that specific link — it is flooded only within the local link (not area-wide). Type 9 (Intra-Area-Prefix LSA) carries the IPv6 prefixes associated with a router or a transit network — it replaces the address information that OSPFv2 embedded directly in Type 1 (Router) and Type 2 (Network) LSAs. The separation was necessary to make OSPFv3's topology LSAs address-family agnostic: Type 1 and Type 2 LSAs in OSPFv3 carry only topology information (adjacencies, link states, costs) with no address information — they work identically for both IPv4 AF and IPv6 AF. The actual prefix advertisements are in the new address-specific Type 8/9 LSAs.

Correct answer is D. The OSPFv3 LSA restructuring is a deliberate architectural decision to enable address-family agnosticism. In OSPFv2, the Router LSA (Type 1) and Network LSA (Type 2) embed IPv4 address information directly in the topology description. This means OSPFv2 is inherently IPv4-specific — you cannot reuse the same LSA structure for IPv6. OSPFv3 solves this by stripping all address information from Type 1 and Type 2 LSAs: a Type 1 OSPFv3 Router LSA contains only link IDs, interface IDs, and metric information — no IP addresses. The address information is moved to two new LSA types: Type 8 (Link LSA) — has local link scope (flooded only between the two routers on a point-to-point link, or between all routers on a shared segment). Carries the originating router's link-local address (so neighbours can populate the next-hop field) and the list of IPv6 prefixes on that link. Not flooded beyond the link. Type 9 (Intra-Area-Prefix LSA) — has area scope (flooded throughout one area). Carries IPv6 prefix-to-router bindings. There are two subtypes: one associated with a Router LSA (carrying the router's connected prefixes) and one associated with a Network LSA (carrying prefixes on a transit network). The separation enables the same OSPFv3 topology engine (running Type 1/2/3/4/5 LSAs for topology and inter-area information) to carry IPv4 AF data using one set of prefix LSAs and IPv6 AF data using another — a single unified flooding mechanism for both address families.

6. A router has no IPv4 addresses configured anywhere — it is a pure IPv6 router. An engineer attempts to start OSPFv3 with `ipv6 router ospf 1`. The process starts but immediately shows `%OSPFv3-4-NORTRID: OSPFv3 process 1 is unable to allocate a router-id`. What must be done and why?

A. Configure a loopback interface with an IPv6 address — OSPFv3 derives its RID from the highest IPv6 loopback address B. The router ID must be manually configured with router-id [x.x.x.x] using a 32-bit dotted-decimal value. OSPFv3 (and EIGRPv6) retain the 32-bit IPv4-format Router ID inherited from their IPv4 predecessors. The RID is normally auto-selected from the highest IPv4 loopback or active interface address. On a pure IPv6 router with no IPv4 addresses, there is nothing to auto-select from — the process cannot start without a RID. The solution is to manually configure any 32-bit value in dotted-decimal notation (e.g., router-id 1.1.1.1). This value has no connection to any real IPv4 address — it is purely a router identifier within the OSPF domain. C. Add a minimal IPv4 address (127.0.0.1) to a loopback — OSPFv3 can then auto-select this as the RID D. OSPFv3 on pure IPv6 routers uses the MD5 hash of the highest IPv6 address as the router ID — no manual configuration is needed

Correct answer is B. This question highlights a somewhat counterintuitive aspect of OSPFv3 (and EIGRPv6): despite being IPv6 routing protocols, they use a 32-bit IPv4-format Router ID. This is a legacy design decision that maintains operational consistency — network engineers familiar with OSPFv2 Router IDs can use the same identification convention in OSPFv3. The Router ID is critical for OSPFv3 operation: it uniquely identifies each router in the OSPF domain. All LSAs are tagged with the advertising router's RID. The DR/BDR election on multi-access segments uses the RID as the final tiebreaker (after priority). Without a RID, the process cannot participate in any of these functions, hence the error message. The manual router-id command accepts any 32-bit value — common practice is to use the router's management IP (if IPv4 management exists), a loopback IP, or a sequential identifier (1.1.1.1, 2.2.2.2, etc.) that maps to the router's number in the topology diagram. Option C (using 127.0.0.1) technically works but is bad practice — the loopback range is semantically reserved for localhost and using it as an OSPF RID would cause confusion. The correct approach is always an explicit router-id command with a meaningful value.

7. How does named EIGRP mode differ from classic EIGRPv6 in terms of process structure and interface activation? What is the advantage of named mode for dual-stack deployments?

A. Named mode is identical to classic mode — the name is just a label for documentation purposes B. Named mode uses a different AS number range (10000–65535) while classic mode uses 1–9999 C. Classic EIGRPv6 requires separate processes for IPv4 (router eigrp [asn]) and IPv6 (ipv6 router eigrp [asn]), each with its own configuration syntax. Named mode uses a single router eigrp [name] process with address-family sub-sections — address-family ipv4 and address-family ipv6 — providing a unified configuration hierarchy. For dual-stack, this means one process, one AS number, consistent parameter inheritance, and a single point of management. Named mode also provides: wide metrics (64-bit vs 32-bit composite metric), per-AF stub configuration, add-paths support, and eliminates the classic EIGRPv6 shutdown-by-default issue. D. Named mode only supports IPv6 — it cannot carry IPv4 routes, which still require classic configuration

Correct answer is C. Named EIGRP mode represents Cisco's architectural evolution of EIGRP to handle modern network requirements, particularly dual-stack and advanced feature sets. Classic EIGRP (both IPv4 and IPv6) has configuration fragmentation: separate router processes for each address family, different command syntax (network statements for IPv4, interface commands for IPv6), and inconsistent behaviours (e.g., IPv6 shutdown-by-default). Named mode consolidates everything under a single process hierarchy: router eigrp [NAME] → address-family ipv4 unicast autonomous-system [N] (IPv4 AF settings, network statements, interface config) → address-family ipv6 unicast autonomous-system [N] (IPv6 AF settings, network statements, interface config). Both AFs share the same process name but can have independent parameters. The operational advantages for dual-stack: one show command tree, unified troubleshooting, consistent metric calculation (wide metrics use 64-bit values, eliminating the metric scaling issues that caused problems when mixing different interface speeds in classic mode), and no need to remember IPv6-specific peculiarities like the shutdown requirement. IOS 15.x deployments and beyond should standardise on named mode. The AS number within each address-family must match between neighbours — it still serves as the EIGRP domain identifier, just nested under the named process.

8. An engineer pings R2's loopback (2001:DB8:0:2::2) from R1 after configuring OSPFv3. The ping fails with "Unreach". `show ospfv3 neighbor` shows R2 in FULL state. `show ipv6 route` on R1 shows the prefix. What is the most likely cause of the ping failure?

A. R2's Loopback0 interface does not have ipv6 ospf 1 area 0 configured — the loopback address is not being advertised into OSPFv3. R1 has the route (possibly from a previous state or redistributed source), but R2 drops the return traffic because the reverse path is broken. Alternatively, R1's routing table shows the route but R2's loopback interface is not actually up, or the route is there but sourced from a stale database entry. Verify with show ipv6 ospf database to confirm R2's loopback prefix appears in a Type 9 Intra-Area-Prefix LSA, and verify show interfaces Loopback0 on R2 shows up/up. B. IPv6 pings are blocked by default — an explicit ACL must permit ICMPv6 traffic C. The OSPFv3 adjacency must be FULL/DR (not FULL/ ) before routes can be exchanged D. OSPFv3 does not advertise loopback interfaces — only physical interfaces can be added to an OSPFv3 area

Correct answer is A. When an OSPF adjacency is FULL but pings still fail despite seeing the route in the routing table, the issue is almost always asymmetric routing or an unadvertised prefix. In this scenario: R1 has the route to 2001:DB8:0:2::2 in its routing table (the question states this). R1 sends the ping from its own address (probably its Gi0/0 address). The ICMP Echo arrives at R2. R2 looks up the return path to R1's source address. If R1's source address prefix is not in R2's routing table, R2 cannot send the Echo Reply — the ping fails at the return path. Alternatively (and more directly related to the question setup): R2's Loopback0 prefix (2001:DB8:0:2::2/128) might not actually be active in OSPFv3. R2 might have forgotten to add ipv6 ospf 1 area 0 on its Loopback0 interface. Without this command, R2's loopback address is not advertised into OSPFv3 — R1 has no route to it. But if R1's routing table DOES show the route (as stated), then R2's loopback must be advertised somehow, and the issue is likely in the return path. Diagnostic approach: ping from a specific source address (ping ipv6 2001:DB8:0:2::2 source loopback0), check R2's routing table for R1's source prefix, and verify the OSPFv3 database on both routers contains the expected Type 9 LSAs for all loopback prefixes.

9. What is the purpose of configuring an explicit link-local address (e.g., `ipv6 address FE80::1 link-local`) instead of relying on the auto-generated EUI-64 link-local? What operational benefit does this provide?

A. Explicit link-locals are required for OSPFv3 — EUI-64 link-locals are not accepted by the routing protocol B. Explicit link-locals prevent duplicate address detection (DAD) conflicts on shared segments C. EUI-64 link-locals may change when the interface MAC changes — explicit link-locals are stable across hardware replacement D. Explicit link-locals provide multiple operational benefits: (1) Readability — EUI-64 auto-generated link-locals like FE80::20C:29FF:FE3A:7B1C are 39 characters and impractical for manual ping testing and show command analysis. FE80::1 is instantly recognisable and easy to type. (2) Documentation consistency — the link-local is predictable and can be pre-documented in network diagrams and runbooks before hardware is installed. (3) Hardware independence — EUI-64 link-locals are derived from the interface MAC address. When a router is replaced (RMA), the new hardware has a different MAC and therefore different link-local, breaking any documentation and requiring updates to routing table interpretations. Explicit link-locals survive hardware replacement unchanged. (4) Troubleshooting simplicity — show ipv6 eigrp neighbors showing FE80::3 immediately identifies R3 in the topology; showing FE80::20C:29FF:FE1A:4B2C requires cross-referencing MAC tables to identify the router.

Correct answer is D. Explicit link-local addressing is a best practice recommendation, not a protocol requirement — both EUI-64 and explicit link-locals are fully functional for OSPFv3 and EIGRPv6 operation. The benefits are operational and administrative rather than technical. Point 1 (readability) is the most immediately compelling in lab environments: when troubleshooting with show ipv6 route, you want to immediately identify which router a next-hop corresponds to. With explicit link-locals (FE80::1, FE80::2, FE80::3 for R1, R2, R3), the routing table is self-documenting. With EUI-64 link-locals, you need a separate lookup step to identify which router owns which link-local. Point 3 (hardware independence) is the most compelling in production: EUI-64 link-locals are derived from the interface's MAC address (specifically the modified EUI-64 process: split the MAC, insert FFFE, flip the 7th bit). When you replace a line card or an entire router, the MAC changes, the link-local changes, and any documentation showing FE80::20C:29FF:... as a next-hop is immediately stale. An explicit FE80::1 configured in the running-config persists through hardware replacements as long as the config is restored. Point 4 is addressed by noting that the same explicit link-local CAN be reused on multiple interfaces of the same router — this is valid because link-locals are link-scoped, so FE80::1 on Gi0/0 and FE80::1 on Gi0/1 are different addresses in different link scopes.

10. How does OSPFv3 authentication differ from OSPFv2 authentication, and what are the two IPsec mechanisms available? What information must match on both routers for authentication to succeed?

A. OSPFv3 uses the same built-in MD5 mechanism as OSPFv2, but with a longer key — both use the ip ospf authentication command family B. OSPFv3 authentication is automatic — it uses the IPv6 link-local address as a shared secret between neighbours C. OSPFv3 removed the built-in authentication mechanism present in OSPFv2 and uses IPv6's native IPsec framework instead. Two mechanisms are available: (1) IPsec AH (Authentication Header) — provides integrity and anti-replay protection but no encryption. Configured with ipv6 ospf authentication ipsec spi [n] sha1|md5 hex [key]. (2) IPsec ESP (Encapsulating Security Payload) — provides both integrity and encryption. Configured with ipv6 ospf encryption ipsec spi [n] esp aes-cbc 128|192|256 hex [key] sha1|md5 hex [key]. For authentication to succeed, both routers must have: identical SPI value, identical algorithm (SHA-1 or MD5), and identical key material (hex string). A mismatch in any of these three parameters causes OSPFv3 to drop received packets and adjacency cannot form. D. OSPFv3 uses HMAC-SHA-256 by default with no configuration needed — authentication is enabled automatically when ipv6 unicast-routing is enabled

Correct answer is C. The authentication model change between OSPFv2 and OSPFv3 is a significant design decision. OSPFv2 has built-in authentication mechanisms (null, plain text, MD5) that are part of the OSPF protocol specification. This made OSPF authentication relatively simple but limited in cryptographic strength and flexibility. OSPFv3 designers decided to leverage IPv6's existing IPsec infrastructure rather than inventing another proprietary authentication mechanism. The benefits of IPsec-based authentication: stronger cryptographic primitives, interoperability with the broader IPsec ecosystem, and the ability to provide not just integrity but also encryption of OSPF control traffic. The two mechanisms serve different needs: AH is simpler to configure and provides sufficient protection against route injection attacks in most environments. ESP adds confidentiality — useful when OSPF control traffic traverses untrusted paths (e.g., a leased line segment where physical security is uncertain). The SPI (Security Parameter Index) is the critical matching parameter — it identifies the security association and must be identical on both sides of a link. If router A configures SPI 256 and router B configures SPI 300, the routers use different SA indices and authentication fails immediately. This is the most common misconfiguration when setting up OSPFv3 IPsec authentication.

Back to Home