Refer to the exhibit.
AS65510 iBGP is configured for directly connected neighbors. R4 cannot ping or traceroute network 192.168.100.0/24.
Which action resolves this issue?
Exam 300-410 All QuestionsBrowse all questions from this exam
Question 68
Correct Answer: A
To resolve the issue where R4 cannot ping or traceroute to the network 192.168.100.0/24, the best approach is to address the iBGP route propagation. In iBGP, routers do not automatically pass learned routes to other iBGP peers. Using a route reflector simplifies route distribution. Configuring R1 as a route reflector server and R2 and R3 as route reflector clients ensures that the routes learned from R1 can be reflected to all iBGP peers, including R4. This configuration helps ensure that R4 will receive the necessary routes from R1 and be able to access the 192.168.100.0/24 network.
Discussion
timtgh
All answers are wrong. R1 and R4 do not see each other's routes because they are two hops apart. They need a route reflector between them, either R2 or R3.
Pietjeplukgeluk
Indeed the quality of the question is low. To have any solution work, you need to add neighbor config on top of the specified "directly connected". Spend you time well and understand why all are wrong.
IarnOption: B
Dont think it possible to be D as the question clearly states there is ONLY BGP relationship between directly connected devices, D is only possible if you stand a BGP relationship between R1 & R4, then you have a full mesh and dont need route reflector at all. If R2 & R3 are RR clients and R4 The RR. R1 advertises to R2 & R3 they then pas the route to the reflector.
glbngl91
Ehm... wrong, if you have connectivity between loopback via an IGP (or static routing), you can configure peering between two routers that are not directly connected... in my opinion D is not correct, but only because R1 is a border router and it's better not to configure it as a RR
JonnyBingo
None of the answers are correct. Lab'd it up. Only way for R4 (based on the question's requirement for directly connected iBGP neighbors) is if R2 or R3 or both to have R4 config'd as a route-reflector-client.
JonnyBingo
*only way for R4 to see the 192.168.100/24 route
inteldarvidOption: D
The anwser correct is D, because, router 1 y router 4 have to be RR
yasiramithOption: D
D is correct
HungarianDishOption: B
I came to the same conclusion as others. Some information is missing from this question, or the question is different in the real exam. I tested all "A", "B", "C", "D" in CML. The design of "A" and "B" does not work. "C" and "D" worked, of course, but not because of the RR configuration. We need to avoid setting the border router (R1) as RR. So, we can exclude "A" and "D". https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/212881-border-gateway-protocol-bgp-optimal-ro.html
HungarianDish
Normally, R2 OR R3 are the best candidates for becoming RR (the desired connection works without any further configurations), but such option is not given. If setting up R1 or R4 as the RR, we need to add IGP or static routes, so R1 and R4 can become neighbors first. In this case, we build a full mesh and we do not need any RR. The question says: "iBGP is configured for directly connected neighbors". -> It does not mention, but does not exclude either an underlay routing being configured for R1 and R4 neighborship. So, it might be a full mesh.
HungarianDish
+R1 needs next-hop-self for sure.
AinsBOption: D
IBGP will not readvertise a BGP learnt route to another IBGP neighbor, that is why we need a RR so that the route can get to R4. If R1 is the RR it can be advertised to R4 because a TCP connection will be created. Based on this scenario R2 & R3 could be RR and accomplish the same thing but they are not a part of the answer , it would be a much better design though
HungarianDish
Solution "C" has the same result, but it has the advantage that it does not use the border router R1 as an RR. The thing is that: If we make R1 and R4 become neighbors, and configure next-hop-self on R1, then it works without RR. Only R2 or R3 work well as RR.
Dacusai
I don't see a correct answer here, R2 and R3 will received routes from eBGP on R1 because is external so for R4 get those routes and R1 get routes from R4 you need to make them RRC on R2 and R3 with the command neighbor (ip) route-reflector-client for both R1 and R4. In that way R2 and R3 will send the routes to R4 and R1.
SeMo0o0o0Option: D
im going with D
cloud29Option: B
I vote for B. It is best practice to not set EDGE ROUTER (R1) as Route Reflector
RachnessOption: B
B: R1 is out, Can't set reflector at the edge of BGP, Must be centrally located to avoid issues. R4 makes sense to be reflector and the opposite, attached routers to be clients.
brownleafOption: C
Defo C
Omar0563Option: D
D Clients may also receive routes from non-clients that have been reflected by the router reflector
tinoe
R4 can only be a route reflector client of either R2 or R3 for the ping to work. This means for this scenario question there is no correct answer, all the answers are incorrect.
[Removed]Option: D
D is the only one that works but even then only if there is a direct peering between the routers (and the diagram implies there isnt).
SolidSnake74Option: A
Answer is A R4 can't reach 192.168.100.0/24 It means that R4 has most likely no routes received from any BGP neighbors. So, by setting R1 as RR with R2 & R3 as clients, they will get the routes from remote AS via R1. They can, then, just share it with their local neighbor which is R4. Route reflector rule 3 says : If an RR receives a route from an eBGP peer, it advertises the route to RR clients and non-RR clients
shiro990127Option: C
according to Cisco, R1 has to be RR client. https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/212881-border-gateway-protocol-bgp-optimal-ro.html -The border routers must be RR clients of the RR.