09-10-2007 11:54 AM - edited 03-03-2019 06:41 PM
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
Solved! Go to Solution.
09-12-2007 12:11 PM
Did you clear the ip routing table on R1 after entering the route-map ?
09-10-2007 04:06 PM
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
09-11-2007 02:02 AM
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
09-10-2007 06:42 PM
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 ?
09-12-2007 11:57 AM
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
09-12-2007 12:11 PM
Did you clear the ip routing table on R1 after entering the route-map ?
09-12-2007 12:26 PM
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
09-12-2007 12:11 PM
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.
09-12-2007 12:30 PM
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
09-12-2007 12:39 PM
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.
09-12-2007 12:48 PM
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
09-12-2007 12:46 PM
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
09-12-2007 01:09 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide