11.3 BGP Attributes & Junos Path Selection Algorithm

BGP Attributes & Junos Path Selection Algorithm

Unlike Interior Gateway Protocols that compute shortest paths using scalar link metrics (such as OSPF cost or IS-IS metric), BGP determines optimal routes through a rich, multi-tiered collection of Path Attributes. Each BGP Update message advertising a prefix carries a payload of attributes describing the path's origin, history, administrative preference, and transit constraints.

When a Junos routing device receives multiple candidate paths to the exact same destination prefix, it executes the Junos BGP Path Selection Algorithm. This ordered mechanism evaluates eligibility, preference and attributes to choose a best route submitted to the Junos master routing table (inet.0).

---

1. Classification of BGP Path Attributes

RFC 4271 divides BGP path attributes into four distinct architectural categories based on whether an attribute must be supported by all implementations and whether it must be propagated across autonomous system boundaries:

+---------------------------------------------------------------------------------------------------+
| BGP PATH ATTRIBUTE CLASSIFICATION MATRIX                                                          |
+-----------------------+---------------------------------------+-----------------------------------+
| Category              | Definition & Handling Requirement     | Standard Attributes               |
+-----------------------+---------------------------------------+-----------------------------------+
| Well-Known Mandatory  | Must be recognized by all BGP         | - AS_PATH                         |
|                       | implementations; MUST be present in   | - NEXT_HOP                        |
|                       | every BGP Update advertising an NLRI. | - ORIGIN                          |
+-----------------------+---------------------------------------+-----------------------------------+
| Well-Known            | Must be recognized by all BGP         | - LOCAL_PREF                      |
| Discretionary         | implementations; MAY be included in   | - ATOMIC_AGGREGATE                |
|                       | an Update at sender's discretion.     |                                   |
+-----------------------+---------------------------------------+-----------------------------------+
| Optional Transitive   | May or may not be recognized by an    | - COMMUNITY                       |
|                       | implementation; if unrecognized, MUST | - AGGREGATOR                      |
|                       | be accepted and forwarded to peers.   |                                   |
+-----------------------+---------------------------------------+-----------------------------------+
| Optional              | May or may not be recognized by an    | - MULTI_EXIT_DISC (MED / Metric)  |
| Non-Transitive        | implementation; if unrecognized, MUST | - ORIGINATOR_ID                   |
|                       | be quietly discarded and NOT passed.  | - CLUSTER_LIST                    |
+-----------------------+---------------------------------------+-----------------------------------+

---

2. In-Depth Attribute Analysis

Well-Known Mandatory Attributes

1. AS_PATH: An ordered list of Autonomous System numbers that the route advertisement has traversed. Whenever an EBGP router advertises a route to an external peer, it prepends its own local ASN to the sequence. The AS_PATH serves two essential functions:
   • Loop Detection: If a router receives an Update containing its own local ASN anywhere in the AS_PATH, the route is rejected.
   • Metric / Path Length: Paths traversing fewer autonomous systems are preferred over longer paths. The attribute contains segments: AS_SEQUENCE (ordered list of traversed ASNs) and AS_SET (unordered set resulting from route summarization; an AS_SET counts as exactly 1 AS in path length calculations regardless of how many ASNs it contains).
2. NEXT_HOP: The IP address of the next-hop router used to forward transit packets toward the destination prefix. In EBGP, this is typically the IP address of the peer's interface. In IBGP, the external next-hop is preserved unchanged across the internal network.
3. ORIGIN: Identifies how the route was initially introduced into BGP. It carries one of three standardized values:
   • IGP (Value 0): The route has IGP origin. Junos export of local routes commonly assigns this origin; Junos does not use an IOS-style BGP network statement. Represented as IGP or i in routing tables.
   • EGP (Value 1): The prefix was learned via the legacy Exterior Gateway Protocol (RFC 904). Historical; rarely observed in production.
   • Incomplete (Value 2): The origin is unspecified/incomplete. Do not infer this value solely because a Junos export policy redistributed a static route; inspect the actual attribute or set it explicitly. Represented as Incomplete or ? in routing tables. Tiebreaker hierarchy: IGP is preferred over EGP, which is preferred over Incomplete (IGP < EGP < Incomplete).

