Troubleshooting EIGRP Route Advertisement
EIGRP (just like OSPF or BGP) establishes a neighbor adjacency before it exchanges any routing information. If your neighbor adjacency is up and running, this post is for you. If it’s not working, check out my troubleshooting EIGRP neighbor adjacency lesson first.
Having said that, let’s fix some missing route advertisements!
Most of the time you are expecting to see a certain network in the routing table but it’s not there. I’ll show you a number of things that could go wrong with EIGRP and how to fix them, here are the most common errors:
- Someone configured a distribute-list so routing information is being filtered.
- Auto-summarization has been configured or someone created a manual summary.
- Split-horizon is preventing the advertisement of routing information.
- Redistribution has been configured but information from EIGRP is not being used.
- Redistribution has been configured but no EIGRP external routes are showing up.
Let’s look at these issues.
EIGRP Distribute-List
Let’s start with a simple topology. R1 and R2 are running EIGRP and each router has a loopback interface. Here’s the configuration of both routers:
R1(config)#router eigrp 12
R1(config-router)#no auto-summary
R1(config-router)#network 1.1.1.0 0.0.0.255
R1(config-router)#network 192.168.12.0 0.0.0.255R2(config)#router eigrp 12
R2(config-router)#no auto-summary
R2(config-router)#network 2.2.2.0 0.0.0.255
R2(config-router)#network 192.168.12.0 0.0.0.255Everything is working fine until a couple of weeks later one of the users is complaining that they are unable to reach the 2.2.2.0 /24 network from behind R1. You take a look at the routing table on R1 and this is what you see:
R1#show ip route
Gateway of last resort is not set
C 192.168.12.0/24 is directly connected, FastEthernet0/0
1.0.0.0/24 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, Loopback0For some reason you don’t see network 2.2.2.0 /24 in the routing table. Let’s check if R1 is using a filter:
R1#show ip protocols | include filter
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not setI can see no distribute lists have been configured on R1. What about R2? Let’s check its routing table:
R2#show ip route
Gateway of last resort is not set
C 192.168.12.0/24 is directly connected, FastEthernet0/0
1.0.0.0/24 is subnetted, 1 subnets
D 1.1.1.0 [90/156160] via 192.168.12.1, 00:14:01, FastEthernet0/0
2.0.0.0/24 is subnetted, 1 subnets
C 2.2.2.0 is directly connected, Loopback0R2 does have network 1.1.1.0 /24 in its routing table and 2.2.2.0 /24 is showing up as directly connected. Let’s do a quick debug to see what is going on.
R2#debug ip eigrp
IP-EIGRP Route Events debugging is on
IP-EIGRP(Default-IP-Routing-Table:12): 2.2.2.0/24 - denied by distribute listA debug quickly shows us what is going on. It make tight a while before you see this message or you can reset the EIGRP neighbor adjacency to speed things up. As you can see network 2.2.2.0 /24 is being denied because of a distribute list. You can see it here:
R2#show ip protocols | include filter
Outgoing update filter list for all interfaces is 1
Incoming update filter list for all interfaces is not setR2 has an outbound distribute-list that refers to access-list 1. You can also see this in the configuration:
R2#show run | section eigrp
router eigrp 12
network 2.2.2.0 0.0.0.255
network 192.168.12.0
distribute-list 1 out
no auto-summaryLet’s take a closer look at the access-list:
R2#show access-lists
Standard IP access list 1
10 deny 2.2.2.0, wildcard bits 0.0.0.255 (5 matches)
20 permit any (5 matches)It’s denying 2.2.2.0 /24. Let’s get rid of this distribute-list:
R2(config)#router eigrp 12
R2(config-router)#no distribute-list 1 outAnd now we take a look at R1 again:
R1#show ip route
Gateway of last resort is not set
C 192.168.12.0/24 is directly connected, FastEthernet0/0
1.0.0.0/24 is subnetted, 1 subnets
C 1.1.1.0 is directly connected, Loopback0
2.0.0.0/24 is subnetted, 1 subnets
D 2.2.2.0 [90/156160] via 192.168.12.2, 00:00:13, FastEthernet0/0There it is, problem solved!
Lesson learned: If the network commands are correct, check if you have a distribute-list that is preventing prefixes from being advertised or installed in the routing table.
Keep in mind that distribute-lists can be applied in- or outbound.
EIGRP Discontiguous Network
Onto the next scenario, same two routers but different networks on the loopbacks:
Below you will find the network commands on R1 and R2:
R1(config)#router eigrp 12
R1(config-router)#network 192.168.12.0
R1(config-router)#network 10.0.0.0R2(config)#router eigrp 12
R2(config-router)#network 192.168.12.0
R2(config-router)#network 10.0.0.0It’s a pretty basic configuration as you can see. Let’s check the routing tables:
R1#show ip route
Gateway of last resort is not set
C 192.168.12.0/24 is directly connected, FastEthernet0/0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.1.1.0/24 is directly connected, Loopback0
D 10.0.0.0/8 is a summary, 00:00:07, Null0R2#show ip route
Gateway of last resort is not set
C 192.168.12.0/24 is directly connected, FastEthernet0/0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.2.2.0/24 is directly connected, Loopback0
D 10.0.0.0/8 is a summary, 00:00:15, Null0Looking at the routing tables, I don’t see network 10.1.1.0 /24 or 10.2.2.0 /24. I do see an entry for the 10.0.0.0/8 network pointing to the null0 interface on both routers. This entry only shows up when summarization is configured and it’s used to prevent routing loops. Let’s enable a debug:
R2#debug ip eigrp
IP-EIGRP Route Events debugging is onNow I’ll reset the neighbor adjacency so that the routers exchange routes again:
R2#clear ip eigrp 12 neighborsHere’s what you will see on R2:
R2#
IP-EIGRP(Default-IP-Routing-Table:12): 192.168.12.0/24 - do advertise out FastEthernet0/0
IP-EIGRP(Default-IP-Routing-Table:12): 10.2.2.0/24 - don't advertise out FastEthernet0/0
IP-EIGRP(Default-IP-Routing-Table:12): 10.0.0.0/8 - do advertise out FastEthernet0/0Here’s our answer. The debug tells us that 10.2.2.0 /24 should not be advertised but 10.0.0.0 /8 has to be advertised (a summary). This can happen because of 2 reasons:
- Summarization was configured by someone.
- Auto-summary is enabled for EIGRP.
Let’s see take a closer look at the configuration:
R1#show run | section eigrp
router eigrp 12
network 10.0.0.0
network 192.168.12.0
auto-summaryR2#show run | section eigrp
router eigrp 12
network 10.0.0.0
network 192.168.12.0
auto-summaryAs you can see auto-summary is enabled for EIGRP. Depending on the IOS version this is enabled or disabled by default. Let’s disable it:
R1(config)#router eigrp 12
R1(config-router)#no auto-summaryR2(config)#router eigrp 12
R2(config-router)#no auto-summaryNow take a look at the routing tables:
R1#show ip route
C 192.168.12.0/24 is directly connected, FastEthernet0/0
10.0.0.0/24 is subnetted, 2 subnets
D 10.2.2.0 [90/156160] via 192.168.12.2, 00:00:22, FastEthernet0/0
C 10.1.1.0 is directly connected, Loopback0R2#show ip route
C 192.168.12.0/24 is directly connected, FastEthernet0/0
10.0.0.0/24 is subnetted, 2 subnets
C 10.2.2.0 is directly connected, Loopback0
D 10.1.1.0 [90/156160] via 192.168.12.1, 00:16:24, FastEthernet0/0Now we see both networks appearing in the routing table.
Lesson learned: If EIGRP auto-summary is enabled you might end up with discontiguous networks.
EIGRP Summarization
Let me show you another issue that can arise with summarization. In the example above we have 2 routers but different networks:
R1 has network 172.16.1.0 /24 on a loopback interface and R2 has network 172.16.2.0 /24 and 172.16.22.0 /24 on its loopback interfaces. Let me show you the EIGRP configuration of both routers:
R1#
router eigrp 12
network 172.16.1.0 0.0.0.255
network 192.168.12.0
auto-summaryR2#
router eigrp 12
network 172.16.2.0 0.0.0.255
network 172.16.22.0 0.0.0.255
network 192.168.12.0
no auto-summaryYou can see that all networks are advertised. Note that R1 has auto-summary enabled and R2 has auto-summary disabled. R2 has a summary configured:
R2#
interface FastEthernet0/0
ip summary-address eigrp 12 172.16.0.0 255.255.0.0 5Someone configured a summary on R2 and is sending it towards R1. The summary that was created is 172.16.0.0 /16. Let’s take a look at the routing table of R1:
R1#show ip route
C 192.168.12.0/24 is directly connected, FastEthernet0/0
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
D 172.16.0.0/16 is a summary, 00:30:07, Null0
C 172.16.1.0/24 is directly connected, Loopback0However if I look at the routing table of R1 it doesn’t show up. We do see an entry for the 172.16.0.0 /16 network but it’s pointing to the null0 interface…not towards R2. What is going on here? A debug gives us the answer:
R2#debug ip eigrp
IP-EIGRP Route Events debugging is onR2#clear ip eigrp 12 neighborsI’ll do a clear ip eigrp neighbors too just to speed things up. Here’s what we see:
R2#
IP-EIGRP(Default-IP-Routing-Table:12): 192.168.12.0/24 - do advertise out FastEthernet0/0
IP-EIGRP(Default-IP-Routing-Table:12): 172.16.2.0/24 - don't advertise out FastEthernet0/0
IP-EIGRP(Default-IP-Routing-Table:12): 172.16.22.0/24 - don't advertise out FastEthernet0/0
IP-EIGRP(Default-IP-Routing-Table:12): 172.16.0.0/16 - do advertise out FastEthernet0/0Looking at the debug we can see that R2 is working properly. It’s advertising the 172.16.0.0 /16 summary route as it should. This means the problem has to be at R1.
Let’s debug R1:
R1#debug ip eigrp
IP-EIGRP Route Events debugging is onHere’s what we see:
R1#
IP-EIGRP(Default-IP-Routing-Table:12): Processing incoming UPDATE packet
IP-EIGRP(Default-IP-Routing-Table:12): Int 172.16.0.0/16 M 156160 - 25600 130560 SM 128256 - 256 128000
IP-EIGRP(Default-IP-Routing-Table:12): route installed for 172.16.0.0 (Summary)
IP-EIGRP(Default-IP-Routing-Table:12): 172.16.0.0/16 routing table not updated thru 192.168.12.2We can see that R1 receives the summary route from R2 but decides not to use it. Why? We can find the answer in the topology table:
R1#show ip eigrp topology 172.16.0.0
IP-EIGRP (AS 12): Topology entry for 172.16.0.0/16
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 128256
Routing Descriptor Blocks:
0.0.0.0 (Null0), from 0.0.0.0, Send flag is 0x0
Composite metric is (128256/0), Route is Internal
Vector metric:
Minimum bandwidth is 10000000 Kbit
Total delay is 5000 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1514
Hop count is 0
192.168.12.2 (FastEthernet0/0), from 192.168.12.2, Send flag is 0x0
Composite metric is (156160/128256), Route is Internal
Vector metric:
Minimum bandwidth is 100000 Kbit
Total delay is 5100 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1Above you can see that it does have the 172.16.0.0 /16 summary from R2 in its EIGRP topology table but R1 decides not to use it because the entry to the null0 interface is a better path. To fix this issue, we should get rid of the null0 route. Disabling auto-summary will do the job:
R1(config)#router eigrp 12
R1(config-router)#no auto-summaryNow take a look again at the routing table of R1:
R1#show ip route
C 192.168.12.0/24 is directly connected, FastEthernet0/0
172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
D 172.16.0.0/16 [90/156160] via 192.168.12.2, 00:00:51, FastEthernet0/0
C 172.16.1.0/24 is directly connected, Loopback0There we go. Disabling auto summarization removes the null0 entry and now the summary of R2 can be installed…problem solved!
Lesson learned: EIGRP auto-summary creates an entry to the null0 interface which might prevent the installation of summaries you receive from neighbor routers.
EIGRP Summary not advertised
There is one more summarization issue I want to show you, here’s the topology:
Here’s the configuration:
R1#
router eigrp 12
network 192.168.12.0
no auto-summaryR2#
router eigrp 12
network 172.16.2.0 0.0.0.255
network 172.16.22.0 0.0.0.255
network 192.168.12.0
no auto-summaryAll networks are advertised and auto summarization is disabled on both routers. R2 has a summary:
R2#
interface FastEthernet0/0
ip summary-address eigrp 12 172.16.0.0 255.255.0.0 5This summary will be advertised to R1. However, R1 doesn’t have it:
R1#show ip route
C 192.168.12.0/24 is directly connected, FastEthernet0/0Unfortunately I’m not seeing anything on R1. Let’s check R2 to see what is wrong:
R2#debug ip eigrp
IP-EIGRP Route Events debugging is onR2#clear ip eigrp 12 neighborsWhen it comes to troubleshooting networking not Google but debug and show commands are your friends. Here’s what we see:
R2#
IP-EIGRP(Default-IP-Routing-Table:12): 192.168.12.0/24 - do advertise out FastEthernet0/0Hmm this is the only network that R2 is advertising. Let’s check the routing table of R2:
R2#show ip route
C 192.168.12.0/24 is directly connected, FastEthernet0/0One of the golden rules of routing: You can’t advertise what you don’t have. Apparently R2 only knows about network 192.168.12.0 /24. Let’s check the interface:
R2#show ip interface brief
Interface IP-Address OK? Method Status Protocol
FastEthernet0/0 192.168.12.2 YES manual up up
Loopback0 172.16.2.2 YES manual administratively down down
Loopback1 172.16.22.22 YES manual administratively down downUhoh…this looks like a Friday afternoon error! Someone left a shutdown command on the loopback interfaces. Let’s enable them:
R2(config)#interface loopback 0
R2(config-if)#no shutdown
R2(config)#interface loopback 1
R2(config-if)#no shutdownIf you left the debug enabled then you’ll see the route advertisement:
R2#
IP-EIGRP(Default-IP-Routing-Table:12): 172.16.2.0/24 - don't advertise out FastEthernet0/0
IP-EIGRP(Default-IP-Routing-Table:12): 172.16.22.0/24 - don't advertise out FastEthernet0/0
IP-EIGRP(Default-IP-Routing-Table:12): 172.16.0.0/16 - do advertise out FastEthernet0/0Now we see that the summary is being advertised. Here’s the routing table of R1:
R1#show ip route | include 172.16.0.0
D 172.16.0.0/16 [90/156160] via 192.168.12.2, 00:09:39, FastEthernet0/0Now we see the summary in the routing table of R1, problem solved!
Lesson learned: You can’t advertise wat you don’t have in your routing table.
The last problem might be simple but there’s an important lesson you should not forget: In order for a summary route to be advertised at least one prefix that falls within the summary range has to be in the routing table of the advertising router!
EIGRP Split Horizon
Here’s something new for you, a different topology:
In the picture above we have a frame-relay hub and spoke topology. Spoke1 and Spoke2 each have a loopback interface which we will advertise in EIGRP. Here’s the relevant configuration of all routers:
Hub(config)#router eigrp 123
Hub(config-router)#no auto-summary
Hub(config-router)#network 192.168.123.0Spoke1(config-if)#router eigrp 123
Spoke1(config-router)#no auto-summary
Spoke1(config-router)#network 192.168.123.0
Spoke1(config-router)#network 2.2.2.0 0.0.0.255Spoke2(config)#router eigrp 123
Spoke2(config-router)#no auto-summary
Spoke2(config-router)#network 192.168.123.0
Spoke2(config-router)#network 3.3.3.0 0.0.0.255As you can see all networks are advertised. Let’s check the routing tables…we’ll start with the hub router:
Hub#show ip route
C 192.168.123.0/24 is directly connected, Serial0/0
2.0.0.0/24 is subnetted, 1 subnets
D 2.2.2.0 [90/2297856] via 192.168.123.2, 00:00:11, Serial0/0
3.0.0.0/24 is subnetted, 1 subnets
D 3.3.3.0 [90/2297856] via 192.168.123.3, 00:00:03, Serial0/0Our hub router sees the networks of the 2 spoke routers. What about the spokes?
Spoke1#show ip route
C 192.168.123.0/24 is directly connected, Serial0/0
2.0.0.0/24 is subnetted, 1 subnets
C 2.2.2.0 is directly connected, Loopback0 Spoke2#show ip route
C 192.168.123.0/24 is directly connected, Serial0/0
3.0.0.0/24 is subnetted, 1 subnets
C 3.3.3.0 is directly connected, Loopback0Unfortunately our spoke routers don’t see anything…what’s going on here? Let’s enable a debug:
Hub#debug ip eigrp
IP-EIGRP Route Events debugging is onWe’ll reset the neighbor adjacencies to force the routers to send the route advertisements again:
Hub#clear ip eigrp 123 neighborsHere’s what you will see:
R1# processing incoming UPDATE packet
IP-EIGRP(Default-IP-Routing-Table:123): Processing incoming UPDATE packet
IP-EIGRP(Default-IP-Routing-Table:123): Int 3.3.3.0/24 metric 2297856 - 1657856 640000
IP-EIGRP(Default-IP-Routing-Table:123): Processing incoming UPDATE packet
IP-EIGRP(Default-IP-Routing-Table:123): Int 2.2.2.0/24 M 2297856 - 1657856 640000 SM 128256 - 256 128000
IP-EIGRP(Default-IP-Routing-Table:123): route installed for 2.2.2.0 ()
IP-EIGRP(Default-IP-Routing-Table:123): 192.168.123.0/24 - do advertise out Serial0/0In the debug we can see that our Hub router learns about network 2.2.2.0 /24 and 3.3.3.0 /24 but only advertises network 192.168.123.0 /24 to the spoke routers. Split horizon is preventing the advertisements from one spoke router to another. (If you learn something on an interface…don’t advertise it out of the same interface again). Let’s disable split horizon:
Hub(config)#interface Serial 0/0
Hub(config-if)#no ip split-horizon eigrp 123Let’s disable split horizon on the serial interface of the Hub router. Take a look at the debug of the hub router now:
Hub#
IP-EIGRP(Default-IP-Routing-Table:123): 192.168.123.0/24 - do advertise out Serial0/0
IP-EIGRP(Default-IP-Routing-Table:123): 3.3.3.0/24 - do advertise out Serial0/0
IP-EIGRP(Default-IP-Routing-Table:123): 2.2.2.0/24 - do advertise out Serial0/0Now we can see that the Hub router does advertise all networks. Let’s see if the spoke routers installed the routes:
Spoke1#show ip route
C 192.168.123.0/24 is directly connected, Serial0/0
2.0.0.0/24 is subnetted, 1 subnets
C 2.2.2.0 is directly connected, Loopback0
3.0.0.0/24 is subnetted, 1 subnets
D 3.3.3.0 [90/2809856] via 192.168.123.1, 00:16:02, Serial0/0Spoke2#show ip route
C 192.168.123.0/24 is directly connected, Serial0/0
2.0.0.0/24 is subnetted, 1 subnets
D 2.2.2.0 [90/2809856] via 192.168.123.1, 00:16:33, Serial0/0
3.0.0.0/24 is subnetted, 1 subnets
C 3.3.3.0 is directly connected, Loopback0The spoke routers can now learn about each other’s networks since split horizon has been disabled. This is looking good but we are not done yet. Lesson learned: RIP and EIGRP are distance vector routing protocols and use split horizon. Split horizon prevents the advertisement of a prefix out of the interface where we learned it on.
Even though we solved this problem, there is still another issue we have to deal with. Take a look at these pings:
Spoke1#ping 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)Spoke2#ping 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)Even though the networks show up in the routing tables I’m unable to ping from one spoke router to another. This is not an EIGRP problem but it’s related to frame-relay…we still have to fix it though.
When Spoke1 sends an IP packet to Spoke2 the IP packet looks like this:
First we need to check if Spoke1 knows where to send 3.3.3.3 to:
Spoke1#show ip route 3.3.3.3
Routing entry for 3.3.3.0/24
Known via "eigrp 123", distance 90, metric 2809856, type internal
Redistributing via eigrp 123
Last update from 192.168.123.1 on Serial0/0, 00:38:10 ago
Routing Descriptor Blocks:
* 192.168.123.1, from 192.168.123.1, 00:38:10 ago, via Serial0/0
Route metric is 2809856, traffic share count is 1
Total delay is 45000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2There’s an entry for 3.3.3.3 and the next hop IP address is 192.168.123.1 (Hub router). Are we able to reach 192.168.123.1?
Spoke1#ping 192.168.123.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.123.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/8 msNo problem at all, it seems Spoke1 is able to forward packets meant for network 3.3.3.0 /24. Let’s go to the Hub router:
Hub#ping 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/4 msThe Hub router has no issues sending traffic to network 3.3.3.0 /24 so at this moment we can draw the conclusion that the problem must be at router Spoke2. Take a look at the IP packet below:
This is the IP packet that router Spoke2 receives, when it responds it will create a new IP packet that looks like this:
Is spoke2 able to reach IP address 192.168.123.2? Time to find out!
Spoke2#ping 192.168.123.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.123.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)Now we know the problem…Spoke2 is unable to reach IP address 192.168.123.2. What is the issue?
Spoke2#show ip route | include 192.168.123.0
C 192.168.123.0/24 is directly connected, Serial0/0If we look at the routing table of Spoke2 we can see that network 192.168.123.0 /24 is directly connected. From a layer 3 perspective we don’t have any issues. Time to move down the OSI model and check layer 2…or maybe in between layer 2 and 3:
Spoke2#show frame-relay map
Serial0/0 (up): ip 192.168.123.1 dlci 301(0x12D,0x48D0), dynamic,
broadcast,, status defined, activeFrame-relay uses Inverse ARP to bind layer 2 (DLCI) to layer 3 (IP address). You can see that there is no mapping for IP address 192.168.123.2. Let’s add one:
Spoke2(config)#interface Serial 0/0
Spoke2(config-if)#frame-relay map ip 192.168.123.2 301Now check the frame-relay mappings again:
Spoke2#show frame-relay map
Serial0/0 (up): ip 192.168.123.1 dlci 301(0x12D,0x48D0), dynamic,
broadcast,, status defined, active
Serial0/0 (up): ip 192.168.123.2 dlci 301(0x12D,0x48D0), static,
CISCO, status defined, activeNow router Spoke2 knows how to reach router Spoke1:
Spoke1#ping 3.3.3.3
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/10/16 msFinally router Spoke1 is able to ping router Spoke2’s loopback interface. When we try to ping from router Spoke2 to router Spoke1’s loopback interface we’ll have the same issue so we’ll add a frame-relay map statement there as well:
Spoke1(config)#interface Serial 0/0
Spoke1(config-if)#frame-relay map ip 192.168.123.3 201 Spoke1#show frame-relay map
Serial0/0 (up): ip 192.168.123.1 dlci 201(0xC9,0x3090), dynamic,
broadcast,, status defined, active
Serial0/0 (up): ip 192.168.123.3 dlci 201(0xC9,0x3090), static,
CISCO, status defined, activeNow we have an extra frame-relay mapping on router Spoke1. Let’s try to ping 2.2.2.2 from Spoke2:
Spoke2#ping 2.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/8/8 msAnd our ping is successful! Lesson learned: Make sure the next hop IP address is reachable and if needed add additional frame-relay map statements.
We just got a little sidetracked from EIGRP to solving frame-relay problems but that’s what network engineers do…sometimes troubleshooting is a deadly cocktail of multiple protocols. Another method of dealing with split-horizon is changing the point-to-multipoint configuration to a point-to-point configuration.
EIGRP Redistribution Sub-Optimal Routing
Here’s a totally different scenario for you:
In the picture above R1 and R2 are running EIGRP AS 12. All routers are running RIP. R3 has a loopback interface with network 3.3.3.0 /24 that will be advertised in RIP. R2 is going to redistribute this network into EIGRP AS 12.
Here are the EIGRP and RIP configurations of all routers:
R1#
router eigrp 12
network 192.168.12.0
no auto-summary
!
router rip
version 2
network 192.168.13.0
no auto-summary R2#
router eigrp 12
redistribute rip metric 1 1 1 1 1500
network 192.168.12.0
no auto-summary
!
router rip
version 2
redistribute eigrp 12 metric 5
network 192.168.23.0
no auto-summaryR3#
router rip
version 2
network 3.0.0.0
network 192.168.13.0
network 192.168.23.0
no auto-summaryNote that R2 has been configured for redistribution between EIGRP AS 12 and RIP. How does this influence our routing selections? Let’s take a look:
R1#show ip route 3.3.3.0
Routing entry for 3.3.3.0/24
Known via "rip", distance 120, metric 1
Redistributing via rip
Last update from 192.168.13.3 on Serial1/0, 00:00:06 ago
Routing Descriptor Blocks:
* 192.168.13.3, from 192.168.13.3, 00:00:06 ago, via Serial1/0
Route metric is 1, traffic share count is 1R1 is sending traffic towards network 3.3.3.0 /24 using the serial link between R1 and R3. It would have been better if we would use the link between R1 and R2 because using the FastEthernet links is faster than the serial link. Take a look below:
R1#show ip eigrp topology 3.3.3.0 255.255.255.0
IP-EIGRP (AS 12): Topology entry for 3.3.3.0/24
State is Passive, Query origin flag is 1, 0 Successor(s), FD is 4294967295
Routing Descriptor Blocks:
192.168.12.2 (FastEthernet0/0), from 192.168.12.2, Send flag is 0x0
Composite metric is (2560002816/2560000256), Route is ExternalWe can look at the EIGRP topology table and see that R1 did learn about network 3.3.3.0 /24 through EIGRP from R2. So why are not we using this information instead of RIP?
The problem here is that EIGRP external routes has an AD (administrative distance) of 170 while RIP has an AD of 120.
We can fix this problem by changing the AD:
R1(config)#router rip
R1(config-router)#distance 175 192.168.13.3 0.0.0.0In the example above I’m setting the AD to 175 for all RIP routes that we learn from IP address 192.168.13.3 (R3). Now check the routing table of R1 again:
R1#show ip route 3.3.3.0
Routing entry for 3.3.3.0/24
Known via "eigrp 12", distance 170, metric 2560002816, type external
Redistributing via eigrp 12
Last update from 192.168.12.2 on FastEthernet0/0, 00:17:53 agoR1#show ip route | include 3.3.3.0
D EX 3.3.3.0 [170/2560002816] via 192.168.12.2, 00:18:46, FastEthernet0/0Since the AD of EIGRP external (170) is lower than the AD of my RIP routes (175) R1 will install the EIGRP external information. We are now using the FastEthernet links to get to network 3.3.3.0 /24…problem solved!
Lesson learned: Change the administrative distance to change traffic patterns but be aware; In more complex topologies this can also cause routing loops.
Redistribution is a complex topic, if you want to learn a bit more about this then you might want to read my “metric related distribution issues” lesson.
EIGRP Redistribution Seed Metric
Here’s another redistribution issue for you, we have a different topology:
I have another redistribution situation for you. There are 3 routers and R2 is the router performing the redistribution between EIGRP AS 12 and RIP. Here are the configurations:
R1#
router eigrp 12
network 192.168.12.0
no auto-summaryR2#
router eigrp 12
redistribute rip
network 192.168.12.0
no auto-summary
!
router rip
version 2
redistribute eigrp 12 metric 1
network 192.168.23.0
no auto-summaryR3#
router rip
version 2
network 3.0.0.0
network 192.168.23.0
no auto-summaryAs you can see R1 is running EIGRP, R2 is running RIP and EIGRP and is doing redistribution, R3 is only running RIP. Take a look at the routing table of R1:
R1#show ip route
C 192.168.12.0/24 is directly connected, FastEthernet0/0I’m expecting to see some redistributed routes. Unfortunately there’s nothing here. What’s going on? Let’s check R2:
R2#show ip route rip
3.0.0.0/24 is subnetted, 1 subnets
R 3.3.3.0 [120/1] via 192.168.23.3, 00:00:23, FastEthernet1/0R2 is the router performing the redistribution and we can see that it has learned network 3.3.3.0 /24 through RIP. It should be redistributing this network into EIGRP.
Is it in the topology table?
R2#show ip eigrp topology 3.3.3.0 255.255.255.0
% IP-EIGRP (AS 12): Route not in topology tableHmm network 3.3.3.0 /24 is not in the EIGRP topology table of R2 even though we configured redistribution, let’s check the redistribution configuration:
R2#
router eigrp 12
redistribute rip
network 192.168.12.0
no auto-summaryWe do have the redistribute rip command but there’s no default seed metric. If you don’t specify a metric then the default seed metric will be infinite. In other words it’s unreachable. Let’s configure a seed metric:
R2(config)#router eigrp 12
R2(config-router)#default-metric 1500 100 255 1 1500You need to specify the bandwidth, delay, load and reliability yourself. I just used some random values. Now take a look at R2 again:
R2#show ip eigrp topology 3.3.3.0 255.255.255.0
IP-EIGRP (AS 12): Topology entry for 3.3.3.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 1732096
Routing Descriptor Blocks:
192.168.23.3, from Redistributed, Send flag is 0x0
Composite metric is (1732096/0), Route is ExternalNow we see the 3.3.3.0 /24 network in the EIGRP topology table of R2. R1 should now be able to learn it:
R1#show ip route | include 3.3.3.0
D EX 3.3.3.0 [170/1734656] via 192.168.12.2, 00:04:08, FastEthernet0/0And as a result it can be advertised to R1…problem solved!
Lesson learned: When you redistribute a routing protocol into EIGRP you need to configure seed metrics.
That’s all I have for you, this should cover most of the “route advertisement” issues that you might encounter with EIGRP. I hope this has been helpful and if you have any questions, feel free to leave a comment!
Table of Contents
Unit 2: EIGRP Neighbor Adjacency
Unit 4: EIGRP Advanced Features