cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5828
Views
15
Helpful
12
Replies

Setting EIGRP redistribute metric in a route-map

Kevin Dorrell
Level 10
Level 10

We all know that when re-distributing routes into EIGRP, if you don't set the metric, then the routes don't get re-distributed. I had always thought there were three ways you could set the re-distribution metric:

- as a default in the eigrp section: default-metric 10000 100 255 1 1500

- in the redistribution: redistribute ospf 1 metric 10000 100 255 1 1500

- in a route-map

Recently I tried putting the metric in the route-map, and it did not work unless I also put it in as the default or in the redistribution command. This behavior surprised me. Has anyone else noticed it? My config was something like:

<b>

router eigrp 100

 redistribute ospf 1 route-map ospf->eigrp

route-map ospf->eigrp permit 10

 set metric 1000 10 255 1 1500

 set tag 110

!

</b>

I cannot see why this did not work, but if I put the metric in the redistribute command it does work (and the routes do get tagged):

<b>

router eigrp 100

 redistribute ospf 1 metric 10000 100 255 1 1500 route-map ospf->eigrp

</b>

IOS 12.2(15)T17

Kevin Dorrell

Luxembourg

1 Accepted Solution

Accepted Solutions

Did you clear the ip routing table on R1 after entering the route-map ?

View solution in original post

12 Replies 12

Kevin,

My first thought was that it should work with a route map. A sanity check in my lab proves it indeed does work when the metric is set using the route map referenced in the redistribution command. My lab router runs IOS version 12.3(17a). I quickly scanned 12.2(15)T17 release notes and didn't find any bug for this behavior.

In the processed I noticed something interesting that even when I had no metric set in any format for the redistribution the route was getting redistributed into EIGRP from OSPF process. I assume the router probably uses the metric of the ingress interface as it's default metric or some other default metric. It looks like the traditional behavior of having to set a metric for the redistribution process/protocol isn't mandatory anymore.

HTH

Sundar

Thank you both, Sundar and EdisonOriz. Thank you both for taking the trouble to try it.

So, it remains a mystery for the moment. I shall not have a chance to use my rack this evening, but I shall investigate more deeply tomorrow evening. Maybe there was some other complicating factor - it was quite a complex lab with RIP, EIGRP and OSPF all mutually redistributing on three different routers.

(BTW, the lab was NetMasterClass DoIT II Lab 18, router R1.)

I was intrigued by what Sundar said about the routes getting redistributed in 12.3(17a) even without the redistribution metric. I have that version on a couple of routers and I shall try it out.

Thanks again, and I'll be sure to let you know what I come up with.

Kevin Dorrell

Luxembourg

Edison Ortiz
Hall of Fame
Hall of Fame

Kevin,

I loaded 12.2(15)T17 on 3 boxes and was unable to duplicate your problem. I mirrored your configuration, enabled 'debug ip eigrp'.

Routes were redistributed as expected with the metrics in the route-map

____________________

R2#show ip route os

192.168.200.0/32 is subnetted, 1 subnets

O 192.168.200.1 [110/11] via 192.168.0.2, 00:04:52, Ethernet0/0

192.168.254.0/32 is subnetted, 1 subnets

O 192.168.254.1 [110/11] via 192.168.0.2, 00:04:52, Ethernet0/0

192.168.100.0/32 is subnetted, 1 subnets

O 192.168.100.1 [110/11] via 192.168.0.2, 00:04:52, Ethernet0/0

R2#

____________________________

R2#clear ip route *

R2#

*Sep 11 02:38:51.151: IP-EIGRP(Default-IP-Routing-Table:1): 192.168.2.0/24 routing table not updated

*Sep 11 02:38:51.279: IP-EIGRP(Default-IP-Routing-Table:1): 192.168.100.1/32 - do advertise out Ethernet1/0

*Sep 11 02:38:51.279: IP-EIGRP(Default-IP-Routing-Table:1): Ext 192.168.100.1/32 metric 4294967295 - 2560000 4294967295

*Sep 11 02:38:51.279: IP-EIGRP(Default-IP-Routing-Table:1): 192.168.254.1/32 - do advertise out Ethernet1/0

*Sep 11 02:38:51.279: IP-EIGRP(Default-IP-Routing-Table:1): Ext 192.168.254.1/32 metric 4294967295 - 2560000 4294967295

*Sep 11 02:38:51.279: IP-EIGRP(Default-IP-Routing-Table:1): 192.168.200.1/32 - do advertise out Ethernet1/0

R2#

*Sep 11 02:38:51.279: IP-EIGRP(Default-IP-Routing-Table:1): Ext 192.168.200.1/32 metric 4294967295 - 2560000 4294967295

*Sep 11 02:38:51.571: IP-EIGRP(Default-IP-Routing-Table:1): Processing incoming REPLY packet

*Sep 11 02:38:51.571: IP-EIGRP(Default-IP-Routing-Table:1): ExtS 192.168.100.1/32 M 4294967295 - 2560000 4294967295 SM 4294967295 - 2560000 4294967295

*Sep 11 02:38:51.571: IP-EIGRP(Default-IP-Routing-Table:1): ExtS 192.168.254.1/32 M 4294967295 - 2560000 4294967295 SM 4294967295 - 2560000 4294967295

*Sep 11 02:38:51.571: IP-EIGRP(Default-IP-Routing-Table:1): ExtS 192.168.200.1/32 M 4294967295 - 2560000 4294967295 SM 4294967295 - 2560000 4294967295

*Sep 11 02:38:51.639: IP-EIGRP(Default-IP-Routing-Table:1): 192.168.100.1/32 - do advertise out Ethernet1/0

*Sep 11 02:38:51.639: IP-EIGRP(Default-IP-Routing-Table:1): Ext 192.168.100.1/32 metric 2562560 - 2560000 2560

*Sep 11 02:38:51.639: IP-EIGRP(Default-IP-Routing-Table:1): 192.168.254.1/32 - do advertise out Ethernet1/0

*Sep 11 02:38:51.639: IP-EIGRP(Default-IP-Routing-Table:1): Ext 192.168.254.1/32 metric 2562560 - 2560000 2560

*Sep 11 02:38:51.639: IP-EIGRP(Default-IP-Routing-Table:1): 192.168.200.1/32 - do advertise out Ethernet1/0

*Sep 11 02:38:51.639: IP-EIGRP(Default-IP-Routing-Table:1): Ext 192.168.200.1/32 metric 2562560 - 2560000 2560

R2#

*Sep 11 02:38:51.851: IP-EIGRP(Default-IP-Routing-Table:1): Processing incoming UPDATE packet

*Sep 11 02:38:51.851: IP-EIGRP(Default-IP-Routing-Table:1): ExtS 192.168.100.1/32 M 4294967295 - 2560000 4294967295 SM 4294967295 - 2560000 4294967295

*Sep 11 02:38:51.851: IP-EIGRP(Default-IP-Routing-Table:1): ExtS 192.168.254.1/32 M 4294967295 - 2560000 4294967295 SM 4294967295 - 2560000 4294967295

*Sep 11 02:38:51.851: IP-EIGRP(Default-IP-Routing-Table:1): ExtS 192.168.200.1/32 M 4294967295 - 2560000 4294967295 SM 4294967295 - 2560000 4294967295

R2#

__________________________

R3#show ip route eigrp

192.168.200.0/32 is subnetted, 1 subnets

D EX 192.168.200.1 [170/2588160] via 192.168.1.1, 00:03:47, Ethernet0/0

D EX 192.168.0.0/24 [170/2588160] via 192.168.1.1, 00:05:46, Ethernet0/0

192.168.254.0/32 is subnetted, 1 subnets

