
Refer to the exhibit. R2 can access content on the server successfully. A network engineer finds packet drops on PC1 for traffic destined to network 2.2.2.2/32. Which action resolves the issue?
Refer to the exhibit. R2 can access content on the server successfully. A network engineer finds packet drops on PC1 for traffic destined to network 2.2.2.2/32. Which action resolves the issue?
In the present configuration, R2 is acting as a stub router, which means it only advertises connected and summary routes. For the static route 2.2.2.2/32 to be advertised to R1 through EIGRP, redistribution of the static route is required. The command 'redistribute static' under the EIGRP process on R2 introduces the static route into the EIGRP domain, allowing R1 to learn about it and resolve the packet drops on PC1 for traffic destined to network 2.2.2.2/32.
it is true the redistribute static command is needed but after that it still won't work... as the "eigrp stub static" & "eigrp stub connected" were typed as 2 separate commands the latter overwrote the first thus still no advertising of static routes..
Good point.
need to redistribute static
You've got right bro: https://community.cisco.com/t5/routing/eigrp-eigrp-stub-connected-static-summary/td-p/2575321#:~:text=the%20command%20%22%20eigrp%20stub%20connected,redistribute%20static%20routes%20in%20eigrp.
That makes sense, but why do they call it "redistribute static metric?"
Labbed it. R1 would not show an route to 2.2.2.2 until this command was removed from R2.
After modelling the scenario in CML: If R2 is a stub, then we need both B+C to be applied. "ip route 2.2.2.2 255.255.255.255 10.10.23.1" is configured on R2. => Static route is installed in the RIB. Redistribution of static under eigrp process is required to get this route advertised in eigrp (to R1). = "C" If only "eigrp stub connected" is configured, then R2 does not advertise the static route. We need "eigrp stub connected static". = "B"
IP address of R3 does not fit in the ip addressing scheme on the output.
2.2.2.2/32 is received by R1 as external route if static route+redistribute static are applied. Without redistribute static (and without stub), 2.2.2.2/32 is simply advertised as internal route in the eigrp domain.
2.2.2.2/32 is received by R1 as external route if static route+redistribute static are applied. Without redistribute static (and without stub), 2.2.2.2/32 is simply advertised as internal route in the eigrp domain.
vey sorry team, my previous answer is wrong because it is not possible to add the eigrp "stub connect static command" because this applies when I have a static route with the exit interface (not with the neighbor's IP) and declare the 2.2.2.2 network on router R2 . For this exercise, the correct answer is option "C", because the stub only announces the connected networks but does not redistribute static routes. To redistribute the static route it is necessary to use the "redistribute" command. Correct option is "C". I tested it in my laboratory in GNS3
You need B AND C. (in any case i think if you should pick only one, pick C as it is mandatory even if you are not using a stub config at all) B because comment "upp3r": it is true the redistribute static command is needed but after that it still won't work... as the "eigrp stub static" & "eigrp stub connected" were typed as 2 separate commands the latter overwrote the first thus still no advertising of static routes.. C because without redistribution the route will NOT be advertised at all, regardless of the "eigrp stub static" configuration (validated in lab). The stub config only tells what you are allowed to redistribute in your stub, it does not automatically redistribute these automatically.
Labbed it, R1 shows 2.2.2.2 even eigrp stub connected and static is configured on R2, i just redistributed static into eigrp. C is the correct asnwer.
I think the given answer is correct. Can you redistribute METRICS?? I think the correct is to redistribute ROUTES NOT METRICS, so A and C options are discarded for me. About option D, if you do that, you will get with nothing because it will erase the only eigrp stub command applied (this explains with the given reason by upp3r). So option B would be the best fit, although it is not complete until you configure the redistribute static command.
Another horrible written nonsense question FOR GOD SAKE! The point there is that is You cannot see the redistribute static in eigrp. So you cannot know if the static is redistributed... For sure you need both eigrp stub connected and static, otherwise cause R2 is a stub router is not gonna advertise nothing. So the point here is that I need both the commands eigrp stub connected static and I also need (Of course) the redistribute static command. I do not understand why they are saying static metric... They are saying this.... In eigrp you do not need to set a specific metric when you redistribute connected and static routes in eigrp because the router will get all the metric info using the phyisical interfaces, with the static route is gonna check th next hop interface and take the metric from there
I labbed in CML, and all the options are wrong. However, you definitely need to remove eigrp stub command, because even though you redistribute the static route, it will not advertise. Also, the route to R3 10.10.23.0/30 needs to be included in the routing table. Therefore, to make this route to happen, you need the following: 1)redistribute static route in R2 2) remove eigrp stub in R2 3) add network 10.10.23.0/30 in R2 eigrp 100
If R3 has a default route pointing to R2 we don't need to advertise 10.10.23.0/24 All we need to do is advertise the static route to R1 EIGRP peer. We do this with redistribute static and eigrp stub static. The link between R3 and R2 can be built with static routes.
The stub command is will not allow R2 to advertise the nei routes to avoid being used as a transit site.
yes, option B correct: eigrp stub connected static
the again please veryfy, the option correct is "B". I test in my lab
Overlapping commands would undo the redistribution of static
Option B is right but only if the scenario I cooked up is right, otherwise question should have said select 2 answers B & C. R2 is not advertising static route to R1 because redistribution is required Engineer did redistribution of static and route now appears in EIGRP table but R2 is still not advertising it to R1 Realises he also needs "eigrp stub static" due to the stubbiness of R2 Added command "eigrp stub static", solved problem but introduced a new one where R2 is no longer advertising its connected Loopback to R1 Quickly added "eigrp stub connected", solved loopback advertisement issue but back to square 1 "eigrp stub connected static" is required at this point to avoid the loopback advertisement issue
I believe that C and D are needed. If you will use, as mentioned, B and C, you will resolve issue only partially. R2 will advertise server IP to R1. But what about the PC1 subnet? R3 doesn't have IP info how to reach the PC1 with EIGRP stub feature configured on R2. Unless this subnet (R1-PC1) will be configured as static on R2 it will not work. Or am I wrong?
I would like to correct my answer. Only D is needed and correct answer
B is the correct answer from exam point of view ommand " eigrp stub connected static summary" will advertise local connected routes, static routes and summary routes. Having said that it will advertise static routes- does not mean that it will happen automatically. You need to redistribute static routes in eigrp.
Need to redistribute static into EIGRP and then configure the stub to advertise static. I would go for B and C
C is correct
C is correct
Since "eigrp static" was typed in first , then "eigrp connected" - this means that the eigrp static will not take effect as its overwritten. Having said the above I think the static route needs to be advertised into eigrp AS which is achieved by "eigrp static". testing in the lab yields the below: router eigrp 100 eigrp stub connected static So how is B not the correct answer? and how are metrics redistributed?