Lesson Contents
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.255
R2(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.255
Everything 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, Loopback0
For 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 set
I 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, Loopback0
R2 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 list
A 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 set
R2 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-summary
Let’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 out
And 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/0
There 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.
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.0
R2(config)#router eigrp 12
R2(config-router)#network 192.168.12.0
R2(config-router)#network 10.0.0.0
It’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, Null0
R2#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, Null0
Looking 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 on
Now I’ll reset the neighbor adjacency so that the routers exchange routes again:
R2#clear ip eigrp 12 neighbors
Here’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/0
Here’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-summary
R2#show run | section eigrp
router eigrp 12
network 10.0.0.0
network 192.168.12.0
auto-summary
As 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-summary
R2(config)#router eigrp 12
R2(config-router)#no auto-summary
Now 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, Loopback0
R2#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/0
Now 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-summary
R2#
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-summary
You 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 5
Someone 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, Loopback0
However 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 on
R2#clear ip eigrp 12 neighbors
I’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/0
Looking 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 on
Here’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.2
We 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 1
Above 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-summary
Now 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, Loopback0
There 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-summary
R2#
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-summary
All 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 5
This 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/0
Unfortunately 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 on
R2#clear ip eigrp 12 neighbors
When 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/0
Hmm 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/0
One 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 down
Uhoh…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 shutdown
If 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/0
Now 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/0
Now 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.
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.0
Spoke1(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.255
Spoke2(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.255
As 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/0
Our 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, Loopback0
Unfortunately 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 on
We’ll reset the neighbor adjacencies to force the routers to send the route advertisements again:
Hub#clear ip eigrp 123 neighbors
Here’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/0
In 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 123
Let’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/0
Now 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/0
Spoke2#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, Loopback0
The 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)
Hi Rene,
What does the number 5 mean in the show information above ?
And what about leak-map ? when do we use it ?
thanks.
Hi Hussein,
The “5” here is the administrative distance of the summary.
The leak-map option can be used to “leak” certain prefixes from your example. You can use this to advertise a prefix that normally falls within the range of your summary.
For example, let’s say you want to advertise summary 172.16.0.0/16 but also one specifix prefix, 172.16.1.0/24. You can use the leak map to get 172.16.1.0/24 “out” of the summary so that it can be advertised.
Rene
Hi Renee,
I didn’t see a topic on this. But is there a way to perform preferred route selection based on a source prefix from the local router? For example lets say I have a router that has two equal cost paths to a network. Let’s say this router has three prefixes it is advertising too. Lets say that only for one prefix will choose one explicit path and the other two prefixes will still use equal load balancing. The config should be made on the local router advertising the prefixes. Can this be done with EIGRP?
Hi Mario,
Routers normally only care about the destination, that’s it.
If you want to make routing decisions based on the source then you can use policy based routing, take a look here:
How to configure policy based routing
Rene
I don’t think this statement is true or at least its not in the perspective i am thinking about it:
“Lesson learned: When you redistribute something into EIGRP you need to configure seed metrics.”
I injected a static route into EIGRP in production and it worked and I did not add any metrics at all.
I basically have talked about it before but I just added a route-map and used a match statement and it showed up in EIGRP on the other router and everything worked great. Before I tried it on production I built a GNS3 lab and tested it.
So am I not understanding co
... Continue reading in our forum