Understanding EIGRP – Part 1

I used to work as a Network Design Specialist at Walt Disney World, in Florida. Their massive network contained over 500 Cisco routers (and thousands of Cisco Catalyst switches). What was the routing protocol keeping all of these routers in agreement about available routes? It was Enhanced Interior Gateway Routing Protocol (EIGRP). That’s the focus of this blog post, which is the first of a series of posts focusing on EIGRP.

If you already have your CCNA R/S certification (or higher), you’re probably well acquainted with EIGRP. However, unless you have an eidetic memory (like Sheldon Cooper on The Big Bang Theory TV show), you probably don’t remember every single EIGRP command and concept. Therefore, this series of blog posts is going to review and reinforce those fundamental EIGRP concepts, and even introduce a few other fun facts.

EIGRP Fundamentals

There’s a long-running debate about the fundamental nature of EIGRP. At its essence, is EIGRP a link state routing protocol or a distance vector routing protocol? Or, is it a hybrid routing protocol (that is, a combination of both)? You’ll find lots of literature supporting the notion that EIGRP is a hybrid routing protocol, arguing that EIGRP neighbors initially exchange their full routing table, much like a distance vector routing protocol, and EIGRP only sends routing updates based on network changes, much like a link state routing protocol.

While I was in the “it’s a hybrid routing protocol” camp for many years, recently I converted to the belief that EIGRP is an “advanced distance vector” routing protocol. Here’s my reasoning: Consider the fundamental characteristic of a link state routing protocol, which is routers maintaining a topology table, indicating how routers are interconnected. These routers (speaking routing protocols such as OSPF and IS-IS) then run the Dijkstra Algorithm on that topology to determine the “shortest” path to a destination network from the perspective of a particular router. EIGRP does not maintain a view of the network’s topology, nor does it run the Dijkstra Algorithm. Rather, EIGRP’s topology table lists available networks, along with information about the “distance” to those networks. That’s my take, but I certainly won’t harbor any ill feelings for you if you’re on the “hybrid” side of the debate.

EIGRP Characteristics

Let’s being our EIGRP review by reminding ourselves of a few basic EIGRP characteristics:

• Fast Convergence: If a link goes down in a network, in many cases EIGRP can rapidly reroute around the link failure. This typically happens in no more than 3 seconds. This fast convergence is made possible by EIGRP having a standby route to a network, and that standby route is ready to take over in the event the primary route fails.
• Highly Scalable: Whereas a routing protocol such as RIP has a limit of fifteen router hops, EIGRP can scale to support very large enterprise networks, such as the Walt Disney World network mentioned earlier.
• Load Balancing Over Unequal Cost Links: By default, both EIGRP and OSPF load balance traffic across more than one link leading to a specific destination network, if the cost (that is, the value of the routing protocol metric) is the same. However, EIGRP can be configured to load balance across links with unequal costs. This is made possible by the variance feature.
• Variable-Length Subnet Mask (VLSM) Support: Unlike RIP version 1, EIGRP sends subnet mask information as part of a route advertisement.
• Communicates via Multicast: An EIGRP-speaking router communicates with other EIGRP-speaking routers via multicast. Specifically, EIGRP for IPv4 uses a multicast address of 224.0.0.10, while EIGRP for IPv6 uses a multicast address of ff02::a.
• Was Cisco-Proprietary: While Cisco originally introduced EIGRP as a Cisco-proprietary routing protocol, in recent years EIGRP has been opened up to other vendors. Specifically, EIGRP was made an open standard in 2013, and an EIGRP informational RFC (RFC 7868) was published in 2016.
• Multiprotocol Support: EIGRP was originally designed to support the routing of multiple protocols, including IPv4, IPX, and AppleTalk. Although modern networks rarely if ever use IPX or AppleTalk, EIGRP can now support IPv6, which is rapidly growing in popularity. This multiprotocol support is made possible by Protocol-Dependent Modules (PDMs), where there is a separate PDM handling routing decisions for each routed protocol (for example, IPv4 and IPv6).
• Diffusing Update Algorithm (DUAL): EIGRP’s algorithm used to keep track of routes known to neighboring routers. DUAL is also used to determine the best path to a destination network (that is, the successor route) and any acceptable backup paths to that destination network (that is, feasible successor routes).
• Summarization: To reduce the number of entries in an EIGRP topology table (or a router’s IP routing table), EIGRP has the ability to summarize multiple network advertisements into a single network advertisement. This summarization can be manually configured. However, EIGRP has an automatic route summarization feature that summarizes networks at classful network boundaries.
• Updates: Full EIGRP topology table updates are sent when new neighbors are discovered. Otherwise, partial updates are sent.

Configuration Review

A basic EIGRP configuration is very easy to configure. In fact, it only requires two commands:

router eigrp asn

network net-id wildcard-mask

The router eigrp asn command starts the EIGRP routing process on a router for an autonomous system (AS) specified by the asn variable. This command also brings you into router configuration mode. From there, you can issue the second command, network net-id wildcard-mask. This second command uses a combination of a network address and a wildcard mask to specify a range of one or more IP addresses, and any router interface whose IP address belongs to that range of IP addresses then participates in the EIGRP routing process. However, there are some rules and behaviors to keep in mind with these commands:

• EIGRP-speaking routers must be in the same AS to form a neighborship.
• After a router enables EIGRP on interfaces matched by the EIGRP network command, it attempts to discover neighbors by multicasting EIGRP Hello messages.
• If a wildcard mask is not specified in the network command, the specified network address should be a classful network address.
• If a wildcard mask is not specified in the network command, and a classful network address is specified, all interfaces whose IP addresses fall under the classful network (for example, 172.16.1.1 /24 would fall under 172.16.0.0 /16) will participate in the EIGRP routing process.

To illustrate these concepts, consider the following example:

EIGRP Configuration on Routers R1, R2, and R3

The EIGRP configuration on routers R1, R2, and R3 begins with a router eigrp 1 command. This command tells each router to start an EIGRP routing process within the autonomous system of 1. Since autonomous system numbers must match between EIGRP-speaking neighbors, all three routers use the same autonomous system number of 1. Also, notice how the configuration varies in its use of the network command:

Router R1’s network 10.1.1.0 0.0.0.3 Command

On router R1, the network 10.1.1.0 0.0.0.3 command specifies a network address of 10.1.1.0 with a wildcard mask of 0.0.0.3, which corresponds to a 30-bit subnet mask (that is, a 255.255.255.252 subnet mask). Since router R1’s Gig 0/1 interface’s IP address of 10.1.1.1 /30 falls in that subnet, that interface is instructed to participate in the EIGRP process.

Router R1’s network 10.1.1.5 0.0.0.0 Command

The network 10.1.1.5 0.0.0.0 command specifies a specific IP address, rather than an entire subnet (or, one might argue that it’s a subnet containing a single IP address). We know it’s only specifying a single IP address due to the wildcard mask of 0.0.0.0. Recall that in a wildcard mask we have a series of contiguous zeros followed by a series of contiguous ones (in binary). The binary zeros correspond to bit positions in the IP address that specify a network address, and the binary ones correspond to bit positions in the IP address that specify the host address. However, in an instance were we have all zeros, as in this case, we have a network of one and only one IP address (that is, the subnet mask is /32). Since the IP address matches the IP address of router R1’s Gig 0/2 interface, that interface also participates in the EIGRP routing process.

Router R1’s network 192.0.2.0 Command

The final network command on router R1 is network 192.0.2.0. Interestingly, this command was actually entered as network 192.0.2.0 0.0.0.255, but since 0.0.0.255 is the wildcard mask corresponding to the default subnet mask (also known as the natural mask) of a Class C network (in this case 192.0.2.0 /24), it’s implied but not shown. Router R1’s Gig 0/3 interface’s IP address of 192.0.2.1 /24 does indeed fall within the Class C subnet specified by the network command. Therefore, the Gig 0/3 also starts to participate in router R1’s EIGRP routing process.

Router R2’s network 10.0.0.0 Command

The network 10.0.0.0 command on router R2 seems to be missing a wildcard mask. However, remember from the previously discussed network command (on router R1), a wildcard mask is not displayed if it’s reflecting the natural mask of the subnet being specified. Building on that logic, we can conclude that if we intentionally omit the wildcard mask argument from a network command, the assumed wildcard mask will be the wildcard mask corresponding to the classful subnet mask of the network specified in the network command. In this case, the first octet of the network specified in the network address command is 10. A 10 in the first octet of an address indicates that we’re dealing with a Class A address, which has a default subnet mask of 255.0.0.0, and therefore a default wildcard mask of 0.0.0.255. Since router R2’s Gig 0/1 and Gig 0/2 interfaces both fall under this classful network statement, both interfaces participate in router R2’s EIGRP routing process.

Router R2’s network 198.51.100.0 Command

Like the previous network command, router R2’s network 198.51.100.0 command was entered without specifying a wildcard mask. Since the first octet of the address is a 198, we can conclude that we have a Class C network, whose default subnet mask is 255.255.255.0, and whose default wildcard mask is 0.0.0.255. The IP address (198.51.100.1 /24) of interface Gig 0/3 on router R2 lives within the specified 198.51.100.0 /24 subnet. So, the interface participates in the EIGRP routing process.

Router R3’s network 0.0.0.0 Command

