Troubleshooting EIGRP Route Advertisement

Lessons Discussion
1

This topic is to discuss the following lesson:

2

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.

3

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

4

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?

5

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

6

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 correctly what that statemen5t means which is possible I am a bit crazy I am told.

7

Hello Brian

A clarification is needed here. Seed metrics are needed when redistributing routes from other routing protocols into EIGRP. The redistribution of static routes does not need any seed metrics. Similarly, when redistributing from one EIGRP process into another EIGRP process, metrics are not needed either.

I’ll ask @ReneMolenaar to clarify this in the lesson text.

I hope this has been helpful!

Laz

8

Thanks for clarifying I think that would be helpful as I ran into same issue with information on the internet its one of those things not clearly defined and made me very timid utilizing it in production. I never found anything anywhere saying seed metrics where not needed I got that from word of mouth from our architects and senior engineers who I had collaborated with before my change request.

1 Like
9

Hi,

Is there a command to confirm if split horizon is enabled/disabled for eigrp on an interface without using sh run command?

I’m doing some practice labs and disabled it on DMVPN hub tunnel interface, which worked. But when I issue a sh ip int Tu0 command it says…

sh ip int tu0
Tunnel0 is up, line protocol is up

 Split horizon is enabled

Thanks.

10

Hello Samir

Actually, that’s quite interesting. At first I thought it would be an issue with how the tunnel interface interprets split horizon commands, so I went into the lab to check it out.

It turns out that it has nothing to do with tunnel interfaces. I found that the output of the show ip interface command informs you about whether or not split horizon is enabled or disabled only for the RIP protocol. So if you issue the following command on your interface:

no ip split-horizon eigrp 1

split horizon will be disabled for EIGRP. This will not affect the output of the show ip interface command. It still states that split horizon is enabled. However, if you issue this command:

no ip split-horizon

which disables split horizon for the RIP protocol, then the output of the show ip interface command will show that split horizon is disabled.

This is really strange, and I believe Cisco should have resolved this, because it can be confusing. I searched command reference documentation such as that in the following link, but the only thing they say for the split horizon info is that it “Shows whether split horizon is enabled.”

So to answer your question, is there any way of determining the state of split horizon for EIGRP without looking at the running configuration? After doing a bit more experimentation in the lab, I found the following:

R1#show ip eigrp interfaces detail gigabitEthernet 0/1 
EIGRP-IPv4 Interfaces for AS(1)
                              Xmit Queue   PeerQ        Mean   Pacing Time   Multicast    Pending
Interface              Peers  Un/Reliable  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Gi0/1                    1        0/0       0/0           1       0/0           50           0
  Hello-interval is 5, Hold-time is 15
  Split-horizon is disabled
  Next xmit serial <none>
  Packetized sent/expedited: 42/0
  Hello's sent/expedited: 286/2
  Un/reliable mcasts: 0/41  Un/reliable ucasts: 44/3
  Mcast exceptions: 0  CR packets: 0  ACKs suppressed: 0
  Retransmissions sent: 1  Out-of-sequence rcvd: 0
  Topology-ids on interface - 0 
  Authentication mode is not set
  Topologies advertised on this interface:  base
  Topologies not advertised on this interface:

R1#

With this command, you can see that it states that split horizon is indeed disabled, and this is EIGRP-specific, so it is displaying the correct information.

I hope this has been helpful!

Laz

11

Hi Laz,

Thanks very much for confirming all of that - I actually forgot the eigrp interface command existed.

Sam

12

Hello Sam

I actually created a NetworkLessons note on this particular behavior. You can find it at EIGRP split horizon verification.

Laz