CCNA: IPv6 Won't Ping — Work the Failure, Not the Config

Archive lab

A dual-stack enterprise tri-router line with two LANs and end hosts. IPv4 routing is healthy and end-to-end; IPv6 addressing is present but end-to-end IPv6 fails. Work from operational state only to isolate and correct the broken IPv6 control/forwarding plane without changing what already works. The graded end-state requires IPv6 forwarding enabled on all routers, OSPFv3 process 10 in area 0 with an explicit unique router-id on every router, and per-interface activation on all required links so the hosts can ping6 across the WAN.

Learning objectives

• Use show ipv6 interface brief, show ipv6 route, show ipv6 neighbors, show ipv6 ospf interface brief and show ipv6 ospf neighbor to localize a broken IPv6 path
• Differentiate between interface up/up vs. control-plane adjacency and forwarding readiness
• Enable IPv6 forwarding (ipv6 unicast-routing) and bring up OSPFv3 with an explicit, unique router-id
• Activate OSPFv3 on the correct interfaces and verify end-to-end IPv6 reachability from hosts

Troubleshooting focus

• IPv4 stays green while IPv6 fails, so a healthy-looking network proves nothing — drive every conclusion from IPv6-specific show output
• An interface that is up/up with a correct global address can still be invisible to OSPFv3: activation is per-interface, and show ipv6 ospf interface brief is what proves it
• The Router ID a process is operationally using is not always the one you assume — read it from show ipv6 ospf, and remember two routers in an area may never share one
• Global IPv6 forwarding writes nothing to the running config when it is off, so its absence is invisible by eye and shows up only as transit traffic vanishing on an otherwise healthy router
• A router-id change is latched at process start and does nothing until clear ipv6 ospf process is run