Refer to the exhibit. After redistribution is enabled between the routing protocols; PC2, PC3, and PC4 cannot reach PC1.
Which action can the engineer take to solve the issue so that all the PCs are reachable?
Refer to the exhibit. After redistribution is enabled between the routing protocols; PC2, PC3, and PC4 cannot reach PC1.
Which action can the engineer take to solve the issue so that all the PCs are reachable?
The issue arises because R2 learns the 10.1.1.0/24 route from two different sources: RIP (with an administrative distance of 120) and OSPF (with an administrative distance of 110). By default, R2 prefers the route learned via OSPF due to its lower administrative distance, leading the traffic towards PC1 to be rerouted through R3 instead of directly through RIP. By setting the administrative distance to 100 under the RIP process on R2, the route learned from RIP will be preferred over the OSPF route, ensuring the correct path to PC1 is used and resolving the reachability issue for PC2, PC3, and PC4.
This Config works: Answer A ------------------------------------ R2#sh run | s rip redistribute rip metric 1 1 1 1 1 router rip version 2 redistribute eigrp 100 metric 1 network 10.0.0.0 network 12.0.0.0 distance 100 no auto-summary ----------------------------------- R3#sh run | s router router eigrp 100 network 34.34.34.0 0.0.0.255 redistribute ospf 100 metric 1 1 1 1 1 router ospf 100 redistribute eigrp 100 subnets network 10.3.3.0 0.0.0.255 area 0 network 23.23.23.0 0.0.0.255 area 0 --------------------------------------- Answer B is wrong: the Correct is to filter 10.1.1.10 when redistribute from EIGRP to OSPF: Configs are --------------------------------------- ip prefix-list DNA seq 5 deny 10.1.1.0/24 ip prefix-list DNA seq 10 permit 0.0.0.0/0 le 32 route-map DDD permit 10 match ip address prefix-list DNA ! router eigrp 100 network 34.34.34.0 0.0.0.255 redistribute ospf 100 metric 1 1 1 1 1 ! router ospf 100 redistribute eigrp 100 subnets route-map DDD network 10.3.3.0 0.0.0.255 area 0 network 23.23.23.0 0.0.0.255 area 0 !
very good. i dont need to test this one to understand. answer is A
What's result your config? B correct: It seems there is a loop because of mutual redistributions among RIP, OSPF and EIGRP domains. So we should filter out the prefix 10.1.1.0/24 when redistributed from OSPF to EIGRP (the second redistribution point) to prevent routing loop.
100% agree. Labbed it. Reducing AD to 100 will always provide an exit for packets to 10.1.1.0/24. When this route is in EIGRP it's external, so it will be treated with AD=170. Within OSPF AD=110. Reduce RIP down to 100 then on R2 10.1.1.0/24 will always point out towards RIP domain. After making lab you'll see that problem happens on R2; it redistributes RIP into EIGRP, which then gets redistributed into OSPF at R3. So R2 learns from R3 an OSPF E2 route with an AD of 110. It inserts 10.1.1.0/24 >> R3 into the RIB because the OSPF AD is lower than the RIP learned AD. Thus lower RIP AD to 100 and it will be preferred over the OSPF route.
What is being redistributed on R2? I may be missing something but when I labbed the below all routers could ping the 10.1.1.1 interface on R1. There were no redistributions on R4. R2(config)#do sho run | s router router eigrp 100 network 24.24.24.2 0.0.0.0 redistribute rip metric 1000000 10 255 1 1500 router ospf 100 redistribute rip network 23.23.23.2 0.0.0.0 area 0 router rip version 2 redistribute ospf 100 metric 2 redistribute eigrp 100 metric 2 network 10.0.0.0 network 12.0.0.0 neighbor 12.12.12.1 R2(config)# R3#sho run | s router router eigrp 100 network 34.34.34.0 0.0.0.255 redistribute ospf 100 metric 1000000 10 255 1 1500 router ospf 100 redistribute eigrp 100 network 10.3.3.3 0.0.0.0 area 0 network 23.23.23.3 0.0.0.0 area
Me too I lab it up and there's no issue. PC2, PC3 & PC4 could ping PC1 R2#show run | s router router eigrp 100 redistribute rip metric 1000000 1 255 1 1500 redistribute ospf 100 metric 1000000 1 255 1 1500 network 24.24.24.0 0.0.0.255 no auto-summary router ospf 100 log-adjacency-changes redistribute rip subnets redistribute eigrp 100 subnets network 23.23.23.0 0.0.0.255 area 0 router rip version 2 redistribute ospf 100 metric 1 redistribute eigrp 100 metric 1 network 10.0.0.0 network 12.0.0.0 no auto-summary R3#show run | s router router eigrp 100 redistribute ospf 100 metric 1000000 1 255 1 1500 network 34.34.34.0 0.0.0.255 no auto-summary router ospf 100 log-adjacency-changes redistribute eigrp 100 subnets network 10.3.3.0 0.0.0.255 area 0 network 23.23.23.0 0.0.0.255 area 0
I lab all router can ping PC1 =)))), maybe question is not true
You still will have a routing loop
PC 2 will not be able to reach PC1 The correct answer is B
HETKAR and Alnet are correct, and I just want to add simple clarification D - does not make any sense C - if you filter prefix 10.1.1.0/24 from RIP to EIGRP, this network becomes unreachable on R3 and R4. B - there is no redistribution from RIP to OSPF that won't work as OSPF does not learn the prefix from RIP. A (Correct) When the traffic goes to the R2, the router will have a choice - sent to the R1 (RIP AD is 120) or to R3 (OSPF 110). OSPF is learning the route from R4 via redistribution. Route with the lover AD will be injected into the routing table. So if RIP's AD will not be changed to 100, R2 will forward the traffic to R3, so the packet will not reach R1. I was confused a bit when I saw this scheme first time. R2 OSPF is redistributed into the RIP and RIP redistributed into EIGRP I hope it helps
Redistribution of subnet 10.1.1.0/24 on from RIP to OSPF on R2 with create an OSPF route to 10.1.1.0/24 with AD of 110. This one is preffered over the RIP route to 10.1.1.0/24 with AD 120. Redistribution of RIP route 10.1.1.0/24 to EIGRP on R2 creates an external EIGRP route with AD 170. This route will not be chosen anyway. So if you set the AD of RIP to 100 on R2 that route is chosen to reach 10.1.1.0/24.
A - solves the problem because R2 trusts RI and sends the 10.1.1.0 traffic to the left. B - doesn't help because the problem is caused by redistributing the route from EIGRP to OSPF, not the other way around. C - suppresses the 10.1.1.0 route from EIGRP, thereby preventing PC4 from reaching the subnet. D - just ridiculous nonsense obviously.
typo - first line should say R2 trusts RIP
Definitely A.
it´s A
Correct Answer is A. Traffic flows for the prefix 10.1.1.10 from R1(RIP)--> R2 (RIP) --> R4 (EIGRP 170) -----> R3 (OSPF 110) --------> R2 (OSPF 110) In R2 OSPF AD(110) is preferred than RIP AD(120). Because of that R2 flushes the RIP prefix(10.1.1.10) out of its routing table. So R4 and R3 will flush that prefix consecutively.
R2# debug ip routing *Jan 9 18:22:41.547: RT: updating rip 10.1.1.0/24 (0x0): via 12.12.12.1 Fa0/0 1048578 *Jan 9 18:22:41.547: RT: add 10.1.1.0/24 via 12.12.12.1, rip metric [120/1] R2# *Jan 9 18:22:42.587: RT: updating ospf 10.1.1.0/24 (0x0): via 23.23.23.3 Fa2/0 1048578 *Jan 9 18:22:42.591: RT: closer admin distance for 10.1.1.0, flushing 1 routes *Jan 9 18:22:42.591: RT: add 10.1.1.0/24 via 23.23.23.3, ospf metric [110/20] R2# *Jan 9 18:22:46.707: RT: del 10.1.1.0 via 23.23.23.3, ospf metric [110/20] *Jan 9 18:22:46.707: RT: delete subnet route to 10.1.1.0/24
Ans. A is correct
Answer A
The core issue here is that When the RIP route redistributed from eigrp into OSPF on R3, R2 that is running OSPF will install the route as have better AD, causing the loop. The solution here then is use a distribute list to do not intall the EIGRP route ont the ospf procees and avoid the loop.
Given answer is correct. I was testing on GNS3 and is the best solution
It may seem that B solves the problem, which makes it difficult to choose an answer. But B removes only the EIGRP route that passed from R2 in a clockwise direction. The main problem is that on R2 there is an external OSPF route(counterclock-wise) that pulls all attempts to get to the PC1. If in answer B we swapped OSPF and EIGRP, then it would fit. .
if the red arrow in the picture is a symbol to a redistribution, what we should have in R2 are : OSPF is redistributed into RIP, RIP is redistributed into EIGRP and an arrow between OSPF and EIGRP that i can't see where it is pointing at.
This is a route looping problem, being the route is looping via redistribution from OPSF to EIGRP. Why would adding distance metric to RIP solve this?
Because when R2 is trying to get to 10.1.1.1, it will always go LEFT to the correct destination if it trusts the RIP routes over the OSPF routes. With RIP having AD of 100 it is trusted over OSPF which is 110.
The correct answer is: A
Looks like no answer is correct. Just labbed it. It works when you set an AD of 171 for OSPF routes on R2. But once the RIP distance is set to 100 on R2 instead R1 loses connectivity to PC3 because there is no redistribution from OSPF into RIP and the best route to PC3 in R2s routing table is via OSPF. So all routes from R3 must traverse EIGRP (since this is redistributed into RIP afterwards) which means that these routes must be in R2s routing table available via EIGRP. Nonetheless A makes most sense. r2#show running-config | s router router eigrp 1 default-metric 1000000 1 255 1 1500 network 24.24.24.0 0.0.0.255 redistribute rip route-map set-rip-tag router ospf 1 network 23.23.23.0 0.0.0.255 area 0 distance 171 router rip version 2 redistribute eigrp 1 metric 1 network 10.0.0.0 network 12.0.0.0 no auto-summary