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.
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.
Yes the exhibit is tricky showing "Static Routing" however the static routing refers to the 192.168 networks from Chicago pointing to LA. Chicago doesn't have or need a static route to the directly connected 10.1.1.2 interface. If it already had a static route, then there would be full reachability, assuming we already redistributed static routes into EIGRP in the first place.
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.)
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.
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.
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
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.
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.
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
This section is not available anymore. Please use the main Exam Page.300-410 Exam Questions
Log in to ExamTopics
Sign in:
Community vote distribution
A (35%)
C (25%)
B (20%)
Other
Most Voted
A voting comment increases the vote count for the chosen answer by one.
Upvoting a comment with a selected answer will also increase the vote count towards that answer by one.
So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.
xqlz
Highly Voted 3 years, 5 months agobk989
8 months, 2 weeks agoHungarianDish_111
Highly Voted 1 year, 11 months ago[Removed]
Most Recent 9 months, 1 week agoMasterMatt
2 years agoDavid98898998
1 year, 10 months ago6dd4aa0
2 years agoforccnp
2 years, 1 month agoRouter
2 years, 7 months agojohnmcclane78
2 years, 9 months agoHack4
3 years, 2 months agokent2612
3 years, 2 months agoAliMo123
3 years, 1 month agoCarl1999
3 years, 2 months agogeek1992
3 years, 3 months ago[Removed]
3 years, 3 months agogeek1992
3 years, 3 months agoCarl1999
3 years, 2 months agoJOKERR
3 years, 4 months agomosvan
3 years, 8 months agoRS_nw
3 years, 8 months ago[Removed]
3 years, 8 months ago