8.2 BGP Path Attributes and Route Selection

Read what an advertisement says

A BGP route contains more than a destination prefix. Its path attributes describe origin, AS traversal, next-hop information, and policy preferences. This lesson adds detail to the current course's introductory BGP topic; it does not imply that every advanced tie-breaker is a separate published 4A0-100 objective.

Begin with eligibility. A route rejected by import policy or lacking a usable next hop cannot become a usable path merely because it has an attractive AS_PATH. The selected BGP path must also compete appropriately with other route sources in the routing context.

Attribute categories

“Mandatory” does not mean every UPDATE packet contains all three familiar attributes. An UPDATE can only withdraw routes, and multiprotocol address families carry next-hop information in their applicable structures. Attribute presence and error handling must be interpreted in the message's actual context.

AS_PATH and ORIGIN

AS_PATH records AS traversal. An ordinary external advertisement prepends the sending AS. A receiver normally rejects a path containing its own AS to avoid an interdomain control-plane loop. Explicit features such as confederations or local-AS handling introduce additional rules; the basic model assumes these are absent.

A shorter AS_PATH can be preferred after earlier selection criteria tie. AS prepending repeats an ASN to influence another network's selection. It is a suggestion through attributes, not an instruction that overrides the other network's policies. Fewer AS entries do not guarantee lower delay.

ORIGIN has values IGP, EGP, and INCOMPLETE, ordered 0, 1, and 2 for ordinary comparisons. It describes how a route was introduced into BGP under the originating configuration. “IGP” is not a certificate of route stability, and a route learned through another protocol does not universally acquire a particular ORIGIN without considering export policy and implementation behavior.

NEXT_HOP must resolve

NEXT_HOP identifies where traffic toward the advertised destination should be sent. The BGP peer that delivered an update and the forwarding next hop need not be the same router.

Suppose a border router learns 203.0.113.0/24 externally with next hop 192.0.2.2 and advertises it internally. If an internal peer has no route resolving 192.0.2.2, the BGP session can be healthy while the path is unusable. The operator can provide suitable next-hop reachability or intentionally rewrite the next hop with a supported policy.

This reachability is recursive: the router resolves the advertised next hop through its routing and, where applicable, tunnel information until it has usable forwarding. A route's presence in a BGP display is not proof that it is active in the main FIB.

LOCAL_PREF and MED

LOCAL_PREF expresses internal preference for an exit. Higher values are preferred; SR OS uses 100 as its ordinary default. It is distributed within the AS, rather than normally advertised to external peers. Confederation behavior is a special case outside the simple model.

If two eligible paths to one prefix have LOCAL_PREF 200 and 100, the first normally wins before AS_PATH length is considered. This can intentionally prefer a longer AS path for business or policy reasons.

MULTI_EXIT_DISC (MED) suggests an entry preference to a neighboring AS. Lower values are preferred when MED is compared. By default, ordinary comparison is between applicable paths from the same neighboring AS; configuration can alter this behavior.

Neither attribute guarantees a particular traffic pattern. Route eligibility, more-specific destination advertisements, policy on other routers, and failures can change actual forwarding. LOCAL_PREF affects a route choice inside the AS; it is not a direct setting for all Internet senders.

A bounded selection example

The following simplified comparison assumes eligible conventional IPv4 BGP paths, equal route preference, no earlier differentiating feature, and ordinary path-selection settings. It illustrates common criteria rather than claiming an exhaustive SR OS algorithm.

LOCAL_PREF ties. Candidate B loses on AS_PATH length. A then beats C on ORIGIN. There is no need to compare their MED or internal next-hop distance after a winner is determined.

With LOCAL_PREF 200 on B instead, B wins the illustrated comparison despite its longer AS path. Always stop at the first applicable criterion that resolves the comparison.

When later criteria are needed, route source, next-hop distance, and identifier tie-breaks can matter. Consult the matching SR OS manual and configured path-selection options. Do not insert a Cisco-specific Weight mnemonic and call it Nokia's complete algorithm.

Verify the selected result

Inspect BGP route details for the prefix, peer, path attributes, and selection reason. Then inspect the main route table. A path selected as BGP's best can still lose to an eligible static route for the exact same prefix.

For a packet, perform longest-prefix match over installed routes afterward. An installed /25 can override an installed /24 for matching destinations regardless of the relative LOCAL_PREF used when each prefix's BGP path was chosen. Keeping these steps distinct avoids a common confusion between BGP path selection and packet forwarding.

Primary references

BGP specification and Nokia SR OS documentation, checked October 20, 2026. Use current release documentation for the full configurable selection procedure.