Click the Exhibit button.
You implemented the configuration shown in the exhibit on your route reflector device. However, you notice
traffic is transiting the route reflector rather than taking the optimum path.
Which two actions would solve the problem? (Choose two.)
A.
Change the policy to match on the external BGP neighbor.
B.
Change the policy to match on the internal BGP neighbor.
C.
Change a direct peering session between both internal neighbors and use the multihop parameter.
D.
Change a direct peering session between both internal neighbors and use the no-client-reflect parameter.
Explanation:
The no-client-reflect command disables intracluster route redistribution by the system acting as the route
reflector. Include this statement when the client cluster is fully meshed to prevent the sending of redundant
route advertisements. Route reflection provides a way to decrease BGP control traffic and minimizing the
number of update messages sent within the AS.
https://www.juniper.net/documentation/en_US/junos16.1/topics/concept/routing-protocol-bgpsecurity-route-reflector-understanding.html
I think A,D is correct
A.
from protocol bgp
neighbor 23.56.83.209
then next-hop self
Next hop will be changed only for External reachability.
0
0
The options are B and D. Route Reflector reflects your internal routes and you don’t need next hop self configured for external peers. hope this helps!
3
0
I am also for A,D
0
0
reason is if you dont mention internal or external BGP neighbor in the policy then RR will do next hop self attribute change for even internal learnt routes, which is not the intention here. because internal clients reach ability is via IGP. however next hop self is required only for eBGP learnt routes.
0
0
agree with Raju, it should be A&D
0
0
https://kb.juniper.net/InfoCenter/index?page=content&id=KB12214
The best practice when setting up BGP is to have a policy on the BGP global level set as:
user@router# show policy-options
policy-statement bgp-export {
term ebgp {
from route-type external;
then {
next-hop self;
accept;
}
}
term ibgp {
from route-type internal;
then accept;
}
}
By default, all eBGP routes are advertised to iBGP peers. In other words, they are already “accepted” in the default export policy. Any new policy applied to the peer(s) will have a default catch-all accept term at the end. We don’t need to have an explicit “then accept” term.
However, by default, routes learnt from eBGP peers are advertised to iBGP peers with next hop (of eBGP) unchanged. If iBGP neighbours do not have routes to the next hop, all routes learnt are hidden. We need a term “then next-hop self” for that purpose.
0
0
group group-name {
type internal;
peer-as autonomous-system;
cluster cluster-identifier;
no-client-reflect;
neighbor address3;
neighbor address4;
}
you must have iBGP full mesh
0
0
Options A & D final answer.
Next-hop self is used to advertised routes received from the eBGP to the internal bgp neighbors.
A Router Reflector is always choosen from the internal BGP groups and have nothing to do with next-hop-self, unless if it is also used for peering to another AS. The primary purpose of a route reflector is to advertise routes received from a client to other iBGP routers which is normally not possible because of split-horizon.
So in this case, the route reflector have external bgp peering, therefore the policy should be changed to match on routes received from the eBGP neighbor.
1
0
Explanation:
A. Change the policy to match on the external bGP neighbor
!
set policy-options policy-statement nhs from protocol bgp
set policy-options policy-statement nhs from route-type external
set policy-options policy-statement nhs then next-hop self
!
set protocols bgp group INT export nhs
!
D. Change a direct peering session between both internal neighbors and use the no-client-reflect parameter.
!
set protocols bgp group INT no-client-reflect
!
1
0