My journey to CCIE RS — EIGRP 3

Published in

TechRebels

7 min readMar 15, 2021

This is the 5th topic in the series with my accumulated notes over years of study until passing the CCIE RS lab. Almost 400 notebook pages with information and observations that I considered important when working with Routing and Switching for more than 15 years.

I believe this information will help not only certification exams, but in the day by day of other people (like me) when dealing with Cisco infrastructure.

For those who have not read the previous articles, follow below a list with them. Today we explore the “EIGRP” part 3.

Feel free to comment and contact me on LinkedIn. If you liked what you read, I encourage you to share it with colleagues in the industry. Don’t forget to follow TechRebels and me by clicking the follow link on the top :)

Default Routing

Default routing in EIGRP can be done via <default network> or <default information>.

Default Network is a previous compatibility with IGRP that only supports the default network flag and field (does not support 0.0.0.0/0).

<default network> must be learned through EIGRP (so it cannot be directly connected) and be classful.

Default Route (0.0.0.0/0) can be propagated via:

Summarization on direct interface
Redistribution of a static route or other protocol
Apply static default route for directly connected interface (but without next-hop) + declare 0.0.0.0 in the EIGRP process.

NOTE: In both cases, redistributing a default static route to a directly connected interface (without next-hop) is understood by EIGRP to be an internal route (DA 90).

NOTE: Redistributing the default route as internal (DA 90) or external (DA 170) only makes difference when we have multiple routes and want to manipulate preferences.

Filtering IN

Distribute-list in EIGRP works in a similar way as in RIP.
Standard and extended ACLs have limitations and cannot distinguish the prefix size (mask) (same as RIP) because they were designed to filter data plane.
Prefix-list is a much better implementation because it was designed to work with routing information (control plane).
Offset-list is used to increase the metric beyond the limit (same as RIP, with the difference that the metric is much higher) preventing the route from being installed in the routing table.
Administrative distance can be changed by prefix and neighbor (255 = infinite).
EIGRP supports the use of route-map directly in the distribute-list filtering by metric and prefix type (TAG).

Filtering OUT

Distribute-list using ACL or prefix-list
Offset-list
Passive interface disabling adjacencies
Route-map applied directly to the distrbute-list

Router-ID

In EIGRP the router-id is only used on external routes as a loop prevention mechanism. In the event that a route redistributed by a router in the EIGRP domain returns to the same router with a lower AD than the source protocol of the route, this route would be learned by the routing table and could cause a loop. To avoid this, EIGRP does not accept routes with its own router-id.

NOTE: Obviously for this to occur, the AD of the external route should be decreased (because 170 is greater than any IGP).

Duplicate router-ids can generate black holes in the topology because routers will discard external routes.

NOTE: It is a best practice to explicitly define the router-id for all protocols: EIGRP, OSPG, BGP, MPLS, etc.

NOTE: Router-id is used to find out who is the originator of the prefix for OSPF (in graph construction) and BGP (in loop prevention).

EIGRP Named Mode (or Multi-AF)

Old mode is known as EIGRP classic mode.
The biggest change is a better config hierarchy, where the entire config goes in the global process.
There is also a better separation of IPv4 and IPv6 configs because both are unified within the same process and separated by AFs (address-families).
The most important new features are:
— IPv6 VRF lite
— Wide-metrics

Config:

Enable process <router eigrp [NAME]> where NAME is not the AS number
Enable AF <address-family ipv4 autonomous-system X> — AS is configured in AF
Enable process on interface <net [address] [wildcard]> — Similar to OSPF
Customize interfaces <af-interface [default | int]>

Topology-base is the global table, including all interfaces, all related to the process.

NOTE: <af-interface default> applies to all interfaces (more practical, right?).

NOTE: Basically everything is below topology base and af-interface.

EIGRP multi-af allows multi-topology routing with multiple instances of EIGRP.

Config <> address-family ipv4 as X ” (does not show the shortcut but it exists)

