EIGRP for IPv6: Classic and Named Mode on IOS XE

EIGRP did not just bolt IPv6 support onto the existing process. On Cisco IOS XE, EIGRP for IPv6 is a separate protocol instance with its own topology table, its own neighbors, and a configuration model that trips up engineers who expect it to look like IPv4 EIGRP. There is no network statement, the next hop is always a link-local address, and (depending on your IOS version) the process may or may not come up shut down. This article walks the classic interface-based configuration on real IOS XE 17.18, shows the actual adjacency and routes, and clears up the one gotcha that has confused CCNP and CCIE candidates for years. It is part of the PingLabz IPv6 routing and services guide, and it builds directly on the EIGRP cluster.

Why EIGRP for IPv6 is its own protocol

EIGRP for IPv4 and EIGRP for IPv6 share the same DUAL (Diffusing Update Algorithm) core, the same composite metric, and the same convergence behaviour. What differs is the plumbing. IPv6 does not use the network command to select which interfaces run the protocol. Instead, you enable EIGRP directly on each interface. That single design decision changes how you read a router's configuration: to know which interfaces are participating, you look at the interfaces themselves, not at a list of network statements under the routing process.

The other structural difference is the next hop. IPv6 interior gateway protocols always form adjacencies and install routes using link-local addresses (the FE80::/10 range that every IPv6 interface auto-generates). You will never see a global unicast next hop for an EIGRP-learned IPv6 route. This is not a quirk, it is by design: link-local addresses are guaranteed to exist and are guaranteed to be reachable on the local link, which is exactly what a next hop needs to be.

Classic mode: the interface-based configuration

Classic mode is the original configuration style and the one you still meet most often in production and in older documentation. Here is the working configuration from EDGE1 facing CORE1 on the lab, IOS XE 17.18.02:

ipv6 router eigrp 100
interface Ethernet0/1
 ipv6 eigrp 100
interface Loopback0
 ipv6 eigrp 100

Read that carefully. The ipv6 router eigrp 100 line creates the process for autonomous system 100. But nothing under that process tells it which interfaces to use. The activation happens per interface with ipv6 eigrp 100. Enable it on the interfaces you want to advertise and form adjacencies over, and leave it off everywhere else. There is no network 2001:db8::/64 equivalent, and there is no wildcard mask to fuss over. If an interface is not carrying EIGRP, it is because you did not put ipv6 eigrp 100 on it.

The adjacency and the routes: what you actually see

Once both ends are enabled, the neighbor comes up. Notice the address the router lists for its neighbor:

EDGE1#show ipv6 eigrp neighbors
EIGRP-IPv6 Neighbors for AS(100)
H   Address                 Interface   Hold Uptime   SRTT   RTO  Q  Seq
0   Link-local address:     Et0/1        14  00:00:17    1   100  0  3
    FE80::A8BB:CCFF:FE00:7710

The neighbor is identified by its link-local address FE80::A8BB:CCFF:FE00:7710, not by any global address you configured. That is the rule for every IPv6 IGP, and it is the first thing to internalise. Now look at the route EIGRP installs:

EDGE1#show ipv6 route eigrp
D   2001:DB8:99:255::2/128 [90/409600]
     via FE80::A8BB:CCFF:FE00:7710, Ethernet0/1

