How to Implement IPv6 EIGRP on Cisco Routers: Complete Configuration Guide

EIGRP for IPv6 is a protocol I genuinely enjoy working with, mostly because if you already know EIGRP for IPv4, the transition is refreshingly straightforward — the DUAL algorithm, feasible successors, and metric calculation all behave identically. What changes is primarily the configuration syntax, particularly with the shift toward the named mode configuration that Cisco has standardized across recent IOS-XE releases. In this guide I am covering both classic and named EIGRP for IPv6 configuration, verification, and the troubleshooting patterns I rely on.

Networking Fundamentals: EIGRP for IPv6 vs IPv4

EIGRP for IPv6 uses the same DUAL (Diffusing Update Algorithm) finite-state machine as EIGRP for IPv4, calculating loop-free paths using feasible successors and providing very fast convergence when a feasible successor is available. The metric calculation (based on bandwidth and delay by default, with the option to include reliability, load, and MTU) is unchanged conceptually.

The key structural difference is that EIGRP for IPv6 is enabled directly on interfaces rather than relying on network statements matching an address, which historically caused a lot of confusion in IPv4 EIGRP when engineers got wildcard masks wrong. With IPv6 EIGRP, there is no equivalent network statement ambiguity — you explicitly enable EIGRP on each interface.

Classic Configuration Mode

Router(config)# ipv6 unicast-routing
Router(config)# ipv6 router eigrp 100
Router(config-rtr)# eigrp router-id 1.1.1.1
Router(config-rtr)# exit

Router(config)# interface GigabitEthernet0/0/1
Router(config-if)# ipv6 address 2001:db8:1::1/64
Router(config-if)# ipv6 eigrp 100

Note that eigrp router-id must be explicitly configured for IPv6 EIGRP — unlike IPv4 EIGRP, which can derive a router-id from an IPv4 address on the router, IPv6 EIGRP has no IPv4 address to fall back on by default (in an IPv6-only environment), so I always configure this explicitly to avoid unpredictable router-id assignment or duplicate router-id conflicts.

Named Mode Configuration (Recommended for Modern Deployments)

Cisco has moved toward named EIGRP configuration as the standard across recent platforms, since it unifies IPv4 and IPv6 EIGRP configuration under a consistent structure and makes features like SAF and multi-address-family support cleaner to manage.

Router(config)# ipv6 unicast-routing
Router(config)# router eigrp ENTERPRISE-EIGRP
Router(config-router)# address-family ipv6 unicast autonomous-system 100
Router(config-router-af)# eigrp router-id 1.1.1.1
Router(config-router-af)# af-interface GigabitEthernet0/0/1
Router(config-router-af-interface)# no shutdown
Router(config-router-af-interface)# exit-af-interface
Router(config-router-af)# exit-address-family

I generally recommend named mode for any new deployment, both because it is the direction Cisco’s platform development has been heading and because it keeps IPv4 and IPv6 EIGRP configuration visually and structurally consistent, which reduces mistakes when managing both address families on the same router.

Verification Commands

Router# show ipv6 eigrp neighbors
Router# show ipv6 eigrp topology
Router# show ipv6 route eigrp
Router# show ipv6 protocols

For named mode specifically, some commands require specifying the address family context:

Router# show eigrp address-family ipv6 neighbors
Router# show eigrp address-family ipv6 topology

Adjacency Requirements

For two routers to form an IPv6 EIGRP neighbor relationship, the following must match:

• Autonomous system number
• K-values (metric weight coefficients)
• The routers must share a common subnet on the interface (link-local reachability, since EIGRP for IPv6 uses link-local addresses for neighbor communication by default)

I check K-value consistency with:

Router# show ipv6 protocols

If K-values were customized on one router and not the other (a rare but real cause of failed adjacency), this command will surface the mismatch clearly.

Authentication

I configure MD5 or, preferably, HMAC-SHA256 authentication on every EIGRP for IPv6 deployment I am responsible for in production, since unauthenticated EIGRP allows any device that can reach the link to potentially inject routes.

Classic mode:

Router(config)# key chain EIGRP-KEYS
Router(config-keychain)# key 1
Router(config-keychain-key)# key-string CiscoEigrpKey123

Router(config-if)# ipv6 authentication mode eigrp 100 md5
Router(config-if)# ipv6 authentication key-chain eigrp 100 EIGRP-KEYS

Named mode:

Router(config-router-af-interface)# authentication mode md5
Router(config-router-af-interface)# authentication key-chain EIGRP-KEYS

Summarization and Route Filtering

Route summarization in EIGRP for IPv6 is configured at the interface level, just as in EIGRP for IPv4:

Router(config-if)# ipv6 summary-address eigrp 100 2001:db8::/32

For route filtering, I use distribute-lists referencing IPv6 prefix-lists:

Router(config)# ipv6 prefix-list EIGRP-FILTER seq 10 deny 2001:db8:99::/48
Router(config)# ipv6 prefix-list EIGRP-FILTER seq 20 permit ::/0 le 128

Router(config-router-af)# distribute-list prefix-list EIGRP-FILTER in

Real-World Enterprise Scenario: Migrating from Classic to Named Mode

