Eigrp redistributing OSPF

[rwiebe]

Eigrp redistributing OSPF

I have two problems here.

One is redistribution of OSPF into EIGRP. Redistribution seems to work fine, my redistributing router has all of the OSPF domain routes in it's topology table. It does not seem to advertise these routes to the next hop EIGRP router.

My other problem is that this same router does not advertise a default route to the next hop EIGRP router.

Included are the configs for these routers (with show IP Route), and a diagram.

Router 70,71 etc. on the right are my OSPF core. Router Rtest on the left is there to test default route injection, and I will be testin EIGRP Stub functionality.

[Kevin Dorrell]

It seems OK, except that your redistribution metric is a bit strange. I don^t know whether it makes a difference, but is there any particular reason for specifiying the MTU as 500?

The values I usually use are something like 10000 10 255 1 1500.

Have you tried just distributing one way to start with, and without the route-map?

Do the two routers actually see each other in show ip eigrp neighbor?

Kevin Dorrell

Luxembourg

[rwiebe]

Yes, the neghbor adjacencies are all there:

R74-EIGRP#sho ip eigrp neigh

IP-EIGRP neighbors for process 42

H Address Interface Hold Uptime SRTT RTO Q Seq Typ

e

(sec) (ms) Cnt Num

0 172.31.30.26 Gi1/0/22 13 21:14:35 1 200 0 176

R74-EIGRP#sho ip ospf neigh

Neighbor ID Pri State Dead Time Address Interface

192.168.255.37 1 FULL/DR 00:00:30 192.168.250.14 GigabitEtherne

t1/0/23

r251dnld-1#sho ip eigrp neigh

IP-EIGRP neighbors for process 42

H Address Interface Hold Uptime SRTT RTO Q Seq Typ

e

(sec) (ms) Cnt Num

0 172.31.30.25 Gi1/0/1 11 21:15:28 1 200 0 313

1 172.16.44.162 Gi1/0/6 11 21:29:39 1 200 0 20

RTest#sho ip eigrp neigh

IP-EIGRP neighbors for process 42

H Address Interface Hold Uptime SRTT RTO Q Seq

(sec) (ms) Cnt Num

0 172.16.44.161 Fa0 14 21:31:08 1 200 0 175

The redistribution of the default route does not seem to matter to whether the OSPF routes are advertised to the rest of the EIGRP routers. At one point I had configured all the routers with static IP Route 0.0.0.0 0.0.0.0 to the next hop towards the OSPF core, and the OSPF routes were still missing from R251dnld and Rtest.

As for the redistribution metrics, I am new to EIGRP, and was not sure how to set those. The routes from the OSPF area are from some fast links (Gig Ethernet) and from some slow (64Kb single ISDN B channel). Not sure how to present this to EIGRP as metrics.

[rwiebe]

I called Cisco TAC with this problem. While looking around through the configs, routing tables, topology tables, the Cisco tech noticed that my redistributing router and the next hop EIGRP router had the same router id.

How this can be we could not determine since the router id is derived from the highest loopback address, and the routers were configured with very different loopbacks (one a private class C address, the other a private class B address). But the 'show ip eigrp topology' command on the two routers showed this to be the case.

The duplicate router ids cause redistribution to not work properly. Setting an explicit router id by using the command 'eigrp router-id 192.168.250.21' under router eigrp solved the problem.

With redistribution working properly, injecting the default route into EIGRP to the upstream EIGRP routers also worked.

Cisco TAC refered me to this article describing the duplicate router id problem:

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800949ab.shtml

Thanks Kevin for looking into my problem, and thanks to all for the interesting posts I have been reading through.

Sollution: Duplicate router id causes redistribution to not work properly. This affects propogation of redistributed routes, including redistribution of the static default router.

[Kevin Dorrell]

That's interesting, and thank you for coming back and telling us about how the problem was resolved. It is always useful; it allows us all to benefit from the cumulative experience.

I am curious to know how the routers got the same EIGRP RID, and whether it was 192.168.250.21 or 172.31.30.1. There is only one way I can imagine this: if the routers started out with a duplicate address which was then corrected later. If so, a reboot would have fixed the problem.

Once the EIGRP process has started, it will not change the RID on the fly, even if you change the underlying interface address. In fact, it is useful always to bear in mind that the RID (for EIGRP, OSPF, and BGP) is not actually an IP address at all, but simply a unique 32-number. It just happens that picking out an IP address is a good way of selecting this "random" number and having a good probability it is unique.

The duplicate loopback address is not such an uncommon occurence. In fact, if you want to do anycast RP for multicast (with MSDP), it is essential. I have seen quite a few practice labs based on this "gotcha". In that case it is necessary to hard-code the RIDs.

Kevin Dorrell

Luxembourg

[rwiebe]

Hi Kevin.

R251dnld-1 has loopback address 172.31.30.1. R74-EIGRP has loopback address 192.168.250.21. Both routers acquired the RID 172.31.30.1. Router R74-EIGRP never had this address configured on it, it was the first router I configued for this test and always had the 192.168.250.21 loopback.

The closest network to this RID in question is the one connecting the two routers, 172.31.30.24/29. At one piont, I think I had a network command 'network 172.31.30.0', which I made more specific later on. The router was rebooted a few times while trying to troubleshoot the problem, so we would think that the RID would be taken from the loopback.

Randall Wiebe-Dembowski

Winnipeg

[Kevin Dorrell]

Hi Randall, and thanks for the information. I cannot think how that could happen, but I guess we shall never know.

Glad you got it all sorted in the end though.

Kevin Dorrell

Luxembourg