Implementing EIGRP Routing Protocol: Explanation and Tutorial
EIGRP stand for Enhanced Interior Gateway Routing Protocol and is an advanced distance-vector routing protocol that is used on a computer network for automating routing decisions and configuration
The issue with EIGRP 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: 224.0.0.100 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 this 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 parameter, it has the best of all worlds (DV).
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.
ON THIS PAGE: Implementing EIGRP Routing Protocol: Explanation and Tutorial
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:
- VLSM or CIDR support is available.
- Discontinuous networks and summarization
- The DUAL has the best route variety.
- We no longer use broadcast; now, we now use multicast.
- IPv4 and IPv6 are supported.
- Discovering neighbours quickly and efficiently
DUAL stands for Diffusing Update Algorithm.[ps2id id='DUAL stands for Diffusing Update Algorithm.' target=''/]
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:
- If the topology allows, it finds a backup path.
- VLSM Dynamic Path Recovery is assisted.
- Check with its neighbours' routers to see if there are any other options.
READ MORE: Check out about BGP Protocol!
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:
- Under a certain time frame, neighbours are found or noted as deceased.
- Messages sent out should be accurately answered.
- Messages and modifications must be handled in the sequence in which they were issued.
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
Remember that this command is typed under interface configuration mode.
Configuring EIGRP[ps2id id='Configuring EIGRP' target=''/]
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 170Okay, 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/0It seems that EIGRP has found all our different networks and has applied the best metric to each destination. If you look closely at the routing table, you will see that two networks have multiple paths to it: 10.1.1.20 and 10.1.1.24. The path that it takes is determined by the router that is learning it.
So, what does that mean? EIGRP has two successor routes or two feasible distances that are equal, so they must go to the routing table. All other routes to include the successor routes will be in the topology table.
I have highlighted the networks that have the multiple paths, which means they can go in either direction, but EIGRP will load balance by default when it has multiple paths:
We need to see exactly which path it is taking to this network: 10.1.1.20. This is from the R4 viewpoint. It could go via 10.1.1.5 or 10.1.1.13, so let’s use the tools we have at hand, such as 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 msecSo, even if they have the identical metric of 2172416, it will choose the first path from top to bottom, to send the packet to the destination. If that path is shut down or is disconnected, it will still have an alternate route to get to the destination.
In your lab, if you followed the configuration exactly as I did it, you should get the same results. But, this is where your curiosity should come in. Shut down the 10.1.1.5 interface and see what happens. What will your routing table look like then? Will it have only one route to the destination or will it have more than one? Remember that when a successor route goes down, EIGRP will query the topology table to find an alternate route, but in this situation, will it do that, since an alternate route exists?
Let’s take a look:
R1(config)#int s0/0/0 R1(config-if)#shut
Now let’s take a look at the routing table from the R4 perspective.
The first thing that happens is the following:
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/0Only one route exists, which is 10.1.1.13. It had the same metric as 10.1.1.5. So, in this situation, there was no need to query the topology table, since an existing alternate route already existed in the routing table. But, let’s verify this with the traceroute command:
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) Since it only had one path to get to the 10.1.1.20 network, it was quicker in getting there, but when it had multiple paths, it took longer. Now I know we are talking about milliseconds, but still, it is a delay, none the less. So, what does this tell us? Redundancy is not always a good thing. This is a full-mesh topology, which is very costly and we are running into delays. So, be careful in your design of the network. There is such a thing as too much redundancy and you can easily create Layer 3 loops and delays. We looked at the routing table, but not the topology table, so I am going to turn on the s0/0/0 interface again and look at the routing table once more to make sure all is as it was and then look at the topology table. Almost immediately after turning on the s0/0/0 interface on R1, I receive the following message: 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 Notice that the first path in the network is through 10.1.1.13 and not 10.1.1.5, as before. Now let us look at the topology table:
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.
Thus, we discussed how EIGRP operates, its capabilities, and how to configure EIGRP for single and multiple autonomous systems in this Video.
i Hope you enjoy this, if you want more about networking (maybe you need to get any it certification like CCNA?) i suggest you to bookmark my website for don't miss anything
https://www.techguruhub.net/2021/05/07/eigrp-routing-protocol-explanation/?feed_id=62551&_unique_id=62920eba63a41
Comments
Post a Comment