D EX 192.168.254.1 [170/2588160] via 192.168.1.1, 00:03:47, Ethernet0/0

192.168.100.0/32 is subnetted, 1 subnets

D EX 192.168.100.1 [170/2588160] via 192.168.1.1, 00:03:47, Ethernet0/0

_______________________

R3#show ip route 192.168.100.1

Routing entry for 192.168.100.1/32

Known via "eigrp 1", distance 170, metric 2588160

Tag 110, type external

________________________

Can we see a debug from your rack ?

Well, it is really strange, but I stick by my observation. OK I have simplified the following outputs so I can concentrate on one particular route. I start off with a route to 151.10.100.7/32 in my OSPF on my border router, and I try to redistribute it into EIGRP. But it does not turn up in a neighboring EIGRP router.

CAT2#show ip route 151.10.100.7

% Subnet not in table

Here is some config from my border router:

R1#show run

*Mar 1 00:18:06.651: %SYS-5-CONFIG_I: Configured from console by console

Building configuration...

Current configuration : 3435 bytes

!

version 12.2

!

[output omitted]

!

router eigrp 100

redistribute ospf 1 route-map ospf->eigrp

network 151.10.22.0 0.0.0.255

network 198.1.1.0

distance eigrp 90 112

no auto-summary

!

router ospf 1

log-adjacency-changes

redistribute eigrp 100 subnets route-map eigrp->ospf

network 151.10.124.0 0.0.0.255 area 0

!

[output omitted]

!

route-map ospf->eigrp permit 10

set metric 1000 10 255 40 1500

set tag 110

!

So, then I add a default metric redistribution metric on the eigrp:

R1#conf t

Enter configuration commands, one per line. End with CNTL/Z.

R1(config)#default-metric 10000 100 255 64 1500

Suddenly, my debug on the border router bursts into life, re-distributing the OSPF routes into EIGRP. Amongst them:

*Mar 1 00:18:47.131: IP-EIGRP(Default-IP-Routing-Table:100): 151.10.100.7/32 - do advertise out FastEthernet0/0.50

*Mar 1 00:18:47.155: IP-EIGRP(Default-IP-Routing-Table:100): 151.10.100.7/32 - do advertise out FastEthernet0/0.16

*Mar 1 00:18:47.199: IP-EIGRP(Default-IP-Routing-Table:100): Processing incoming UPDATE packet

*Mar 1 00:18:47.207: IP-EIGRP(Default-IP-Routing-Table:100): ExtS 151.10.100.7/32 M 4294967295 - 2560000 4294967295 SM 4294967295 - 2560000 4294967295

*Mar 1 00:18:47.343: IP-EIGRP(Default-IP-Routing-Table:100): Processing incoming UPDATE packet

*Mar 1 00:18:47.351: IP-EIGRP(Default-IP-Routing-Table:100): ExtS 151.10.100.7/32 M 4294967295 - 2560000 4294967295 SM 4294967295 - 2560000 4294967295

Here is the same event as seen on the neighboring EIGRP router:

CAT2#

*Mar 1 00:58:50.683: IP-EIGRP(Default-IP-Routing-Table:100): Processing incoming UPDATE packet

*Mar 1 00:58:50.843: IP-EIGRP(Default-IP-Routing-Table:100): Ext 151.10.100.7/32 M 2588160 - 2560000 28160 SM 2562560 - 2560000 2560

*Mar 1 00:58:50.847: RT: add 151.10.100.7/32 via 151.10.22.1, eigrp metric [170/2588160]

*Mar 1 00:58:50.851: RT: NET-RED 151.10.100.7/32

*Mar 1 00:58:50.995: IP-EIGRP(Default-IP-Routing-Table:100): Ext 151.10.100.7/32 metric 2588160 - 2560000 28160

Now the route for 151.10.100.7/32 has turned up in the neighboring EIGRP router.

CAT2#show ip route 151.10.100.7

Routing entry for 151.10.100.7/32