I was brought into a project migrating a mid-sized enterprise’s dual-stack EIGRP deployment from classic mode configuration (present since the network was first built years earlier) to named mode, primarily to simplify ongoing management and prepare for future SAF-based feature adoption.

My migration approach, refined after doing this a few times:

1. Document existing classic mode configuration entirely, including K-values, authentication, summarization, and distribute-lists.
2. Build the equivalent named mode configuration on a lab router and validate neighbor formation and route exchange against a classic-mode peer, since named and classic mode EIGRP processes can coexist and interoperate during a phased migration.
3. Migrate one router at a time during a maintenance window, verifying neighbor adjacency and full route table convergence after each device before proceeding to the next.
4. Decommission the classic mode configuration only after the entire domain had been migrated and stable for a full business cycle.

This phased, one-device-at-a-time approach meant that if something went wrong mid-migration, only a single router’s adjacencies were at risk rather than the entire EIGRP domain destabilizing simultaneously.

Troubleshooting IPv6 EIGRP Adjacencies

When two routers refuse to form an IPv6 EIGRP neighbor relationship, I follow a consistent sequence:

Router# show ipv6 eigrp neighbors
Router# show ipv6 interface GigabitEthernet0/0/1
Router# show ipv6 protocols

First, I confirm both routers actually have IPv6 link-local reachability on the shared segment — EIGRP for IPv6 neighbor communication happens over link-local addresses, so if link-local connectivity itself is broken (rare, but possible with certain switch-level filtering), the adjacency will never form regardless of EIGRP configuration.

Next, I compare autonomous system numbers and K-values on both sides using show ipv6 protocols, since a mismatch in either will silently prevent adjacency without any obvious error message pointing directly at the cause.

For named mode specifically, I always double-check the af-interface has not been left in its default shutdown state — this single oversight accounts for a large share of the “EIGRP is configured but neighbors never appear” tickets I have diagnosed, precisely because the configuration looks complete at first glance and the missing no shutdown line is easy to overlook.

Finally, if authentication is configured, I verify the key chain and key-string match exactly on both routers, since even a single character mismatch prevents adjacency with no more specific error than a neighbor that simply never appears.

Common Configuration Mistakes

• Forgetting eigrp router-id in an IPv6-only or dual-stack environment where no IPv4 address exists to derive a default router-id
• Enabling EIGRP on an interface without no shutdown under the af-interface context in named mode (a very common and confusing mistake, since named mode af-interfaces are shutdown by default)
• Mismatched K-values between routers, silently preventing adjacency
• Not authenticating EIGRP sessions, leaving the routing domain open to unauthorized route injection
• Summarizing too aggressively at the wrong topology point, creating black holes for subnets that exist behind a router but are suppressed by an upstream summary

Security Best Practices

• Always configure authentication (prefer HMAC-SHA256 over legacy MD5 where platform support allows)
• Use passive-interface by default and explicitly enable only the interfaces that should form adjacencies
• Filter routes at network boundaries to prevent unintended route leakage between EIGRP domains, especially after mergers or acquisitions bringing two previously separate EIGRP autonomous systems together

Router(config-router-af)# eigrp passive-interface default
Router(config-router-af-interface)# no passive-interface

Performance Tuning

• Tune hello/hold timers on WAN links with higher latency characteristics to avoid unnecessary adjacency flapping
• Use eigrp stub configuration on branch/spoke routers in hub-and-spoke topologies to reduce query scope and improve convergence stability across the network
• Pair EIGRP with BFD on critical links for sub-second failure detection rather than relying solely on hold-timer expiration

Router(config-router-af)# eigrp stub connected summary

Frequently Asked Questions

Do I need to configure a router-id manually for EIGRP IPv6? Yes, in most cases — unlike IPv4 EIGRP, there is no guaranteed IPv4 address to derive a default router-id from, so I always configure it explicitly.

Why won’t my EIGRP IPv6 neighbors form an adjacency even though interfaces are up? Check for mismatched K-values, mismatched autonomous system numbers, or in named mode, confirm the af-interface is not left in its default shutdown state.

Should I use classic mode or named mode EIGRP for new deployments? I recommend named mode for new deployments, since it is the direction Cisco platform development has moved and keeps IPv4/IPv6 configuration structurally consistent.

Can classic mode and named mode EIGRP routers interoperate? Yes, they can form adjacencies and exchange routes normally, which makes phased migration between the two straightforward.

Summary

EIGRP for IPv6 preserves everything that makes EIGRP fast and reliable — DUAL-based loop-free convergence and feasible successor calculation — while shifting configuration toward explicit per-interface enablement rather than network statements. Whether using classic or named mode, the fundamentals of adjacency formation, authentication, summarization, and filtering remain consistent with what EIGRP for IPv4 administrators already know, making the transition to IPv6 EIGRP a relatively smooth one for experienced engineers.

References

• Cisco IPv6 Configuration Guide: Implementing EIGRP for IPv6 — cisco.com
• Cisco EIGRP Named Mode Configuration Guide — cisco.com
• RFC 7868 — Cisco’s Enhanced Interior Gateway Routing Protocol (EIGRP)