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

R1 R2 two loopbacks

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.

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:

R1 R2 discontigious network

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 R2 172.16 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:

R1 R2 loopback summarization issue

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.

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:

EIGRP Hub Spoke Split Horizon

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)
[teaser]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:

IP Packet source destination

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 2

There’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 ms

No 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 ms

The 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:

IP Packet source destination

This is the IP packet that router Spoke2 receives, when it responds it will create a new IP packet that looks like this:

ip-packet-source-destination-swapped

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/0

If 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, active

Frame-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 301

Now 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, active

Now 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 ms

Finally 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, active

Now 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 ms

And 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:

R1 R2 R3 EIGRP RIP Redistribution Troubleshooting

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-summary
R3# 
 router rip
 version 2
 network 3.0.0.0
 network 192.168.13.0
 network 192.168.23.0
 no auto-summary

Note 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 1

R1 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 External

We 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.0

In 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 ago
R1#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/0

Since 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:

r1-r2-r3-eigrp-rip-redistribution-troubleshooting2

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-summary
R2#
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-summary
R3#
router rip
 version 2
 network 3.0.0.0
 network 192.168.23.0
 no auto-summary

As 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/0

I’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/0

R2 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 table

Hmm 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-summary

We 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 1500

You 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 External

Now 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/0

And as a result it can be advertised to R1…problem solved!

Lesson learned: When you redistribute something 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![/MM_Access_Decision]

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 651 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

538 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Forum Replies

  1. Hi Rene,

    R2#
    interface FastEthernet0/0
    ip summary-address eigrp 12 172.16.0.0 255.255.0.0 5
    
     
    
    
    

    What does the number 5 mean in the show information above ?

     

    And what about leak-map ? when do we use it ?

     

    R1(config-if)#ip summary-address ei 1 172.16.0.0 255.255.254.0 ?
    leak-map Allow dynamic prefixes based on the leak-map
    <cr>
    

    thanks.

  2. 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

  3. 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?

  4. 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

Ask a question or join the discussion by visiting our Community Forum