BGP
What the BGP domain tests
This domain tests eBGP and iBGP behavior in Junos: next-hop reachability, best-path selection, route reflection, communities, and policy. The exam expects you to trace why a route is present in BGP but absent from the forwarding table.
Core rules
- BGP prefers higher local preference, then shorter AS path, then lower origin, then lower MED; eBGP is preferred over iBGP, then lower IGP cost to next hop, then lower router ID.
- iBGP does not change the next hop by default; the next hop must be reachable through IGP or a static route.
- A route reflector reflects iBGP routes to clients; cluster ID and originator ID prevent loops.
- Policy controls advertisement and acceptance; a community is a transitive tag unless configured otherwise.
Worked example
A route reflector receives 203.0.113.0/24 from an eBGP peer and reflects it to an iBGP client. The client shows the route as hidden because the next hop 192.0.2.1 is unreachable. The RR did not rewrite the next hop. Applying next-hop-self on the RR for the iBGP group changes the next hop to the RR loopback, which the client reaches via OSPF. The route becomes active.
Traps
Do not expect BGP to load-balance identical paths unless multipath is enabled. Do not use multihop for eBGP without a policy reason. Do not assume local preference is transitive across eBGP; it is not. Check that communities and policy match intent.