My journey to CCIE RS — EIGRP 1

Published in

TechRebels

6 min readMar 1, 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 1.

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 :)

EIGRP

EIGRP does not have as many features and is not as complicated as OSPF and BGP.

Considered a hybrid protocol, it has features of both “link-state” and “distance vector”.

It forms adjacencies as a link-state protocol, but still uses split horizon as a loop prevention mechanism.
DUAL algorithm guarantees a “loop free” topology.
EIGRP does not have a topology overview. It uses “routing by rumor” distance vector method, where the router only knows what the directly connected neighbors are propagating.

Uses its own transport protocol IP 88 (OSPF is similar and uses IP 89). This protocol is used for both unicast and multicast.

NOTE: In any case, despite the link-state features and loop prevention features, it is still considered distance-vector.

EIGRP uses multicast 224.0.0.10 to establish adjacencies. But after adjacencies are established, most of the communication is unicast to synchronize the topology. When the topology converges, multicast is used for incremental updates and unicast for ACKs.

NOTE: As EIGRP uses unicast and muticast, the easiest way to block traffic is to block IP 88.

EIGRP allows running multiple processes and the AS number is global significant (for the entire network). So we can have multiple EIGRP domains running on the entire network.

NOTE: Do not confuse with OSPF, that allows multiple processes but the process number is only locally significant.

NOTE: EIGRP uses wildcard masks which is the opposite of the subnet mask.

EIGRP only propagates installed routes from the routing table.

This behavior is the same for RIP and BGP.
OSPF works on all links regardless of the routing table.

Best practice is to always declare the network as specific as possible to have better control.

The way EIGRP calculates a free loop path is to use routes propagated by the neighbor with metrics smaller than the end-to-end metrics of the router itself. This ensures that the neighbor will always be closer to the destination than the router itself. This allows EIGRP to immediately route to the next best route without having to perform a complete topology recalculation.

Auto-Summary

Like RIP v2, EIGRP is classless but performs automatic summarization by default.
VLSM is supported within the same main network.
Propagations between major networks are summarized in classful, but will not result in “black holes” because EIGRP creates a discard route for summarized routes.

NOTE: In this case we have the same situation with RIP when mixing 2 main networks in the same topology, where route summaries can get confusing, because the same summary can come from different locations. However, with EIGRP there are no loops because of the “Discard Route”.

Split Horizon

In EIGRP, Split Horizon is not used to prevent loops (“Feasible Condition” job), but to improve convergence. Obviously it is because there is no need to disclose a route to a neighbor and get the same route back. The only scenario where this is valid is in a “NBMA partial mesh” topology.

By default, EIGRP enables split-horizon on all interfaces.

NOTE: Disabling the split-horizon will not cause a topology loop because of the “DUAL Feasible Condition”. Therefore, the split-horizon in EIGRP just discards the routes that it would not use right away.

Types of Updates

Uses multicast 224.0.0.10 for HELLO, QUERY, UPDATE
Uses unicast for UPDATE, ACK, REPLY

NOTE: As EIGRP uses multicast and unicast protocol IP 88, we need to be careful not to block. Ex: we can only allow unicast and forget about multicast, or vice versa.

NOTE: Command <neighbor> enables unicast and completely disables multicast for EIGRP (unlike RIP which continues to work in multicast). Therefore, the <neighbor> command in EIGRP needs to be enabled for all neighbors in this particular segment.

<passive-interface> disables unicast and multicast on the interface. So there is no adjacency on passive links. It is usually used for security in the access layer.

NOTE: Both in lab and production environments, always send logs to buffer because it can overload the console.

OBS: To block some traffic transparently, we can use ACL or VLAN ACL in SW L2.

NOTE: For the CCIE lab, it is good to memorize the numbers of the main IP protocols because it is not easy to find in the documentation.

NOTE: Pay attention because the most complicated troubleshooting is precisely when establishing adjacency but it does not exchange information about the topology. The neighbor appears in the list but the queue count remains > 0.

NOTE: The <passive> command prevents the formation of any adjacency (multicast and unicast), so it should not be used in conjunction with <neighbor>.

Timers

Hello — frequency of hello packets on the link.
Hold-time — how long the neighbor must wait to declare the router down (note that it is a different pattern).

In EIGRP, timers do not have to be the same among neighbors to form adjacency. But usually there is no reason to use different timers.

Hello
— Low-speed and NBMA — 60 sec
— Others — 5 sec
Hold-time
— Low-speed and NBMA — 180 sec
— Others — 15 sec

Authentication

Looks much like RIP authentication. The main difference is that it only accepts MD5 (does not accept clear text).

Uses a key chain system (same as RIP) but the key chains must be the same between neighbors because they are exchanged within packets.

“Ignored packet from… (authentication off or key chain missing)”
“Ignored packet from… (invalid authentication)”

EIGRP supports time based key rotation (date and time). To accomplish this, the routers’ clocks must be synchronized or routers will place keys at different points in time and will fail to authenticate.

NOTE: As in RIP, “spaces” count as characters.

To synchronize the routers’ clocks, we can adjust them manually or use NTP. Oddly, NTP synchronization can take several minutes depending on the IOS version and if the times are too far apart (ex: 10 years of distance between times).

NOTE: Best practice: Adjust clocks with real time (even manually). This facilitates verification and troubleshooting.

Recommendation is to always set an overlap time between key chains and set <send> and <accept lifetime> to this overlap time. If there is a slight difference (of seconds) between the accept and send time among routers, EIGRP does not establish (or worse, interrupt) the adjacency due to authentication failure.

To be continued on EIGRP part 2…

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 :)