EIGRP Multi-AF uses wide-metrics automatically agreed and calculated between peers. FD is calculated and from it the RIB metric is generated (does not use FD directly).

Measures delay in picoseconds instead of usec, taking into account tengig links.

Automatic configuration conversion: Performs automatic graceful restart. <(router) eigrp upgrade-cli NAME>

NOTE: Graceful restart (standard) is non-stop forward (Cisco)

IPv4 and IPv6 — supports both, and can be in different ASs.

Obviously EIGRP named-mode supports multiple ASs within the same EIGRP [NAME] because “name” is a local attribute.

Wide Metrics

Metric in classic mode:

Minimum cost is 256 for 10 gig
Minimum delay (1) is 10 usec
With faster bands, cost visibility and delay are lost

Metric in named mode:

Wide metrics is 64 bits
BW uses a larger scale factor
Delay uses scale on picoseconds
Metric is derived from FD using RIB scale 1/128 (default)
— <(eigrp) metric rib-scale>

Authentication in Named Mode

Supports MD5 and SHA

MD5 uses key chains as classic EIGRP
SHA uses static keys and, therefore, does not support automatic key rotation. SHA is more secure than MD5.
NOTE: If EIGRP is enabled in named mode and you configure some parameter in the interface, an error message alerts you that it is not possible (or at least it should be, because sometimes do not work).

Always use <sh key chain> to verify password in text mode, without hashing.

Authentication is defined in the af-interface

af-interface default
specific af-interfaces override the default

EIGRP on DMVPN

Biggest issue is Split Horizon
— OBS: Split Horizon is not desired in partial mesh NBMA networks (Ex: DMVPN).
EIGRP processes “next-hop” differently from other protocols

NOTE: Redistributing with metric 1 1 1 1 1 in new mode (named) is no longer allowed because it scales to a very low value and EIGRP maps to infinity.

NOTE: <sh ip ei topo all> — shows all options including routes without FSs. Important when adjusting the desired metrics.

DMVPN does not support multicast directly, it encapsulates multicast within unicast and replicates to each peer. Therefore, the best scenario is to use the default route for all spokes and not replicating anything.

Next-Hop Process

EIGRP updates include Next-hop Forwarding Address (the next-hop for the route).
If the next-hop forwarding address is 0, it will use the IP of the header, that is, the IP of the connected neighbor that sent the route.
Where not to use? Third party next-hop (ex: DMVPN phase 2)

In DMVPN phase 2, spokes need next-hop from other spokes. Therefore, the HUB must not change the forwarding address <no next-ho-self> when disabling Split Horizon.

EIGRP is the preferred IGP for DMVPN because it supports routing hierarchy (summaries).

NOTE: OSPF does not allow this because all spokes and hubs would need to be in the same area and, if any of them flap, all of them would need to recalculate SPF.

Config Phase 2 (at the hub):

<no split-horizon>
<no next-hop-self>

Config Phase 3:

Hub — <ip nhrp redirect>
Spoke — <ip nhrp shortcut>

NOTE: Spokes do not establish adj among themselves because DMVPN does not directly support multicast. Therefore, it cannot forward multicast traffic directly between Spokes. There’s no way, don’t insist 😞

NOTE: If DMVPN uses OSPF, the tunnel must use network broadcast mode.

DOC: In the Design Zone, search for “Cisco Validated Design Program” by DMVPN Design Guides.

Show commands for EIGRP

sh ei prot = sh ip prot | se eigrp

sh ip prot

sh ip ei int

sh ip ei int det X

sh ip ei nei

sh ip ei nei det

sh ip route ei

sh ip cef x.x.x.x

sh ip ei topo = sh ei ad ipv4 X topo

sh ip ei topo x.x.x.x y.y.y.y

Will this EIGRP summary help you on your daily job?

Was there anything important missing?

Tell us in the comments!

If you liked this content, I ask you to share it with others in the industry. Don’t forget to follow me and TechRebels by clicking the follow link down below :)