BGP: Peering, Path Selection, Route Reflection, and Communities
Peering
iBGP peers do not require direct connectivity in concept, but the next hop must be reachable via the IGP, and multihop plus local-address are typically needed. Because iBGP does not re-advertise iBGP-learned routes to other iBGP peers, you need a full mesh, route reflectors, or confederations. Remember next-hop-self when a route reflector or edge router must keep the next hop resolvable.
Scaling options
A route reflector adds originator-ID and cluster-list as loop prevention, and it does not change AS path or next hop. Client-to-client reflection happens only at the RR. Confederations split one AS into sub-ASs; confederation AS numbers are stripped at the boundary, so external peers see only the public AS.
Junos path selection (short form)
- Highest local-preference (default 100)
- Shortest AS path
- Lowest origin (IGP < EGP < incomplete)
- Lowest MED (compared only among paths from the same neighbor AS by default)
- eBGP over iBGP
- Lowest IGP metric to next hop
- Lowest router ID, then shortest cluster-list, then lowest peer address
Trap: Junos has no "weight" attribute, and local-preference is evaluated before AS path length. Also, BGP installs one best path unless multipath (and multipath multiple-as for eBGP) is configured.
Communities
Standard communities include well-known no-export, no-advertise and no-export-subconfed; large communities are widely used to carry 4-byte AS policy. Communities are matched in policy to drive local-preference, MED or advertisement decisions.
Worked example
Route A: local-preference 200, 4-hop AS path. Route B: local-preference 100, 1-hop AS path. Junos selects Route A - local-preference outranks AS path length.