Troubleshooting AD Redistribution

Hi Rene,

Why when you redistribute ospf into eigrp by default the network 192.168.23.0/24 is not show up in the eigrp table on R4 even if you have the “network 192.168.23.0” command under ospf process? It requires to also apply redistribute connected under eigrp on R3 so it can show up on R4.

Hi Sergio,

When you redistribute OSPF into EIGRP then it should advertise 192.168.23.0/24 to R4. You don’t have to redistribute connected, that’s only needed when the network is not advertised in OSPF.

Rene

Hi Rene,

I discussed this with my study group and we came to find out that I was not entering the metric when redistributing ospf into eigrp. In order for connected/networks to redistribute from another routing protocol into eigrp I would need to specify the metric unless is eigrp into eigrp. Thanks for your response.

Hi Sergio,

Good to hear you figured it out. RIP and EIGRP require a seed metric, if you don’t specify it then the metric will be infinite and it can’t be installed in the routing table.

Rene

1 Like

Yep, seed metric is key for those routing protocols. Won’t forget now.

hi rene ive done the redistribution but I can’t seem to get router 1 to see the 192.168.23.0/24 network I can see the 1.1.1.0/24 network from router 3 and I can make it work if I put in the static route on router 1 so if router 3 pings router 1 from a source ip in the ospf area it can get back but i can’t get the network in it’s route table I’ve debugged routing on router 4 and its being told about the ospf network from router 3 but router 2 is not telling router 1 about the ospf network

Hi Shaun,

First of all, let’s forget about the static routes :slight_smile: With static routes we can make anything work but in this example, we are using routing protocols only.

The problem with R1 and 192.168.23.0/24 is that R2 will never install a route from R4 about 192.168.23.0/24.

Why? For R2, it’s a directly connected network so whatever R4 advertises…the directly connected link is always preferred.

If you want reachability to it from R1 then it’s best to do a “redistribute connected” on R2, make sure you use a route-map so that only the FastEthernet0/0 interface is selected.

Rene

1 Like

rene you are a routing god thank you

Hello Rene,

If we go with the same approach by adding a route map like this when redistributing routes, will this resolve the AD metric issue on 1.1.1.0/24 route?

route-map TAG deny 10
match tag 1
route-map TAG permit 20
set tag 1

Hello Ray,

You could add that route-map to R2 and R4 so that R2 sets the tag and R3 doesn’t redistribute it back into OSPF because of the tag.

That works, but it also means that the OSPF domain won’t know about the 1.1.1.0/24 network. If you have another router (let’s say R5) in the OSPF domain that needs that route, then you have a problem.

Of course, it’s unlikely to see stuff like this on a production network but be very careful when reading the requirement(s) on an exam.

Here is an example where you should use tags:

rip-ospf-redistribution-scenario

  • We have RIP and OSPF, R3 and R4 are redistribution routers.
  • R1 advertises the 1.1.1.0/24 network with a hop count of 10. R3 redistributes it into OSPF.
  • R4 redistributes 1.1.1.0/24 back into RIP with a hop count of 1.
  • R2 now installs 1.1.1.0/24 with R4 as the next hop.

To prevent this from happening, you can add your route-map on R3 and R4 to prevent R4 from redistributing 1.1.1.0/24 back into RIP.

RIP is vulnerable to this issue, OSPF and EIGRP not. OSPF always prefers inter-area routes (O) over external routes (O E) and EIGRP has a higher AD for external routes.

Hope this helps!

Rene

use route-map on redistributing routers will resolve the issue for this topology

I used same route-map on router 2 and 3 only and working fine, but don’t think it will work for other topology, e.g: put Router 5 between R2 and R3

Found a couple mistakes I think:

The internal route was learned through EIGRP external (AD 170) and the internal route is learned through RIP (AD 120).
The internal route was learned through BGP internal (AD 200) and the internal route is learned through OSPF (AD 110).

I think the bolded 'internal’s should read ‘external’ instead.

Hello Jeremy

Yes, that is correct, thanks for catching that! I’ll let Rene know to have that fixed.

Once again, thanks!

Laz

Hi Rene and staff,

i did this lab step by step with my own GNS3 and went until
"
R2 won’t learn about 1.1.1.0 /24 through OSPF anymore and after a short while, R2 will install the RIP entry for 1.1.1.0 /24 again its routing table and the whole problem repeats itself
"
So 1.1.1.0/24 is flapping in the R2’s RIB (because of redistribution and OSPF AD =110 <120)
OK, that is what i see in my GNS3 too
But from R4 perspective, i never see the route 1.1.1.0/24 in its RIB
THis is surprising: as 1.1.1.0/24 is flapping in R2’s RIB, i expected that this route would flap in R4’s RIB too
I have the same debug in my GNS3 as in the lesson

