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 22.214.171.124/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 126.96.36.199/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 188.8.131.52/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 184.108.40.206/24 network with a hop count of 10. R3 redistributes it into OSPF.
- R4 redistributes 220.127.116.11/24 back into RIP with a hop count of 1.
- R2 now installs 18.104.22.168/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 22.214.171.124/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 126.96.36.199 /24 through OSPF anymore and after a short while, R2 will install the RIP entry for 188.8.131.52 /24 again its routing table and the whole problem repeats itself
So 184.108.40.206/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 220.127.116.11/24 in its RIB
THis is surprising: as 18.104.22.168/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 22.214.171.124” and “delete route 126.96.36.199” 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 188.8.131.52/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 184.108.40.206/24
Step 5 : R2 seeing (incorrectly) a better route to 220.127.116.11/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 18.104.22.168/24, so R4 may delete its external EIGRP route to 22.214.171.124/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 126.96.36.199 /24 through OSPF because it didn’t advertise this network itself into OSPF. If R2 would then it wouldn’t learn 188.8.131.52 /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 184.108.40.206/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)
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 220.127.116.11 /24. R2 and R3 both redistribute 18.104.22.168 /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 22.214.171.124/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)
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!
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 126.96.36.199/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!
I configured the same AD redistribution topology on GNS3 and resolved the issue using the first method i . e by applying a lower AD for the RIP route from R1 for 188.8.131.52/24 and I am seeing results in the routing table that R2 is learning 184.108.40.206/24 from R1 with the AD 100. All good there however I am not able to ping 220.127.116.11/24 from R3 and R4 even though these routers have route to 18.104.22.168/24 in their routing table. Also I redistributed connected network under RIP on R2 but 192.168.23.0/24 is still unreachable from R1. All configs were done exactly per the lesson. Can you please help clarifying this issue?
R3#ping 22.214.171.124 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 126.96.36.199, timeout is 2 seconds: ..... **Success rate is 0 percent (0/5)** R3#sh ip route | begin Gateway Gateway of last resort is not set 188.8.131.52/24 is subnetted, 1 subnets **D EX 184.108.40.206 [170/2636800] via 192.168.34.4, 00:08:08, Ethernet0/1** R4#ping 220.127.116.11 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 18.104.22.168, timeout is 2 seconds: ..... **Success rate is 0 percent (0/5)** R4#sh ip route | begin Gateway Gateway of last resort is not set 22.214.171.124/24 is subnetted, 1 subnets **D EX 126.96.36.199 [170/2611200] via 192.168.24.2, 00:09:48, Ethernet0/1** R1#ping 192.168.23.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.23.2, timeout is 2 seconds: ..... **Success rate is 0 percent (0/5)** R1#ping 192.168.23.3 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.23.3, timeout is 2 seconds: ..... **Success rate is 0 percent (0/5)**
I found the issue and fixed. It was a silly mistake I made on R2. I missed “version 2” command on R2 and R1 was configured with version 2. Now I have full connectivity after I configured version 2 command on R2. Thank you anyway!
R3#ping 188.8.131.52 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 184.108.40.206, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/2 ms R4#ping 220.127.116.11 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 18.104.22.168, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms R1#sh ip route | begin Gateway Gateway of last resort is not set 22.214.171.124/8 is variably subnetted, 2 subnets, 2 masks C 126.96.36.199/24 is directly connected, Loopback0 L 188.8.131.52/32 is directly connected, Loopback0 192.168.12.0/24 is variably subnetted, 2 subnets, 2 masks C 192.168.12.0/24 is directly connected, Ethernet0/0 L 192.168.12.1/32 is directly connected, Ethernet0/0 R 192.168.23.0/24 [120/1] via 192.168.12.2, 00:00:03, Ethernet0/0 R 192.168.24.0/24 [120/1] via 192.168.12.2, 00:00:03, Ethernet0/0 R 192.168.34.0/24 [120/1] via 192.168.12.2, 00:00:03, Ethernet0/0
Thanks for sharing your solution with us, it’s always helpful to see your solutions to the problems that you face. If you have any other issues, you know where to find us!
I am wrong or we can fix this issue with tag the redistribution?
Yes, you could use route tagging to resolve this issue. You could tag the route when it is being redistributed from RIP to EIGRP on R2, so that when this is re-redistributed from R3 to R2 via OSPF, it is simply not accepted.
Although this solution would be fine for this topology, making changes to the AD would be more appropriate than using tagged routes. This is because in the event that a specific route does indeed fail, you would want the alternate route to be installed in the routing table. When using route tagging, the alternate route would not be installed, however by adjusting the ADs, that alternate route would be installed, making this solution a more robust and preferable one.
I hope this has been helpful!