Exam 300-410 topic 1 question 444 discussion

Answer is A Can't be B, because if it has been the case, no route at all from R2 would have been learned Can't be C, because a metric mismatch leads in no neighbor relationship and we have Can't be D, Split horizon is enabled by default and it just avoid sharing the network via a same interface it received. It means i can GET routes from R2 but not just sharing them back to R2 via the same interface.

I think B is correct.

Key word: "some prefixes are not showing"

+1 for B. The question implies "both routers are advertising subnets to its neighbor", so we can discard option A.

If the EIGRP adjacency is already formed between R1 and R2, then the issue is likely not related to the network statement. Given that the adjacency is already established, the next most likely cause of the issue is indeed related to the Router ID

Answers is B

I think C is the correct answer. In short, we just need to solve the fact that a certain prefix is not elected as a feasible succesor, don't you think? The condition for being elected as a feasible succesor is FD of the succesor > RD of a certain root.

"Some prefixes are not showing R2 as a successor" I am looking at the diagram and am not sure what prefixes the exhibit is referring to? Would not choose C or D C - neighborship wouldn't form if K values are not correct/matching D - split horizon is enabled by default A - network statement has already been configured because there are routes learned by R2, unless I'm missing something. B. Not sure, R1- show ip eigrp topology R1 has a router-id of 172.16.10.1 what is the router ID of R2? If it is duplicate, that could be a reason why routes are not showing as a successor

just as fyi I labbed the same lab as JohnnyBingo(below) and had the same exact issue. The D EX routes weren't going to R1 from R2 (like Pietjeplukgeluk mentions), until I made unique router-ids. Answer = B on this one. When Route-ID's are same, the external eigrp routes not showing up. The networks sourced from the router itself are showing up. Therefore SOME prefixes are not showing up (as question mentions). Please lab.

Answer B Routers ID are duplicated. both routers already tried to advertise their LOCAL subnets, which mean A is useless.

A is correct

Agree with SolidSnake74

EIGRP will form adjacency with another router with a matching ID but will not install routes ORIGINATED from that router. It will however install routes that did not originate from that router that it received in the Update.

The Answer is B. Lab'd it. 3 router topology. R1, R2, and R3. R1 and R2 have the same ip addresses as indicated. R2 and R3 have a link between them (201.165.101.1 and .2 respectively. R3 has the 192 addresses on loopback interfaces. When you let EIGRP choose the router-id's all links show up, even the link between R2/R3. When you match the router-id to 1.1.1.1 on R1 and R2, the link between R2 and R3 goes away and you are left with the exact same output that is displayed in the exhibit.

I think A

Correct answer is B I have just labbed this up, two EIGRP routers with the same router ID, they did not accept each others locally generated routes, however all other EIGRP learned routes that did not originate from them were accepted It does make sense for the receiving router to feel weird receiving a route with its own router ID as the originating router, as soon as I changed the router ID on one of them, they both accepted each others locally generated routes (installed them in the topology table), changed router ID to match again and the routes disappeared again. The reason some routes shows up according to the question is because those routes were not generated by R2

as explained by solidsnake74. The best answer is A. B, the router ID is different, otherwise no routes would be learned at all, neighborship forms, but no routes learned. C, no neighborship with an error message pointing out K-value mismatch D, no.