The learned prefix is a global unicast address (CORE1's loopback), but the via next hop is again the link-local address out Ethernet0/1. The administrative distance is 90 (internal EIGRP, unchanged from IPv4) and the composite metric is 409600. The D code is EIGRP, exactly as it is for IPv4. Nothing about DUAL changed; only the address family did.

The topology table confirms the feasible successors and feasible distances:

EDGE1#show ipv6 eigrp topology
P 2001:DB8:99:255::1/128, 1 successors, FD is 128256
P 2001:DB8:99:12::/64, 1 successors, FD is 281600
P 2001:DB8:99:255::2/128, 1 successors, FD is 409600

Each prefix is in the passive (P) state with one successor and a feasible distance. This is the same topology-table structure you already know from IPv4 EIGRP, which is the whole point: if you understand DUAL, you already understand the routing logic here. Only the enablement and next-hop conventions are new.

The honest gotcha: does the process come up shut down?

Here is the piece of folklore that has cost people hours. The classic teaching, repeated in study guides for years, is that ipv6 router eigrp comes up administratively shut down and that you must issue no shutdown under the process before any adjacency will form. For a long time on classic IOS that was genuinely true, and forgetting the no shutdown was a rite of passage.

On this lab, running IOS XE 17.18, that behaviour did not reproduce. The adjacency came up immediately after enabling the interfaces, with no no shutdown required under the process. So the honest guidance is: do not assume either way. The shutdown-by-default behaviour was real on older IOS and may still appear on some platforms and versions, so verify it on the exact code you are running. And if a classic EIGRP-for-IPv6 adjacency stubbornly refuses to form, checking for a shut-down process is still the very first thing to rule out:

EDGE1#show ipv6 protocols

If show ipv6 protocols shows the EIGRP process is shut down, add no shutdown under ipv6 router eigrp 100 and the neighbors will spring to life. If it shows the process active and you still have no neighbor, move on to the usual suspects: mismatched AS numbers, an interface that is missing the ipv6 eigrp command, an ACL blocking the multicast, or a mismatched authentication key. The lesson is not that the gotcha is fake; it is that it is version-dependent, so you confirm rather than assume.

Named mode: the modern configuration

Classic mode still works and still appears everywhere, but Cisco's modern recommendation is named mode EIGRP, which places every address family under a single named process. The IPv6 configuration lives inside an address-family block:

router eigrp PLZ
 address-family ipv6 unicast autonomous-system 100
  af-interface Ethernet0/1
  exit-af-interface
 exit-address-family

Named mode gives you two concrete advantages. First, it consolidates IPv4 and IPv6 configuration (plus any VRFs) under one router eigrp NAME hierarchy, so the whole EIGRP posture of the router lives in one place instead of scattered across ipv6 router eigrp and interface commands. Second, named mode enables wide metrics by default. Classic EIGRP scales its metric to a 32-bit value, which starts to lose resolution above roughly a gigabit of interface bandwidth. Wide metrics use a 64-bit metric so that 10G, 40G, and 100G links are distinguished properly instead of all flattening to the same value. On any modern high-speed network, that resolution matters for correct path selection.

For a deeper look at how the composite metric and DUAL feasibility work, see the wider EIGRP cluster, which covers the IPv4 mechanics that carry over unchanged into IPv6.

What carries over unchanged from IPv4 EIGRP

Once you get past the enablement and next-hop conventions, almost everything you already know about EIGRP applies without modification. The hello and hold timers default to the same values (5 seconds hello, 15 seconds hold on high-bandwidth broadcast and point-to-point links). Feasibility and the feasible-distance test that prevent routing loops are identical. Summarisation, stub routing, and the split-horizon rules all behave the same way, you just configure them in the IPv6 context. Authentication is still available, and on any production EIGRP-for-IPv6 deployment you should turn it on so that a rogue device on a segment cannot inject an adjacency.

The composite metric still weighs bandwidth and delay by default (with reliability, load, and MTU available but unused unless you change the K-values). Because delay is part of the metric and delay is configured per interface in tens of microseconds, the same delay knob you use to influence IPv4 EIGRP path selection influences IPv6 path selection too, as long as both address families run over the same interface. The mental model to carry away is simple: EIGRP for IPv6 is EIGRP, with an IPv6 address family and a per-interface enablement model bolted on in place of the network command.

Verifying and troubleshooting

Three commands answer most questions. show ipv6 eigrp neighbors tells you whether the adjacency exists and over which interface. show ipv6 route eigrp tells you which prefixes made it into the routing table and confirms the link-local next hop. show ipv6 protocols tells you the process is running (and, critically, whether it is shut down) along with the interfaces and any redistribution. When a neighbor will not form, work that list top to bottom: process shut down, AS mismatch, missing ipv6 eigrp on an interface, an ACL dropping the EIGRP multicast, an authentication mismatch, or an MTU mismatch on the link. The order matters because the cheapest checks (process state and AS number) catch the most common mistakes.

Classic vs named at a glance

Key Takeaways

• EIGRP for IPv6 is a separate protocol instance that reuses DUAL, the composite metric, and administrative distance 90 from IPv4 EIGRP.
• There is no network statement. You enable classic mode per interface with ipv6 eigrp <as>, so interfaces, not network commands, tell you what is participating.
• The next hop is always a link-local FE80:: address, both in show ipv6 eigrp neighbors and in show ipv6 route eigrp. Learned prefixes are global, next hops are link-local.
• The classic "process comes up shut down, needs no shutdown" gotcha was real on older IOS but did not reproduce on IOS XE 17.18. Verify on your version, and check show ipv6 protocols for a shut-down process as your first troubleshooting step.
• Named mode (router eigrp NAME with an address-family ipv6 block) is the modern configuration and enables 64-bit wide metrics, which you want on any high-speed network.

Next in the series: how IS-IS handles IPv6 and the single-topology trap that quietly blackholes it. For the full picture of IPv6 routing and services, return to the IPv6 guide.