Known via "eigrp 100", distance 170, metric 2588160

Tag 110, type external

Redistributing via eigrp 100

Last update from 151.10.22.1 on Ethernet0, 00:01:54 ago

Routing Descriptor Blocks:

* 151.10.22.1, from 151.10.22.1, 00:01:54 ago, via Ethernet0

Route metric is 2588160, traffic share count is 1

Total delay is 1100 microseconds, minimum bandwidth is 1000 Kbit

Reliability 255/255, minimum MTU 1500 bytes

Loading 40/255, Hops 1

What's more, its "load" metric is 40, not 64. (See what I've done there - I put a different load metric in the route map to the one in the default so I could see which one was being used.)

So, I'm really puzzled. The only other thing I have left out was that there was also mutual redistribution with RIP, but that is not relevant to the 151.10.100.7/32 route.

Kevin Dorrell

Luxembourg

Did you clear the ip routing table on R1 after entering the route-map ?

Yes I did. Well, strictly I just powered the lab on and let it converge. I have the lab in front of me now and I am looking further.

Kevin Dorrell

Luxembourg

Is the 151.10.100.7/32 route showing up as an OSPF route on R1?

Can you post the output of 'show ip route 151.10.100.7' from R1.

OK, here is the route in R1 with the eigrp default-metric in place:

R1#show ip route 151.10.100.7

Routing entry for 151.10.100.7/32

Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 74

Redistributing via eigrp 100, rip

Advertised by eigrp 100 route-map ospf->eigrp

rip route-map ospf->rip

Last update from 151.10.124.4 on Serial0/0.124, 01:15:17 ago

Routing Descriptor Blocks:

* 151.10.124.4, from 151.10.100.7, 01:15:17 ago, via Serial0/0.124

Route metric is 20, traffic share count is 1

And here it is without:

R1#show ip route 151.10.100.7

Routing entry for 151.10.100.7/32

Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 74

Redistributing via eigrp 100, rip

Advertised by rip route-map ospf->rip

Last update from 151.10.124.4 on Serial0/0.124, 01:17:47 ago

Routing Descriptor Blocks:

* 151.10.124.4, from 151.10.100.7, 01:17:47 ago, via Serial0/0.124

Route metric is 20, traffic share count is 1

The only difference I can see is that without the default-metric it is not "Advertised by eigrp 100 route-map ospf->eigrp". It is as if without the default metric or a metric in the redistribution command, it never even attempts to put it through the route map.

KJD

Just to rule out it's not typo that's causing this problem can you use a simple name for the route map, like test or cisco, instead of using the name ospf->eigrp.

It's definitely not a typo because when the route does turn up in CAT2 it has the tag and the load parameter that I set in the route map. But I shall try changing the name in case it is the "->" that upsets it.

KJD

I can see one difference between my topology and the one Edison set up, but I don't think it is relevant. It is that the route 151.10.100.7/32 was already an external E2 when it was injected into OSPF over the other side of the cloud.

But I don't think it is relevant because the same think happens to internal OSPF routes. I'm still puzzled.

Ah-ha! But it doesn't happen like that to routes that are generated locally with a network command on the border router! So that's the difference between Edison's scenario and mine. My routes came from across the OSPF network. Not that it should make any difference.

Edit: OK, I may have slipped up in my observations. I did a clear ip route * on the border router R1 as Sundar suggested, and the route turned up in CAT2. I am just reloading R1 to see what happens.

The strange thing is that before I cleared the routes, I could make the route appear and disappear in CAT2 by setting a default-matric in R1 or removing it. But the metric of the route was the one from the route map.

KJD

OK, so that was it. The route map does not fully take effect until you clear the routes. That it, most of its functionality takes effect, except its flag that says "I can take care of the re-distribution metric."

Hey, I've learned something today!

Thanks for talking me through this both of you. I wouldn't have got there without you.

Kevin Dorrell

Luxembourg

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: