Configuring EIGRP in NetBase: Classic and Named, Side by Side

EIGRP is the protocol every CCNA knows and every production network has quietly migrated off classic for named-mode on anything running IOS 15 or newer. The two flavours use wildly different CLI syntax, which is part of the reason labs still reach for router eigrp <as> while real deployments live under router eigrp <name> with address-families. NetBase keeps both in the same tab, generates the correct syntax for whichever you pick, and validates the metrics and authentication so you don’t have to remember the K-values by heart.

• A NetBase project with a router device tab. Any IOS-XE platform in the Model dropdown is fine for classic + named EIGRP.
• If you plan to deploy live, a NetBase connector assigned to the device. The connector onboarding guide walks you through the built-in wizard.
• A couple of minutes — the visual editor is fast.

In the router editor (/components/router), click EIGRP in the section strip at the top. You’ll see two buttons:

• Add EIGRP process — classic EIGRP, the one you probably configured for the exam.
• Add named EIGRP process — the modern form used on real gear. NetBase warns you that it’s not supported on older IOS versions before adding the card.

Add whichever one matches your target device — or both, if you’re testing a migration — and NetBase renders them into the right IOS stanza at generate time.

The classic EIGRP card has these fields:

• AS — the autonomous system number. Required.
• Router ID — only required when IPv6 is turned on; otherwise the router falls back to the highest IP.
• K-values — only change this if you know exactly how you want to alter the metric calculation. Most networks stick with the default.
• Authentication key and Authentication interfaces — type the key once and NetBase emits the key-chain + ip authentication mode eigrp … lines on every interface you select. No more forgetting one side of the pair.
• Advertise default route, Redistribute static, Redistribute connected — simple switches.

Below those, the Add IPv4 network advertisement button builds the classic network X.X.X.X 0.0.0.255 lines. NetBase accepts either a wildcard or a mask and normalises it in the generated config.

Redistributions get a card of their own: pick the source protocol (OSPF, BGP, connected, static), optionally attach a route-map, and either leave the metric at “default” or fill in bandwidth / delay / reliability / load / MTU.

If you switched to Add named EIGRP process, the fields look similar but the generator renders them inside router eigrp <name> with an explicit address-family ipv4 autonomous-system <as> block. That means:

• Authentication goes under af-interface … rather than per-interface legacy stanzas.
• Redistributions live inside topology base.
• IPv6 is a sibling address-family ipv6 autonomous-system <as>, not a separate process.

You don’t have to think about any of that — just fill in the fields. The Show config modal renders the exact syntax and you can sanity-check it before deploying.

Click Show config on either card. Classic EIGRP produces the familiar form:

router eigrp 100
 eigrp router-id 10.0.0.1
 network 10.10.0.0 0.0.0.255
 passive-interface default
 no passive-interface GigabitEthernet0/0
 redistribute static metric 1000 100 255 1 1500

Named EIGRP renders this instead:

router eigrp CORE
 address-family ipv4 unicast autonomous-system 100
  af-interface GigabitEthernet0/0
   authentication mode md5
   authentication key-chain EIGRP-KC
  exit-af-interface
  topology base
   redistribute static
  exit-af-topology
 exit-address-family

Both come from the same NetBase configuration model. Swap the card style and the IOS stanza changes — no copy-pasting, no tab-tab-tab rewrites.

Click Deploy and NetBase pops the review dialog. Two tabs:

• Changes — field-level diff against the last NetBase deploy. You’ll see “added network 10.10.0.0”, “changed authentication key on Gi0/1”, etc.
• Config — the same code diff against the device’s live running-config, pulled by the connector in the background.

Every deploy runs in merge mode, so EIGRP on the device won’t be rebuilt from scratch. If the running-config is already running classic EIGRP and you’re adding a named process, both coexist until you explicitly remove the old one.

The connector queues the deploy job, executes it, and streams back the logs. Failed jobs surface on the Deployments panel with the full command output so you can see exactly which line the device rejected.

After a successful deploy, cross-check the usual commands over SSH:

show ip eigrp neighbors
show ip eigrp topology
show ip protocols | section eigrp

Adjacency up, topology table populated, metrics sane? You’re done.

• Import what’s already there. If you’re adopting a device that already runs EIGRP, paste show running-config | section eigrp into the Import from running-config dialog. NetBase reads it into the classic or named card automatically so you can pick up where someone else left off.
• Watch for K-value drift. If two routers end up with different K-values they’ll refuse to form an adjacency. NetBase renders whatever you type verbatim — the Show config preview is the fastest way to catch a mismatch before you push.
• Rollback is one click. Every deploy archives the previous running-config on the device-history page. If an adjacency flaps right after your push, open the history, pick the last-known-good revision, and hit Restore.

EIGRP is forgiving enough on paper but punishing if you land a fat-fingered K-value across a dozen routers. Let NetBase type the config for you and keep the reviewable audit log that a terminal window can’t.