Well-Known Discretionary Attributes

1. LOCAL_PREF (Local Preference): A 32-bit unsigned integer value used to indicate the degree of preference for a route within an Autonomous System. It is distributed exclusively within IBGP sessions and is stripped before routes are advertised to EBGP peers.
   • Junos Default: 100.
   • Evaluation: Higher is preferred. An enterprise administrator uses Local Preference on ingress border routers to select the primary outbound ISP for egress traffic.
2. ATOMIC_AGGREGATE: Informs downstream BGP speakers that an upstream router generated an aggregate route that caused path attribute details (such as specific ASNs) to be omitted.

Optional Attributes

1. COMMUNITY (Optional Transitive): A 32-bit numerical tag appended to routes to facilitate traffic grouping, filtering, and automated policy application across administrative domains.
2. MULTI_EXIT_DISC (MED / Metric - Optional Non-Transitive): A 32-bit value advertised by an autonomous system to convey its preferred ingress link to a neighboring AS when multiple connections exist between the same two autonomous systems.
   • Evaluation: Lower is preferred.
   • Propagation: Transmitted to an external peer, but that peer cannot re-transmit the MED value to third-party autonomous systems.
   • Junos Default Rule: Junos OS only compares MED values between routes received from the exact same neighboring Autonomous System. If two competing paths originate from different ASNs, Junos skips MED evaluation and proceeds to the next tiebreaker.

---

3. Junos Route Selection and BGP Tie-Breakers

First verify a usable next hop and compare Junos route preference (lower wins). BGP normally has preference 170 for both EBGP and IBGP, but a policy can change it. Equal default preference is why the attribute sequence matters; it is not a reason to omit preference when a scenario explicitly changes it.

For eligible BGP paths with equal route preference and without optional AIGP or other path-selection changes, the common sequence is:

Juniper’s complete RPD procedure additionally covers optional AIGP, strictly internal/local routes and primary-versus-secondary routes. These are not new universal steps to insert blindly into every basic BGP question. Start with the inputs actually supplied and identify the earliest comparison that differs.

Worked Attribute Decisions

Two reachable paths have equal preference 170. Path A has Local Preference 100 and AS path length 2. Path B has Local Preference 200 and AS path length 4. Path B wins because Local Preference is examined before AS path. A longer path does not overturn an earlier preference decision.

If both instead have Local Preference 100, compare AS path next. Each extra prepended AS in an AS_SEQUENCE increases its length; an AS_SET counts as one even if it contains several ASNs. Neither metric is an IGP hop count. For equal AS paths, IGP origin beats Incomplete; origin describes the route attribute rather than the current transport protocol.

MED Scope and Overrides

When two paths come from the same neighboring AS, a lower MED can choose the preferred entry into that AS. Paths from different neighboring ASs normally skip this comparison. set protocols bgp path-selection always-compare-med changes that behavior. A missing MED is treated as zero by the documented Junos procedure. The cisco-non-deterministic option changes ordering/grouping of comparisons; it is not the switch that disables the older-EBGP-path rule.

The stability preference has explicit exceptions, including path-selection external-router-id, identical peer router IDs, confederation peers, or neither path being the current active path. Use external-router-id when deliberately bypassing that stability preference; do not describe the rule as choosing the “lowest age,” which misleadingly suggests the newest path.

Route Reflection and Multipath

An unresolved next hop renders a path hidden regardless of a desirable Local Preference. Inspect show route hidden extensive and verify next-hop reachability before changing attributes. Hidden and inactive are different: an inactive route may be valid but lose to another route.

For reflected paths, compare originator IDs in place of peer router IDs, then cluster-list length before peer IP address. Otherwise, a router could select the wrong route in an exam scenario with identical originator IDs and different reflection paths. Equal-cost forwarding also requires applicable BGP multipath and forwarding installation; two received paths are not automatic proof that both carry traffic.

Official references checked 2026-10-18: Junos BGP defaults and selection.