R2 is receiving a route from an EBGP neighbor and is advertising the route to R4.
Referring to the exhibit, which configuration on R2 will solve the issue with the route on R4?
R2 is receiving a route from an EBGP neighbor and is advertising the route to R4.
Referring to the exhibit, which configuration on R2 will solve the issue with the route on R4?
The route issue on R4 is being caused by the no-advertise policy under group 65002, which is applied to the specific neighbor 44.44.44.44. This prevents the next-hop self policy from being considered. Moving the no-advertise policy to a global BGP policy ensures that it gets applied in a broader context and allows the next-hop self policy to be effectively utilized. This will resolve the next-hop issue, making the BGP route usable. Therefore, moving the no-advertise export policy from group 65002 to a global BGP policy is the correct solution.
A is the correct answer. B is not correct. If move NHS policy from global level to group 65002 level, this policy still not be considered because no-advertise policy is under neighbor 44.44.44.44 level and it is the most specific policy and it is only policy to be considered. If NHS policy is not considered, R2 will not change Next-hop of route when advertising to R4 >>> R4 show next-hop unusable.
Agree with A
As EBGP is established between R2 and R4, when R2 advertises routes to R4, R2 will change next-hop to its interface address without any policy. The NHS should be applied for IBGP and next hop address is loopback address. If NHS is applied to global, I wonder what is next hop address when R2 advertises routes to R4.
I missed both groups have export-policy. To enable NHS policy for group 65002, no-advertise must be moved from group 65002 neighbor 44.44.44.44 to the global in order not to prioritize no-advertise. A is the correct answer.
no-advertise means that R4 will not forward this prefix to another BGP neighbor, but it can use it and install it! B is valid, because only the most explicit policy is applied (no advertise), so nhs never gets to be applied. https://www.juniper.net/documentation/us/en/software/junos/routing-policy/bgp/topics/example/policy-bgp-levels.html
This route is not usable due to no NHS performed when advertising across the iBGP peer. This can be corrected by ether A or B. Considering NHS should only be done for IBGP peers, would choose B as best practice.
agree B is the most used config
A is the correct answer. B is not correct, if "nhs" policy move to group pilicey the is stil more specific policy under the neighbor 44.44.44.44 test on lab.
B is correct
agree with B, no-advertise tells R4 not to distribute the route to any other peer, but R4 itself can normally install route
A is the correct answer. Tested this in lab
B seems more correct, if we look at the output of show command, protocol next hop is 172.16.1.1 and this IP is of the neighbor in the AS 65001 (in different AS), i think the question is about solving nhs issue.
I think the correct answer is C As the router will not send it to it's peers. If you apply the no-advertise on export, the router will send it to it's peer while requesting they do not advertise it internally and externally...
B is correct because there is a problem, next hop unusable. The problem of next hop resolution is being caused because the prefix is being advertised to iBGP peer without next-hop-self action on policy. It's necessary to move nhs policy to group to solve that problem.