I remark there is a very very short time between “add 1.1.1.0” and “delete route 1.1.1.0” in the output
Perhaps there is no enough time to see this route in the R4’s RIB with a show command, but this is surprising to see the route flapping in R2 and not in R4
Could you help me to understand why ?
Regards

Hello Dominique

You should be seeing a similar behaviour in R4 as well, however, you may not see it because it is happening so fast and you are not able to catch it during the show route. Try using some of the techniques shown in the lesson such as the ip route profile command.

Try it out and let us know what your results are.

I hope this has been helpful!

Laz

Hi Laz,
thanks for replying,
this is the question for me: why does the route flap so quickly that you can’t see it on R4, in contrary to R2 where you can see the route flapping in the RIB

First step is: R4 install a route to 1.1.1.0/24 as EIGRP external when R2 redistribute the RIP route
Second step is: R4 advise this EIGRP external route to R3
Step 3: this route is redistributed as ospf route in R3
Step 4 is: R3 advise R2 a route ospf to 1.1.1.0/24
Step 5 : R2 seeing (incorrectly) a better route to 1.1.1.0/24 via R3 as an ospf route delete the rip route from its RIB
Step 6 is: R2 has no RIP route to redistribute

At this point, i suppose all these steps take a little time
But in addition, R2 has to update the information to R4 via redistribution that there is no more route RIP to 1.1.1.0/24, so R4 may delete its external EIGRP route to 1.1.1.0/24: you have to add this delay too
So the question could be: “how quick is the redistribution update sent from R2 to R4 ?”
It seems like there is no holdtime in redistribution ?

In the picture (that is R3 instead of R4 but this is similar) it takes 60 ms to do all this stuff.
So, i ask myself if there is another mecanism that R4 use to delete this route so quickly ?
Regards

Hi Rene and staff,

this is a new question about this lesson. When you say
"
R2 was able to learn network 1.1.1.0 /24 through OSPF because it didn’t advertise this network itself into OSPF. If R2 would then it wouldn’t learn 1.1.1.0 /24 from R3.
"
i think it is because split horizon ?
But my question is: “which routing protocol is applying split horizon in this case ?”
Should it be OSPF ? = OSPF receive 1.1.1.0/24 via R2-Fa0/0 from RIP redistribution, so it (OSPF) don’t advertise this subnet via this interface. Am i right ?
But does split horizon work this way in OSPF ? (as it is not a DV protocol)
Regards

Hi Rene and staff,

i want to add another comment for the final solution. Perhaps it could help someone
"
R4 will use the EIGRP external entry (AD 170) for 1.1.1.0 /24. R2 and R3 both redistribute 1.1.1.0 /24 into EIGRP, the route that R4 installs depends on the seed metric
"
In the lesson R2 redistribute RIP into EIGRP with BW=1000
And R3 redistribute OSPF into EIGRP with BW=1500
So in my opinion R4 will install the route via R3
I don’t know why so low values are used in the lesson with FastEthernet (?)

But in my GNS3 lab, i set R2 and R3 both to redistribute 1.1.1.0/24 into EIGRP with the same composite metrics (BW= 100 000, DL, etc…) So, with this topology and the same redistribution composite metrics and the same K-values, from the perspective of R4 there are two paths with the same metric, and EIGRP could load balance between these paths. Let’s find the R4’s RIB from my lab (in my lab the name of interfaces are not the same)
Image13

Regards

1 Like

Hello Dominique

Even if the route on R4 is installed and removed so quickly that you can’t see it with a show ip route command, if you issue the ip route profile command, as shown in the lesson, it will show you how many times the route was installed and removed. Do you see these counters going up as they should in your topology?

If so, then the only thing I can say is that it is just by chance, or for some reason, the route remains in the routing table for such a small amount of time, compared to R2. Remember that the route flapping in R2 is occurring between routes that are learned between RIP and OSPF, where on R4, the route flapping is occurring with EIGRP only. The variation in timers that are used by the particular protocols plays a role in how quickly a routing protocol converges. It can be said that EIGRP converges very quickly, and for this reason, you cannot “catch” the route in the table.

I hope this has been helpful!

Laz

Hello Dominique

Yes you are correct.

Split horizon says, as you very well know, that you cannot learn about a route from the same interface that you advertised it out of. Because we have a loop here, R2, R3, R4, each router will always learn about 1.1.1.0/24 from an interface from which it did not learn about it. It learns about it from one interface, and informs the next router from another interface. This happens on R2, R3, R4, and then again on R2, from an interface other than the one it was sent out of. Regardless of which routing protocol is being used, the fact that we have a physical loop with redistribution can allow a route to cause such a routing malfunction and split horizon is helpless to rectify it.

I hope this has been helpful!

Laz