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.
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.
Let’s being our EIGRP review by reminding ourselves of a few basic EIGRP characteristics:
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:
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:
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.
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.
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.
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.
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.
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.
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