Troubleshooting AD Redistribution

Lessons Discussion
1

This topic is to discuss the following lesson:

2

Hi Rene,
You explained the subject in a very detailed manner. Thanks a lot . No one actually have explained it like the way you done. Thanks a lot

Ammar,
CCIE R&S - in progress

3

Thanks Ammar!

4

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.

5

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

6

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.

7

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
8

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

9

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

10

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
11

rene you are a routing god thank you

12

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
13

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

14

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

15

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.

16

Hello Jeremy

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

Once again, thanks!

Laz

17

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

Image11
Image11.png1126×318 10.5 KB

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

18

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

19

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

20

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