Refer to the exhibits. A user on the 192.168.1.0/24 network can successfully ping 192.168.3.1, but the administrator cannot ping 192.168.3.1 from the LA router.
Which set of configurations fixes the issue?
A.
B.
C.
D.
Refer to the exhibits. A user on the 192.168.1.0/24 network can successfully ping 192.168.3.1, but the administrator cannot ping 192.168.3.1 from the LA router.
Which set of configurations fixes the issue?
A.
B.
C.
D.
The problem is that the administrator on the LA router cannot ping the 192.168.3.1 address, even though a user on the 192.168.1.0/24 network can. This indicates an issue with routing information propagation between the routers. In the given scenario, the Chicago router uses EIGRP and redistributes static routes to the NewYork router. However, the routes for the connected network 10.1.1.0/24 (on the LA side) are not known to the NewYork router. To fix this, the Chicago router needs to redistribute its connected routes so that NewYork will know how to reach the LA's 10.1.1.0/24 network. Therefore, the correct answer is to configure the Chicago router to redistribute connected routes into EIGRP, providing NewYork with the necessary routing information to respond to pings originating from the LA router. The correct configuration is option D, which ensures that the Chicago router includes its directly connected networks in EIGRP advertisements, thus solving the connectivity issue.
Correct answer is D and not C The administrator is isuing the ping from LA router, so the source IP will be 10.1.1.2 So when the reply comes back from 192.168.3.1 the destination will be 10.1.1.2 but the NewYork router doesn't have a route for that destination. If the redistribute static (without the metric) was not working then the first ping would also fail since NewYork router would not have a route to 192.168.1.0/24 Please correct if wrong.
For me, it is simply "D". Based on the topology, the networks 192.168.3.0/24 and 192.168.4.0/24 belong to the eigrp domain. Thus, "redistribute connected" under eigrp process is enough to provide connectivity from LA to NY. (I also confirmed it in a lab.)
Chicago router is only missing the connected route. So the simplest solution would be answer D
Emulated this in the lab and while eigrp has a redistribute static will advertise the external route to New York router, once the ICMP is sent back to New York from Chicago it is dropped as we don't have a route entry for the 192.168.3.* and 192.168.4.*. It says that with the initial config it works but it don't. There is no point in redistributing connected and no need of adding the static matrics. For me the correct answer is A, if we need the pings to work.
Because the ping from 192.168.1.0 works, this implies that NY has static routes routes to it and is sharing them with Chicago. The fact that the admins ping from LA doesn't work, implies that NY isn't aware of the 10.1.1.0 network. NY doesn't need to be aware of this network to reach the LAN networks off of LA, but to reach LA router itself, it must be made aware. This can be done by redistributing connected routes on Chicago.
D is the correct answer
D is correct. New york dosent know 10.1.1.0/24. C commands are for OSPF not EIGRP.
C is correct seed metric eigrp is infinity
A seed metric of 1 is given when redistributed from connected and static routing processes. So, if the redelivery source is connected or static, you do not need to set the seed metric.
C is the correct Answer.
The given answer is correct
D is correct
The question does not specify if EIGRP is configured for R3 on the network for 192.168.3.0 and 192.168.4.0 Assuming EIGRP is configured for 192.168.3.0 and 192.168.4.0 =================================================== The correct Answer is D. Why not A? Because in R3, it is configured with EIGRP 100 network 192.168.2.0 0.0.0.255 network 192.168.3.0 0.0.0.255 As a result, EIGRP will populate these 2 routes to R2. Hence, configuring a static route will do the trick, it defeats the purpose of EIGRP. Moreover, the static routes will have an AD of 1, which will then overwrite Eigrp AD of 90. Assuming EIGRP is NOT configured for 192.168.3.0 and 192.168.4.0 =================================================== The correct Answer is A.
c is the correct ans, you must specify metric if you're redistributing into eigrp
Correct answer is A. Tested in lab. B - wrong next-hop C - doesn't make sense, static routes will be available without metric too D - it changes nothing. The problem is absense of routes on Chicago to 3.0/24 and 4.0/24. That's why ping doesn't work. And A is the only way to fix it (except "redistribute connected" into EIGRP on NY)
After doing this lab, i think " Redistribute connected" is most appropriate....Because by doing 'redistributed connected routes", the 10.1.1.0/24 is being seen as EIGRP external route by the New-York router..
Ans should be A & D I lab it up, redistribute connected alone (on Chicago) don't work since Chicago didn't know how to reach 192.168.3.0/24 and 192.168.4.0/24
D is correct see the ip route 0.0.0.0 0.0.0.0 10.1.1.1 on LA router which enables Chicago router to route from LA to NY routers
Why not A ?
Well since the user can ping the 192.168.3.0 network, why would you place a static route to reach those networks? The issue is the traffic coming back. The admin ping is making it to the network but the traffic isnt coming back because there isnt a route back to the admin. Thats why you redistribute connected into EIGRP.
I think D is correct. For redistribute connected, EIGRP will have a look at the component metrics (bandwidth, delay, optionally reliability and load) of the interfaces where these networks are connected, and will compute the resulting metric out of these values. This is, by the way, precisely the same thing EIGRP would do if you had the networks added by a network command. https://community.cisco.com/t5/switching/eigrp-redistribute-connected/td-p/2878396