This topic is to discuss the following lesson:
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
CCIE R&S - in progress
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.
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.
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.
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.
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 188.8.131.52/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
First of all, let’s forget about the static routes 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 you are a routing god thank you
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 184.108.40.206/24 route?
route-map TAG deny 10 match tag 1 route-map TAG permit 20 set tag 1
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 220.127.116.11/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:
- We have RIP and OSPF, R3 and R4 are redistribution routers.
- R1 advertises the 18.104.22.168/24 network with a hop count of 10. R3 redistributes it into OSPF.
- R4 redistributes 22.214.171.124/24 back into RIP with a hop count of 1.
- R2 now installs 126.96.36.199/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 188.8.131.52/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!
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.
Yes, that is correct, thanks for catching that! I’ll let Rene know to have that fixed.
Once again, thanks!
Hi Rene and staff,
i did this lab step by step with my own GNS3 and went until
R2 won’t learn about 184.108.40.206 /24 through OSPF anymore and after a short while, R2 will install the RIP entry for 220.127.116.11 /24 again its routing table and the whole problem repeats itself
So 18.104.22.168/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 22.214.171.124/24 in its RIB
THis is surprising: as 126.96.36.199/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 188.8.131.52” and “delete route 184.108.40.206” 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 ?
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!
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 220.127.116.11/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 18.104.22.168/24
Step 5 : R2 seeing (incorrectly) a better route to 22.214.171.124/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 126.96.36.199/24, so R4 may delete its external EIGRP route to 188.8.131.52/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 ?
Hi Rene and staff,
this is a new question about this lesson. When you say
R2 was able to learn network 184.108.40.206 /24 through OSPF because it didn’t advertise this network itself into OSPF. If R2 would then it wouldn’t learn 220.127.116.11 /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 18.104.22.168/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)