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.
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!
I am also for A,D
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.
agree with Raju, it should be A&D
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.
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