Recall that an EIGRP network statement, contrary to popular belief, does not specify a network to advertise. Rather, it specifies a range of one or more IP addresses, and any interface with an IP address in that range is instructed to participate in the EIGRP routing process. This means if we want all interfaces on a router to participate in the same EIGRP routing process, we could give the command network 0.0.0.0 to specify all possible IP addresses. Since the IP address of each individual interfaces falls under the category of “all possible IP addresses,” all of the interfaces on router R3 are instructed to participate in the EIGRP routing process. Also, the network addresses of those participating interfaces (along with subnet information for those network addresses) are then advertised via EIGRP.

Verification Review

The process of EIGRP verification is more than just making sure neighborships have formed between all routers and that all routers have learned all the routes in the network. The verification process needs to help us verify our design requirements were met. For example, we need to look for appropriate routes to appear in the EIGRP topology table, desired interfaces to appear in the EIGRP interface table, and specific neighbors to appear in the EIGRP neighbor table. Once we have our design goals and anticipated outcomes in mind, we can leverage such EIGRP verification commands as those shown in the following table:

Key EIGRP Verification Commands

The following examples show the output from each of these commands after issuing them on router R1 shown in the previous topology.

Output from show ip route Command on Router R1

Notice how routes learned via EIGRP are shown with a D in the left column. This D code indicates a route learned via EIGRP. These routes include 10.1.1.8 /30, 198.51.100.0 /24, and 203.0.113.0 /24. Also note the highlighted 90 in each EIGRP-learned route. The 90 is EIGRP’s administrative distance (that is, it’s believability as compared to other routing sources), where lower administrative distance values are preferred over higher values.

Output from show ip protocols Command on Router R1

Output from the show ip protocols command on a router speaking EIGRP, as seen above, offers us several data points. For example, under the Routing for Networks: section, you see a list of networks specified by the network command under EIGRP configuration mode. Under the Routing Information Sources: section, you can determine the IP addresses of EIGRP neighbors, which are 10.1.1.2 (that is, router R2) and 10.1.1.6 (that is, router R3) in our topology. Also under that section, you can see the Administrative Distance (AD) for our neighbors. Since those neighbors are EIGRP-speaking routers, they have the default EIGRP AD of 90. Finally, notice the Metric weight K1=1, K2=0, K3=1, K4=0, K5=0 portion of the output. In an upcoming blog post, we’ll learn how EIGRP calculates its metric and how that calculation involves K-values. When we discuss those K-values, please keep in mind you can view a router’s K-values in the output of the show ip protocols command.

Output from show ip eigrp interfaces Command on Router R1

The output of the show ip eigrp interfaces, seen above, indicates that router R1’s Gig 0/1, Gig 0/2, and Gig 0/3 are participating in an EIGRP routing process. Specifically, the process is for EIGRP AS 1. Also notice that an EIGRP neighborship has been established with another router connected off of router R1’s Gig 0/1 interface, and another off of interface Gig 0/2. These neighborship establishments are evidence by having a number greater than 0 in the Peers column. Since router R1’s Gig 0/3 interface did not form a neighborship with any other EIGRP-speaking routers, there is 0 in its Peers column.

Output from show ip eigrp neighbors Command on Router R1

While output from the show ip eigrp interfaces command indicated that we had a couple of EIGRP neighbors, output from the show ip eigrp neighbors command, as seen above, offers more detail about those neighbors. Specifically, the neighbor connected off of router R1’s Gig 0/1 interface has an IP address of 10.1.1.2, and the neighbor connected off of router R1’s Gig 0/2 interface has an IP address of 10.1.1.6.

Output from show ip eigrp topology [all-links] Command on Router R1

One of the most common commands used for EIGRP verification and troubleshooting is show ip eigrp topology, as demonstrated in the example above. Output from this command shows the successor routes (that is, the preferred routes) and feasible successor routes (that is, backup routes) known to the EIGRP routing process. Please keep in mind that a route’s appearance in the EIGRP topology table does not guarantee its presence in the router’s IP routing table. Specifically, the successor routes present in the EIGRP topology table are only candidates to be injected into the router’s IP routing table. For example, the router might possess more believable routing information for a network, such as a statically configured route with an administrative distance of 1. If EIGRP is indeed the most believable routing source for a specific network, then that network will be injected into the router’s IP routing table. Also, notice how the addition of the all-links argument in the above example shows even more routes, which are highlighted. The difference is, the all-links argument instructs the show ip eigrp topology command to display all EIGRP-learned routes, even if some of the routes are not considered successor routes or feasible successor routes.

By the way, you can watch me teach EIGRP as part of the curriculum in the following video courses:

CCNA R/S (200-125) Complete Video Course

CCNP ROUTE (300-101) Complete Video Course

Well, that’s it for this first in a series of EIGRP blog posts. In the next one, we’ll check out some EIGRP internals. For example, we’ll dig into those K-values, and see how they influence EIGRP’s path selection.

Kevin Wallace, CCIEx2 (R/S and Collaboration) #7945