ON THIS PAGE: How to: EIGRP Routing Protocol Implementation & Tutorial.
EIGRP (Enhanced Interior Gateway Routing Protocol) is an interior gateway protocol that can be used for a variety of topologies and media. EIGRP scales well and delivers incredibly fast convergence times with low network traffic in a well-designed network.
The issue with IGRP was that it didn’t accept VLSM (Variable Length Subnet Masking) and was broadcast-based. VLSM is now supported by the Enhance Interior Gateway Routing Protocol, and updates are sent via multicast using the following multicast address: 184.108.40.206 for IPv4.
This essay is an extract from Lazaro (Laz) Diaz’s book CCNA Routing and Switching 200-125 Certification Guide. Understanding networking with routers and switches, layer 2 infrastructure and its different setups and links, VLANS and inter-VLAN routing, and more are all covered in that book. You’ll learn how to set up default, static, and dynamic routing, as well as how to build and execute subnetted IPv4 and IPv6 addressing schemes. This article explains how EIGRP operates, its functions, and how to configure it for single and multiple autonomous systems.
EIGRP has a lot better than its ancestor. It is not only a classless routing protocol with VLSM features, but it also has a maximum hop count of 255, which is set to 100 by design. It’s also known as a distance-vector routing protocol that’s hybrid or sophisticated. That is, with a connections state and a distance vector, (DV).
It has the best of all worlds The DV characteristics are similar to RIPv2, except that it has a small number of hops. The first time it attempts to converge, it will give the whole routing table to its neighbouring routers, and it will summarise the path. As a result, you’ll need to use the no auto-summary order to ensure that the subnet mask is sent out with the changes.
After it has completely converged and the routing table is complete, it has connection state features such as activated changes. EIGRP can use hello messages to manage neighbour connections or adjacencies, and it can only submit the update when a network is introduced or deleted.
EIGRP has a really clever algorithm as well. The Dual algorithm can take into account a number of factors in order to make a more effective or accurate decision on which direction to submit the packet down in order to get it to its destination faster. EIGRP is also focused on autonomous networks, with a scale of 1 to 65,535 nodes. You may have either one autonomous system, in which case all routers use the same routing table, or you can have several autonomous systems, in which case the routes must be redistributed into the other AS in order for the routers to interact.
As a result, EIGRP is a very effective routing protocol with several advantages that help us operate our network more effectively. So, let’s make a rundown of the most important features:
- Support for VLSM or CIDR
- Summarization and discontinuous networks
- Best path selection using the DUAL
- No broadcast; we use multicast now
- Supports IPv4 and IPv6
- Efficient neighbor discovery
This is the algorithm that enables EIGRP to provide all of its functionality and ensures traffic reliability. The below is a list of the most important roles it performs:
- Finds a backup route if the topology permits
- Support for VLSM
- Dynamic route recovery
- Query its neighbor routers for other alternate routes
EIGRP routers keep a copy of all their neighbours’ routes so they can figure out how much it costs them to reach each target network. They will then check the topology table for replacement or alternative routes if the successor path goes down. This is what makes EIGRP so great: it holds all of their neighbours’ routes and can check the topology table for an alternative route if one goes down.
But what happens if the topology table question fails? EIGRP would then seek assistance from its neighbours in order to find a different path! It is the easiest to converge on a network because of the DUAL approach and the stability and leveraging of other routers.
The DUAL must satisfy the following three conditions in order to function:
- Neighbors are discovered or noted as dead within a distinct time
- Messages that transmitted should be received correctly
- Messages and changes received must be dealt with in the order they were received
The following command will display all of the hello messages you’ve sent, as well as other information:
R1#sh ip eigrp traffic IP-EIGRP Traffic Statistics for process 100 Hellos sent/received: 56845/37880 Updates sent/received: 9/14 Queries sent/received: 0/0 Replies sent/received: 0/0 Acks sent/received: 14/9 Input queue high water mark 1, 0 drops SIA-Queries sent/received: 0/0 SIA-Replies sent/received: 0/0
If you choose to modify the default hello timer to anything longer, use the following command:
Keep in mind that you’re typing this command in interface setup mode.
Tables are also supported by EIGRP. The routing table, topology table, and neighbour table all function together to ensure that if a route to a destination network fails, the routing protocol already has a backup path.
The FD (feasible distance) determines the alternative direction. You are the successor path and would be included in the routing table if you have the lowest FD. If your FD is higher, you can stay a viable successor in the topology chart.
As a result, EIGRP is a rather dependable protocol. Let’s have it set up.
The topology that follows would be a complete mesh, with LANs on each router. This will increase the lab’s complexity, allowing us to examine everything we’ve discussed. We need to know the IP addressing scheme of each system before we start configuring it. The addresses, gateways, and masks of each unit are shown in the table below:
Our display commands must be learned from the routing protocol in use:
R1#sh ip protocols Routing Protocol is "eigrp 100 " Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is not set Default networks flagged in outgoing updates Default networks accepted from incoming updates EIGRP metric weight K1=1, K2=0, K3=1, K4=0, K5=0 EIGRP maximum hopcount 100 EIGRP maximum metric variance 1 Redistributing: eigrp 100 Automatic network summarization is not in effect Maximum path: 4 Routing for Networks: 192.168.1.0 10.0.0.0 Routing Information Sources: Gateway Distance Last Update 10.1.1.10 90 1739292 10.1.1.22 90 1755881 10.1.1.6 90 1774985 Distance: internal 90 external 170
Okay, you’ve got the topology, IP scheme, routing protocol to use, and autonomous machine down pat. As you can see, I’ve already set up the lab, so now it’s up to you.
You’ll need to set it up to go along with the display command we’re about to run.
You should be familiar with your admin commands by now. Since communication is the first concern, I’ll display you the performance of the sh ip int brief command from each router:
If you can see, all of my interfaces have the right IPv4 addresses and are operational; your setup should be similar. If you just like to see the subnet mask of the order you should have used, sh protocols:
It’s time to customise the routing protocol after you’ve checked that both of your interfaces are operational. We’ll use the number 100 on both routers to create a single autonomous device that can share the same routing table. They will learn about their neighbours by sending hello messages. This is how the EIGRP protocol should be configured per router:
As you can see, we use the 100 autonomous machine number for all routers, and we use the classfull boundary, which is a Class A network, to advertise the networks, especially the 10.1.1.0 network. If we fail to use the no auto-summary button, the subnet mask will not be sent out with the changes.
Let’s look at our routing tables and see if we’ve totally converged, which means we’ve found both of our networks:
R2 R2#SH IP ROUTE Gateway of last resort is not set 10.0.0.0/30 is subnetted, 6 subnets D 10.1.1.4 [90/2172416] via 10.1.1.26, 02:27:38, FastEthernet0/1 C 10.1.1.8 is directly connected, Serial0/0/0 D 10.1.1.12 [90/2172416] via 10.1.1.26, 02:27:38, FastEthernet0/1 C 10.1.1.16 is directly connected, Serial0/0/1 D 10.1.1.20 [90/2172416] via 10.1.1.9, 02:27:39, Serial0/0/0 [90/2172416] via 10.1.1.18, 02:27:39, Serial0/0/1 C 10.1.1.24 is directly connected, FastEthernet0/1 D 192.168.1.0/24 [90/2172416] via 10.1.1.9, 02:27:39, Serial0/0/0 C 192.168.2.0/24 is directly connected, FastEthernet0/0 D 192.168.3.0/24 [90/2172416] via 10.1.1.18, 02:27:39, Serial0/0/1 D 192.168.4.0/24 [90/30720] via 10.1.1.26, 02:27:38, FastEthernet0/1 R3 R3Gateway of last resort is not set 10.0.0.0/30 is subnetted, 6 subnets D 10.1.1.4 [90/2172416] via 10.1.1.21, 02:28:49, FastEthernet0/1 D 10.1.1.8 [90/2172416] via 10.1.1.21, 02:28:49, FastEthernet0/1 C 10.1.1.12 is directly connected, Serial0/0/1 C 10.1.1.16 is directly connected, Serial0/0/0 C 10.1.1.20 is directly connected, FastEthernet0/1 D 10.1.1.24 [90/2172416] via 10.1.1.17, 02:28:50, Serial0/0/0 [90/2172416] via 10.1.1.14, 02:28:50, Serial0/0/1 D 192.168.1.0/24 [90/30720] via 10.1.1.21, 02:28:49, FastEthernet0/1 D 192.168.2.0/24 [90/2172416] via 10.1.1.17, 02:28:50, Serial0/0/0 C 192.168.3.0/24 is directly connected, FastEthernet0/0 D 192.168.4.0/24 [90/2172416] via 10.1.1.14, 02:28:50, Serial0/0/1 R4 R4#SH IP ROUTE Gateway of last resort is not set 10.0.0.0/30 is subnetted, 6 subnets C 10.1.1.4 is directly connected, Serial0/0/1 D 10.1.1.8 [90/2172416] via 10.1.1.25, 02:29:51, FastEthernet0/1 C 10.1.1.12 is directly connected, Serial0/0/0 D 10.1.1.16 [90/2172416] via 10.1.1.25, 02:29:51, FastEthernet0/1 D 10.1.1.20 [90/2172416] via 10.1.1.5, 02:29:52, Serial0/0/1 [90/2172416] via 10.1.1.13, 02:29:52, Serial0/0/0 C 10.1.1.24 is directly connected, FastEthernet0/1 D 192.168.1.0/24 [90/2172416] via 10.1.1.5, 02:29:52, Serial0/0/1 D 192.168.2.0/24 [90/30720] via 10.1.1.25, 02:29:51, FastEthernet0/1 D 192.168.3.0/24 [90/2172416] via 10.1.1.13, 02:29:52, Serial0/0/0 C 192.168.4.0/24 is directly connected, FastEthernet0/0
So, what exactly does that imply? They must go to the routing table since EIGRP has two successor routes or two possible lengths that are equivalent. The topology table would include all other paths, including the successor routes.
I’ve highlighted the networks that have multiple routes, which implies they can go in any direction, but EIGRP can load balance them by default:
We need to figure out just how it’s getting to this network: The IP address is 10.1.1.20. This is from the perspective of R4. It might go through 10.1.1.5 or 10.1.1.13, but let’s use what we have, including traceroute:
R4#traceroute 10.1.1.20 Type escape sequence to abort. Tracing the route to 10.1.1.20 1 10.1.1.5 7msec 1 msec 6 msec
So, even though they have the same metric of 2172416, it will submit the packet to the destination through the first direction from top to bottom. If that road is shut down or disconnected, it would still be able to reach its target by an alternative route.
You can get the same results in your lab if you follow the setup exactly as I did. But this is when the inquisitiveness can kick in. See what happens if you switch off the 10.1.1.5 gui. So, how would your routing table appear? Would there be just one path to the destination or several routes? Remember that if a successor path goes down, EIGRP will check the topology table to locate an alternative route; but, will it do so in this case when an alternate route already exists?
Have a peek at the following:
R1(config)#int s0/0/0 R1(config-if)#shut
Let’s have a peek at the routing table from the eyes of R4.
The above is the first item that occurs:
R4# %LINK-5-CHANGED: Interface Serial0/0/1, changed state to down %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/1, changed state to down %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 10.1.1.5 (Serial0/0/1) is down: interface down R4#sh ip route Gateway of last resort is not set 10.0.0.0/30 is subnetted, 5 subnets D 10.1.1.8 [90/2172416] via 10.1.1.25, 02:57:14, FastEthernet0/1 C 10.1.1.12 is directly connected, Serial0/0/0 D 10.1.1.16 [90/2172416] via 10.1.1.25, 02:57:14, FastEthernet0/1 D 10.1.1.20 [90/2172416] via 10.1.1.13, 02:57:15, Serial0/0/0 C 10.1.1.24 is directly connected, FastEthernet0/1 D 192.168.1.0/24 [90/2174976] via 10.1.1.13, 02:57:14, Serial0/0/0 D 192.168.2.0/24 [90/30720] via 10.1.1.25, 02:57:14, FastEthernet0/1 D 192.168.3.0/24 [90/2172416] via 10.1.1.13, 02:57:15, Serial0/0/0 C 192.168.4.0/24 is directly connected, FastEthernet0/0
There is just one path, which is 10.1.1.13. The metric was the same as 10.1.1.5. There was no need to question the topology table in this case since an alternative path was already present in the routing table. However, let’s use the traceroute command to double-check:
R4#traceroute 10.1.1.20 Type escape sequence to abort. Tracing the route to 10.1.1.20 1 10.1.1.13 0 msec 5 msec 1 msec (alternate path) 1 10.1.1.5 7msec 1 msec 6 msec (original path)
It was faster to get to the 10.1.1.20 network when it only had one route, but it took longer because it had different routes. Even if we are just talking of milliseconds, there is always a pause.
So, what does all of this mean? It’s not necessarily a positive idea to provide redundancy. This is a full-mesh topology, which is very expensive and causes delays. As a result, be cautious with your network configuration. There is such a thing as too much redundancy, and Layer 3 loops and delays are simple to build.
We looked at the routing table but not the topology table, so I’m going to restart the s0/0/0 interface and double-check the routing table to make sure it is still as it should be, before moving on to the topology table.
I get the following notification almost immediately after turning on the s0/0/0 interface on R1:
R4# %LINK-5-CHANGED: Interface Serial0/0/1, changed state to up %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0/0/1, changed state to up %DUAL-5-NBRCHANGE: IP-EIGRP 100: Neighbor 10.1.1.5 (Serial0/0/1) is up: new adjacency Let us peek at the routing table on R4: R4#sh ip route Gateway of last resort is not set 10.0.0.0/30 is subnetted, 6 subnets C 10.1.1.4 is directly connected, Serial0/0/1 D 10.1.1.8 [90/2172416] via 10.1.1.25, 03:08:05, FastEthernet0/1 C 10.1.1.12 is directly connected, Serial0/0/0 D 10.1.1.16 [90/2172416] via 10.1.1.25, 03:08:05, FastEthernet0/1 D 10.1.1.20 [90/2172416] via 10.1.1.13, 03:08:05, Serial0/0/0 [90/2172416] via 10.1.1.5, 00:01:45, Serial0/0/1 C 10.1.1.24 is directly connected, FastEthernet0/1 D 192.168.1.0/24 [90/2172416] via 10.1.1.5, 00:01:45, Serial0/0/1 D 192.168.2.0/24 [90/30720] via 10.1.1.25, 03:08:05, FastEthernet0/1 D 192.168.3.0/24 [90/2172416] via 10.1.1.13, 03:08:05, Serial0/0/0 C 192.168.4.0/24 is directly connected, FastEthernet0/0
It’s worth noting that the network’s first route is now 10.1.1.13, rather than 10.1.1.5, as it was previously.
Let’s have a peek at the topology table now:
Remember that the topology includes all feasible paths to all destination networks. Just the lowest FD routes make it to the routing table, earning the title of successor path. The highlighted networks are identical to the ones seen in the routing chart.
Since they each have the same formula, they will both be considered successor routes.
But first, let’s look at another network. Let’s go for 192.168.3.0, which is the last one on the chart. It has a variety of paths, but the indicators aren’t quite the same. Since the FD is 2172416, 10.1.1.13 will be the successor path, but 10.1.1.5 has a metric of 2174976, making it a true successor and keeping it in the topology chart.
What does this mean for us? If the successor route were to fail, it would have to ask the topology table to find a new direction. From the viewpoint of the R3, what does the routing table reveal regarding the 192.168.3.0 network?
R4#sh ip route D 192.168.3.0/24 [90/2172416] via 10.1.1.13, 03:28:10, Serial0/0/0 Since there is only one path, the one with the lowest FD, it is true that if this route fails, a query to the topology table is needed.
So, as you can see, it all depends on how you set up the network topology; you can or may not have a viable successor. As a result, you must evaluate the network you’re dealing with in order to make it more efficient.
To use other routes in our load balancing, we haven’t even adjusted the bandwidth of either of the interfaces or used the variance command.
The Enhanced Interior Gateway Routing Protocol (EIGRP) is a sophisticated dynamic routing protocol that is used on routers for routing choices and configuration. EIGRP was created by Cisco Systems as a proprietary protocol that can only be used on Cisco routers, but in 2013 a portion of EIGRP’s functionality was changed to an open standard. EIGRP only provides incremental updates, which reduces the strain on the router as well as the quantity of data that must be sent. Understanding the fundamentals of the EIGRP routing protocol is critical before configuring the protocol in a production setting.
Features of EIGRP:
- Administrative Distance — 90 (internal, when routers are linked in the same autonomous system), 170 (internal, when routers are connected in the same autonomous system) (external, when routers are connected in different autonomous system).
- To determine the optimal route from the source to the destination, EIGRP employs the Diffusing Update Algorithm (DUAL).
- EIGRP is a Hybrid routing protocol that combines the characteristics of Distance Vector and Link State routing protocols.
- Classless routing is supported.
- On an EIGRP-enabled interface, automated and manual summarization is supported.
- VLSM and CIDR support.
- EIGRP routers communicate with one another through multicast using multicast IP 220.127.116.11.
- On EIGRP routers, MD5 authentication is supported.
- Supports various network layer protocols, including IP, IPX, AppleTalk, and even IPv6.
- For the creation of a neighborship under the EIGRP, three criteria must be met:
- The IP subnets of neighbor routers should be the same.
- The Autonomous System number should be the same.
- Metrics that are same (K1, K2, K3, K4 & K5 values should match between both the neighbor routers)
- The maximum hop count for EIGRP is 255. (by default is set to 100).
- EIGRP generates three distinct tables: a neighbor table, a topology table, and a routing table.
- EIGRP provides load balancing across equal cost (up to 32 equal cost paths, with the default being 4) and un-equal cost paths.