Hands-On Lab: Configuring EIGRP Named Mode

This hands-on lab reconfigures a classic EIGRP setup into EIGRP named mode, organizing address-family and interface-specific configuration into a more structured hierarchy, and verifies functional equivalence with the classic configuration style used throughout earlier EIGRP labs in this series.

EIGRP Named Mode ConfigurationAddress-Family Topology StructurePer-Interface AF Settings

~4 min read · Updated Sep 26, 2026

Lab Objective

Convert an existing classic EIGRP configuration into EIGRP named mode, organizing network statements, interface-specific timers, and authentication under a structured address-family hierarchy, and verify the resulting neighbor relationships and routing behavior remain functionally identical to the classic mode configuration used in earlier EIGRP labs.

Lab Purpose

Every EIGRP lab covered earlier in this series used classic mode configuration, where settings like network statements and per-interface parameters are scattered between global router configuration mode and individual interface configuration mode. Named mode consolidates all of this under a single, named EIGRP process with a clearer address-family structure, the format Cisco recommends for new deployments and required for certain advanced EIGRP features.

Lab Topology

R1 ---- Serial0/0/0 ---- R2

Currently configured with classic EIGRP AS
100, as covered in earlier labs:
R1: 10.30.30.1/30, LAN 192.168.30.0/24
R2: 10.30.30.2/30, LAN 192.168.40.0/24

Task 1: Remove the Classic EIGRP Configuration

Remove the existing classic router eigrp 100 configuration from both routers.

Task 2: Configure EIGRP Named Mode

Configure EIGRP using named mode syntax, specifying a process name and the IPv4 address-family with the same AS number.

Task 3: Configure Network Statements Within the Address-Family

Add network statements under the address-family topology configuration, equivalent to the classic mode's router-level network statements.

Task 4: Verify Neighbor Relationships Reform

Confirm the EIGRP neighbor relationship between R1 and R2 re-establishes under named mode.

Task 5: Verify Routes Are Learned Identically to Classic Mode

Confirm each router still learns the other's LAN, exactly as under the previous classic mode configuration.

Solution and Verification

R1(config)# no router eigrp 100
R2(config)# no router eigrp 100

-- Removing classic mode entirely --
-- named mode and classic mode configuration
-- for the same AS cannot coexist on one
-- router

R1(config)# router eigrp NAMED-EIGRP
R1(config-router)# address-family ipv4 unicast autonomous-system 100
R1(config-router-af)# network 10.30.30.0 0.0.0.3
R1(config-router-af)# network 192.168.30.0
R1(config-router-af)# exit-address-family

-- "NAMED-EIGRP" is an administrator-chosen
-- process name, purely for local reference
-- -- the actual AS number (100) is what
-- must match between neighbors, specified
-- explicitly within the address-family
-- line rather than in the initial router
-- eigrp command as classic mode required

R2(config)# router eigrp NAMED-EIGRP
R2(config-router)# address-family ipv4 unicast autonomous-system 100
R2(config-router-af)# network 10.30.30.0 0.0.0.3
R2(config-router-af)# network 192.168.40.0
R2(config-router-af)# exit-address-family

R1# show eigrp address-family ipv4 neighbors

EIGRP-IPv4 VR(NAMED-EIGRP) Address-Family
Neighbors for AS(100)
H   Address         Interface   Hold Uptime
0   10.30.30.2      Se0/0/0      13  00:00:24
-- Neighbor relationship re-established
-- under the named mode structure, showing
-- the process name and AS clearly labeled
-- in the output

R1# show ip route eigrp

D    192.168.40.0/24 [90/2681856] via 10.30.30.2, Serial0/0/0
-- R1 still learns R2's LAN, functionally
-- identical to the classic mode behavior
-- from earlier labs -- named mode changes
-- only the configuration syntax and
-- organization, not the underlying DUAL
-- algorithm or routing outcome

Key Takeaway

EIGRP named mode reorganizes configuration into a clearer address-family hierarchy without changing any of the underlying protocol behavior discussed throughout earlier EIGRP labs in this series — the same DUAL algorithm, the same metric calculations, the same neighbor relationships form identically; named mode is purely a configuration syntax evolution, though it also happens to be the required format for certain newer EIGRP capabilities not available under classic mode, making it the format Cisco now recommends for new deployments.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring EIGRP Stub Routing

This hands-on lab configures a branch router as an EIGRP stub, verifying it advertises only its own connected and summary routes while the hub router correctly avoids querying the stub during a topology change elsewhere in the network.

Continue

Hands-On Lab: Configuring ERSPAN Across a Routed Network

This hands-on lab configures Encapsulated RSPAN (ERSPAN) to mirror traffic across a Layer 3-routed network rather than a single Layer 2 trunk, extending the RSPAN concept from the previous lab beyond the boundaries of a single VLAN or switched domain.

Continue

Hands-On Lab: Configuring RSPAN Across Switches

This hands-on lab configures Remote SPAN (RSPAN) using a dedicated RSPAN VLAN carried across a trunk, allowing traffic mirrored on one switch to be monitored by a capture device connected to an entirely different switch, extending the local SPAN concept covered in an earlier lab across the network.

Continue

Hands-On Lab: Configuring In-Service Software Upgrade (ISSU) on a Stack

This hands-on lab performs an In-Service Software Upgrade across a StackWise stack, upgrading each member's IOS image one at a time while the stack continues forwarding traffic throughout, verifying zero downtime compared to the disruptive reload approach used in earlier IOS upgrade labs.

Continue

Hands-On Lab: Configuring Cisco Catalyst StackWise Traditional Stacking

This hands-on lab configures traditional Catalyst stacking (StackWise) across three switches using stack cables, contrasting its single-tier, chassis-proximity requirement against the StackWise Virtual pair covered in the previous lab, which allows switches to be located much farther apart.

Continue

Hands-On Lab: Configuring StackWise Virtual

This hands-on lab configures two physical switches into a single logical StackWise Virtual switch using a dedicated Stackwise Virtual Link, verifying both members present as one control plane and that a member failure triggers predictable failover behavior.

Continue