Features of the routing protocol EIGRP
Hello! In this article I will talk about the interesting features of the routing protocol EIGRP.
The basics of EIGRP are perfectly described in one of the articles of the SDSM cycle: 6. Networks for the smallest Part six. Dynamic routing
In the first half of the article some facts about this protocol are briefly described, and in the second - some interesting examples with topology and commands.
Well, is it time to practice?
About this problem in networks like Hub-and-Spoke (Frame Relay, DMVPN) + EIGRP is written in almost every book. So why talk about it again, and even with an example, you ask? And let's look carefully, it is very easy to fall into a trap here. Consider the following topology of the Frame-Relay network:
You can download the topology with startup configuration files for GNS3 here . IOS image used: c3640-jk9s-mz.124-16.bin
Nothing much true? 2 virtual connections (PVC), one common network 192.168.123.0/24, everything works on physical interfaces, and not on sub-interfaces. Each router also has a Loopback address configured. EIGRP is enabled on all interfaces.
Let's look at the routing table on hub R1:
R1 has routes to all networks. And now on R2 spooke:
R2 for some reason has no route to the 3.3.3.0/24 network.
You probably already mentally shout: "What's wrong with that?" Obviously, it is necessary to disable the split horizon on the interface s0 / 0 of router R1! ”
Let's check with the show ip interface s0 / 0 command:
???
And at this moment you can easily get confused. That was a great guess!
But I still try the command no ip split-horizon eigrp 100 :
And now let's check the routing table:
ABOUT! There was a route.
Check ping:
Ping, everything is fine.
So what's the deal? Why did the show ip interface s0 / 0 command show that split horizon is disabled, if it was actually enabled? The answer is simple. This line only says that split horizon is disabled for RIP.
How then to look for EIGRP? Actually, nothing but the presence of a line in the current configuration:
By the way, IOS 15 has an opportunity to check this with the help of the show ip eigrp interfaces detail s0 / 0 command .
Here is such an interesting feature.
But, probably, the whole article was conceived solely for the sake of the following example.
Consider carefully the topology:
Download the topology file with the initial configuration for GNS3 here . IOS image used: c3640-jk9s-mz.124-16.bin.
4 routers, 2 routing domains: OSPF area 0 and EIGRP AS 100. Router R1 performs redistribution in both directions. Loopback0 R1 is announced in the EIGRP domain, Loopback1 R1 is not announced anywhere.
Let's look at the routing table of router R2:
Great, routes to ospf networks 172.16.x.0 / 24 are visible as D EX (EIGRP External, AD 170).
And now on the routing table R3:
???
Where are the routes to ospf networks?
Let's look at the neighbors of R1:
Everything is fine, right? And then, because R3 sees other EIGRP routes: for example, 2.2.2.0/24 and 1.1.1.0/24 . The next step would be logical to look at route mepes on R1 and R2. But in this example, I did not use them. If you don’t know what the reason is, then it’s difficult to solve this problem. So let's see what's the matter. On R1 and R3, we use the show ip eigrp topology command :
Yes, the problem is in the same eigrp router-id. There is one great command hidden in IOS (not visible with a "?") To help you understand what's going on: show ip eigrp events on R3.
[This command can help with other problems with EIGRP]
We see that R3 still gets routes to 172.16.x.0 / 24 networks, but drops them due to duplicate router-id.
It turns out that, in general, EIGRP doesn't care what router-id you have in AS. Exactly until one of the routers with the same router-id has redistribution configured. Then the injected routes receive a special label from the router's router id, which made the redistribution. If the router receives a route with such a label and sees that its router-id matches, then such a route is discarded. Router-id is also defined as in OSPF: a special command or the highest Loopback address, or the highest IP address, if there is no Loopback.
In this case, on the R1 router there is Loopback1: 11/11/11/11 , and on R3, the eigrp router-id command was used on 11/11/11/11 . Cancel it with the no keyword and check the routing table again:
Routes appeared, the problem is solved!
In a real network, it is much more likely that the same Loopback addresses can be randomly configured on two routers. Having never heard of this problem, troubleshooting can turn into a fascinating activity and pull a lot of nerves.
If you feel that you know EIGRP well enough, then I recommend trying the GNS3Vault EIGRP Troubleshoot Lab .
This does not apply to EIGRP, but out of the three routing protocols EIGRP, OSPF, BGP, only EIGRP uses the key chain for authentication. Key chain allows you to use different keys at different times. For example, you can seamlessly change the EIGRP authentication password without crashing “adjacency”. But we look at a little more. This mechanism has an interesting feature. Surely everyone knows that the service password-encryption command uses a hacked algorithm (Type 7). On the Internet you can find many sites that will recover the password from such a hash. But it turns out that you can force the router to recover the password. Let me show you how. First, create a user with a password in the local database and enable service password-encryption :
Look at the running config and copy the hash value:
Now create the key chain , the key number and enter this hash:
And now use the show key chain command:
Cool, right? :)
Hope you enjoyed it!
The basics of EIGRP are perfectly described in one of the articles of the SDSM cycle: 6. Networks for the smallest Part six. Dynamic routing
In the first half of the article some facts about this protocol are briefly described, and in the second - some interesting examples with topology and commands.
EIGRP Facts
- In February 2013, Cisco decided to open EIGRP. It should be noted that it was not the source code that was discovered, but only the information necessary to implement the protocol. As a result, the RFC draft appeared. Last updated 10/04/2014. This document did not disclose a key feature - Stub, without which using the protocol is almost useless. The reaction of other vendors is interesting: to date, no one except Cisco has implemented support for this protocol in their equipment.
- EIGRP for calculating the metric uses 5 K-values, which are only modifiers (coefficients), and 4 metric values. Reliability and link loading (load) are dynamic parameters, so these values ​​are recalculated only when the network changes. K5 is an additional reliability factor, and it has no relation to MTU! I recall the general formula for calculating the metric:
')
And if K5 = 0, then the formula has the following form:
where min_bandwidth is the worst link throughput in kbps,
and total_delay is the sum of the delays of all links in ms (microseconds).
To change the metric, the delay is usually changed, since bandwidth affects QoS , besides, changing the bandwidth does not always change the metric (if the worst link has not changed).
The minimum MTU is indeed calculated, but takes no part in determining the best path. In my GNS3 topology, I tested dozens of times using the redistribute connected metric and maximum-paths 1 commands. Despite the different MTU value, the best path is chosen which was studied earlier. It is also interesting that in the RFC draft there is an additional factor K6 and 2 additional metric values: jitter and energy. - Feasibility Condition is not always easy to understand for the first time. But the logic is very simple: if you tell me that you have a metric more than the metric of my best path, then there is a chance that your path passes through me, which in turn means a loop. Because of this, often “path-free-loop” obvious to an engineer may not be considered by the protocol as feasible successors . Remember, EIGRP does not see the entire network - just what the neighbors are saying.
- EIGRP - Distance Vector protocol, there is no hybridity in it.
- With the help of show ip eigrp neighbors detail you can see if a neighbor is a stub router.
- Remember, with the show ip eigrp topology command , only successors and feasible successors are visible. To view all possible paths, you must add the "all-links" keyword: show ip eigrp topology all-links .
- In iOS 15, automatic automatic summatization is finally disabled, hurray! Goodbye no auto-summary command !
- Timer values ​​(hello and hold) may not be the same. By the way, the value of the hold timer is transmitted to the neighbor and means: “if you don’t receive hello from me for X seconds, then I’m no longer available.”
- EIGRP uses its own transport protocol (IP protocol number: 88) - RTP (Reliable Transport Protocol). Do not confuse it with another well-known Real-time Transport Protocol (also RTP), which is used to transmit real-time streams, such as VoIP (in conjunction with SIP). EIGRP also uses multicast address: 224.0.0.10. Do not forget to allow EIGRP traffic in the incoming ACL, for example, using the entry: permit eigrp any any .
- Because of the different administrative distance (AD) values ​​for internal (90) and external (170) routes, EIGRP avoids some of the problems during redistribution.
- Remember that 2 routers may be neighbors, and at the same time they may not have adjacency. With the show ip eigrp neighbors command , only neighbors are shown. In the output of this command, you should pay attention to the field of Q Cnt : if there is not zero, then it is quite possible that you have a problem in the network (for example, an unidentified adjacency).
- EIGRP, in addition to the summary route, can send a specific specific route. This feature is called EIGRP Leak Map . This is useful if we want to do traffic engineering. The idea is very similar to bgp unsuppress-map . To do this, use the following command: ip summary-address eigrp as-number summary-address summary-mask leak-map leak-map-route-map .
- As alk0v is rightly added, unlike OSPF, EIGRP supports load balancing with different metrics ( unequal cost load balancing ). To do this, use the variance command. There are two things to remember: it only works for successors / feasible successors and, by default, CEF performs per-destination balancing. The latter means that 2 packets that have the same IP addresses of the sender and the recipient are the same, will always go out from the same interface, which significantly complicates the verification. If you still want to check this, you can switch CEF to per-packet mode (in interface configuration mode, use the ip load-sharing per-packet command) or disable it altogether ( no ip cef command in global configuration mode, not recommended).
Well, is it time to practice?
EIGRP Split Horizon
About this problem in networks like Hub-and-Spoke (Frame Relay, DMVPN) + EIGRP is written in almost every book. So why talk about it again, and even with an example, you ask? And let's look carefully, it is very easy to fall into a trap here. Consider the following topology of the Frame-Relay network:
You can download the topology with startup configuration files for GNS3 here . IOS image used: c3640-jk9s-mz.124-16.bin
Nothing much true? 2 virtual connections (PVC), one common network 192.168.123.0/24, everything works on physical interfaces, and not on sub-interfaces. Each router also has a Loopback address configured. EIGRP is enabled on all interfaces.
Let's look at the routing table on hub R1:
R1 has routes to all networks. And now on R2 spooke:
R2 for some reason has no route to the 3.3.3.0/24 network.
You probably already mentally shout: "What's wrong with that?" Obviously, it is necessary to disable the split horizon on the interface s0 / 0 of router R1! ”
Let's check with the show ip interface s0 / 0 command:
???
And at this moment you can easily get confused. That was a great guess!
But I still try the command no ip split-horizon eigrp 100 :
And now let's check the routing table:
ABOUT! There was a route.
Check ping:
Ping, everything is fine.
So what's the deal? Why did the show ip interface s0 / 0 command show that split horizon is disabled, if it was actually enabled? The answer is simple. This line only says that split horizon is disabled for RIP.
How then to look for EIGRP? Actually, nothing but the presence of a line in the current configuration:
By the way, IOS 15 has an opportunity to check this with the help of the show ip eigrp interfaces detail s0 / 0 command .
Here is such an interesting feature.
But, probably, the whole article was conceived solely for the sake of the following example.
EIGRP Router-ID
Consider carefully the topology:
Download the topology file with the initial configuration for GNS3 here . IOS image used: c3640-jk9s-mz.124-16.bin.
4 routers, 2 routing domains: OSPF area 0 and EIGRP AS 100. Router R1 performs redistribution in both directions. Loopback0 R1 is announced in the EIGRP domain, Loopback1 R1 is not announced anywhere.
Let's look at the routing table of router R2:
Great, routes to ospf networks 172.16.x.0 / 24 are visible as D EX (EIGRP External, AD 170).
And now on the routing table R3:
???
Where are the routes to ospf networks?
Let's look at the neighbors of R1:
Everything is fine, right? And then, because R3 sees other EIGRP routes: for example, 2.2.2.0/24 and 1.1.1.0/24 . The next step would be logical to look at route mepes on R1 and R2. But in this example, I did not use them. If you don’t know what the reason is, then it’s difficult to solve this problem. So let's see what's the matter. On R1 and R3, we use the show ip eigrp topology command :
Yes, the problem is in the same eigrp router-id. There is one great command hidden in IOS (not visible with a "?") To help you understand what's going on: show ip eigrp events on R3.
[This command can help with other problems with EIGRP]
We see that R3 still gets routes to 172.16.x.0 / 24 networks, but drops them due to duplicate router-id.
It turns out that, in general, EIGRP doesn't care what router-id you have in AS. Exactly until one of the routers with the same router-id has redistribution configured. Then the injected routes receive a special label from the router's router id, which made the redistribution. If the router receives a route with such a label and sees that its router-id matches, then such a route is discarded. Router-id is also defined as in OSPF: a special command or the highest Loopback address, or the highest IP address, if there is no Loopback.
In this case, on the R1 router there is Loopback1: 11/11/11/11 , and on R3, the eigrp router-id command was used on 11/11/11/11 . Cancel it with the no keyword and check the routing table again:
Routes appeared, the problem is solved!
In a real network, it is much more likely that the same Loopback addresses can be randomly configured on two routers. Having never heard of this problem, troubleshooting can turn into a fascinating activity and pull a lot of nerves.
If you feel that you know EIGRP well enough, then I recommend trying the GNS3Vault EIGRP Troubleshoot Lab .
Bonus! Key chain
This does not apply to EIGRP, but out of the three routing protocols EIGRP, OSPF, BGP, only EIGRP uses the key chain for authentication. Key chain allows you to use different keys at different times. For example, you can seamlessly change the EIGRP authentication password without crashing “adjacency”. But we look at a little more. This mechanism has an interesting feature. Surely everyone knows that the service password-encryption command uses a hacked algorithm (Type 7). On the Internet you can find many sites that will recover the password from such a hash. But it turns out that you can force the router to recover the password. Let me show you how. First, create a user with a password in the local database and enable service password-encryption :
Look at the running config and copy the hash value:
Now create the key chain , the key number and enter this hash:
And now use the show key chain command:
Cool, right? :)
Hope you enjoyed it!
Source: https://habr.com/ru/post/224927/
All Articles