BGP Path Selection Algorithm: Network Engineering Guide

Introduction and Core Concepts

The bgp path selection algorithm is the deterministic decision-making process that Border Gateway Protocol (BGP) speakers use to choose a single best path to each destination prefix when multiple candidate paths exist. Unlike interior gateway protocols that primarily optimize for shortest path, BGP is a path-vector protocol designed for policy-based routing between autonomous systems (ASes). The algorithm does not simply find the fastest route; it enforces administrative policy, business relationships, and traffic engineering goals across the global Internet.

At its core, BGP is the glue of the Internet. Every major service provider, cloud region, and large enterprise that connects to multiple upstream providers or peers relies on BGP to exchange reachability information for hundreds of thousands of prefixes. When a router receives multiple advertisements for the same prefix, such as 8.8.8.0/24 from three different neighbors, it cannot install all three into the forwarding table. The bgp path selection algorithm provides a strict, ordered tie-breaking hierarchy to select exactly one best path for installation in the Routing Information Base (RIB) and subsequent advertisement to peers.

Understanding this algorithm is critical because it directly determines outbound traffic flow, inbound traffic influence, resilience, and cost. A misconfiguration of BGP attributes can cause suboptimal routing, asymmetric paths, transit loops, or expensive traffic tromboning through a paid transit provider instead of a free peering link. For network engineers, the algorithm is not an abstract concept but a daily operational tool for implementing routing policy.

Key concepts underpinning the algorithm include BGP path attributes. These are properties attached to each route advertisement. Some are well-known and mandatory, such as AS_PATH and NEXT_HOP, while others are optional or transitive. The selection algorithm evaluates these attributes in a specific sequence, and the first attribute that differs between two paths decides the winner. If all attributes are equal, a final tie-breaker such as the lowest router ID is used. This deterministic nature ensures that all BGP implementations, when given identical inputs and policies, converge to the same decision.

How It Works

The bgp path selection algorithm is implemented as a sequential comparison. Cisco's implementation, which has become the de facto reference, uses up to 13 steps. Other vendors like Juniper and Arista use a nearly identical order with minor differences, such as the handling of Weight, which is Cisco-proprietary. The process stops at the first step where one path is clearly superior.

The Canonical Decision Steps

The algorithm evaluates candidate paths in the following order. It is crucial to memorize this hierarchy, as changing an attribute higher in the list will always override any attribute lower in the list.

1. Weight (Cisco only): Highest Weight wins. This is locally significant to the router and never advertised to peers. Default is 0 for learned routes and 32768 for locally originated routes.
2. Local Preference (LOCAL_PREF): Highest Local Preference wins. This is exchanged only within an AS via iBGP and is used to prefer an exit point from the AS. Default is 100.
3. Locally Originated: Prefer routes originated by the local router via a network or aggregate command, or redistributed, over routes received from a peer.
4. AS_PATH Length: Shortest AS_PATH length wins. This is the count of AS numbers in the path, representing the number of autonomous systems traversed.
5. Origin Type: Lowest Origin code wins, where IGP (i) < EGP (e) < Incomplete (?). IGP indicates the prefix was injected via a network statement, while Incomplete typically means redistribution.
6. Multi-Exit Discriminator (MED): Lowest MED wins. MED is exchanged between eBGP peers to influence inbound traffic from a neighboring AS. It is only compared if the neighboring AS is the same for both paths, unless bgp always-compare-med is enabled.
7. eBGP over iBGP: Prefer eBGP-learned paths over iBGP-learned paths.
8. IGP Metric to NEXT_HOP: Lowest IGP metric to the BGP next-hop wins. This is the hot-potato routing step, preferring the closest exit.
9. Oldest Path: If multipath is not enabled, prefer the oldest path to minimize flapping.
10. Router ID: Lowest BGP Router ID wins.
11. Cluster List Length: Shortest Cluster List wins (for route reflector environments).
12. Neighbor Address: Lowest neighbor IP address wins as a final tie-breaker.

Attribute Scope and Influence

Attributes differ in scope. Weight and Local Preference control outbound traffic leaving your AS. AS_PATH prepending and MED are primary tools to influence how other ASes send traffic into your AS. For example, prepending your AS number multiple times makes a path appear longer and thus less desirable to remote networks, allowing you to make a backup link less preferred without dropping the advertisement entirely. Understanding the direction of influence is essential for traffic engineering.

Another critical mechanism is that BGP only compares MEDs from the same neighboring AS by default. This prevents unfair comparison between MED values that have different meanings in different ASes. Similarly, the IGP metric step implements hot-potato routing, where the AS tries to get traffic out of its own network as quickly as possible by choosing the nearest egress point according to its interior protocol like OSPF or IS-IS.

Implementation

Implementing the bgp path selection algorithm in software requires modeling BGP attributes and then applying the ordered comparison logic. Below are Python examples that simulate the decision process as it would occur on a router.

Modeling BGP Paths and Attributes

from dataclasses import dataclass, field
from typing import List, Optional
from ipaddress import IPv4Address

@dataclass
class BGPPath:
    """Represents a single BGP path advertisement for a prefix."""
    prefix: str
    next_hop: str
    weight: int = 0  # Cisco proprietary, local to router
    local_pref: int = 100
    originated_locally: bool = False
    as_path: List[int] = field(default_factory=list)
    origin: str = "IGP"  # IGP, EGP, INCOMPLETE
    med: int = 0
    learned_via_ebgp: bool = True
    igp_metric_to_nexthop: int = 0
    router_id: str = "0.0.0.0"
    peer_ip: str = "0.0.0.0"
    age_seconds: int = 0

    @property
    def as_path_length(self) -> int:
        return len(self.as_path)

    @property
    def origin_rank(self) -> int:
        # Lower rank is more preferred: IGP (0) < EGP (1) < INCOMPLETE (2)
        ranking = {"IGP": 0, "EGP": 1, "INCOMPLETE": 2}
        return ranking.get(self.origin, 2)

# Example: Create candidate paths for 203.0.113.0/24
path_a = BGPPath(
    prefix="203.0.113.0/24",
    next_hop="192.0.2.1",
    local_pref=200,  # High preference - primary exit
    as_path=[65001, 64512, 64500],
    med=50,
    igp_metric_to_nexthop=20,
    router_id="10.0.0.1",
    learned_via_ebgp=True
)

path_b = BGPPath(
    prefix="203.0.113.0/24",
    next_hop="192.0.2.2",
    local_pref=100,
    as_path=[65002, 64500],  # Shorter AS_PATH
    med=10,
    igp_metric_to_nexthop=5,
    router_id="10.0.0.2",
    learned_via_ebgp=True
)

Core Selection Logic

def compare_bgp_paths(path1: BGPPath, path2: BGPPath) -> BGPPath:
    """
    Implements the full Cisco-style bgp path selection algorithm.
    Returns the best path between path1 and path2.
    Comparison stops at the first decisive attribute.
    """
    # 1. Highest Weight wins
    if path1.weight != path2.weight:
        return path1 if path1.weight > path2.weight else path2

    # 2. Highest Local Preference wins
    if path1.local_pref != path2.local_pref:
        return path1 if path1.local_pref > path2.local_pref else path2

    # 3. Prefer locally originated routes
    if path1.originated_locally != path2.originated_locally:
        return path1 if path1.originated_locally else path2

    # 4. Shortest AS_PATH length wins
    if path1.as_path_length != path2.as_path_length:
        return path1 if path1.as_path_length < path2.as_path_length else path2

    # 5. Lowest Origin type wins
    if path1.origin_rank != path2.origin_rank:
        return path1 if path1.origin_rank < path2.origin_rank else path2

    # 6. Lowest MED wins (simplified: assumes same neighboring AS)
    if path1.med != path2.med:
        return path1 if path1.med < path2.med else path2

    # 7. Prefer eBGP over iBGP
    if path1.learned_via_ebgp != path2.learned_via_ebgp:
        return path1 if path1.learned_via_ebgp else path2

    # 8. Lowest IGP metric to NEXT_HOP wins (hot-potato)
    if path1.igp_metric_to_nexthop != path2.igp_metric_to_nexthop:
        return path1 if path1.igp_metric_to_nexthop < path2.igp_metric_to_nexthop else path2

    # 9. Oldest path wins (lowest age is actually older if we track uptime)
    # Here we prefer smaller age_seconds as older for simplicity
    if path1.age_seconds != path2.age_seconds:
        return path1 if path1.age_seconds < path2.age_seconds else path2

    # 10. Lowest Router ID wins
    if path1.router_id != path2.router_id:
        return path1 if IPv4Address(path1.router_id) < IPv4Address(path2.router_id) else path2

    # 11. Lowest peer IP wins (final tie-breaker)
    return path1 if IPv4Address(path1.peer_ip) < IPv4Address(path2.peer_ip) else path2


def select_best_path(paths: List[BGPPath]) -> Optional[BGPPath]:
    """Select best path from a list of candidates using iterative comparison."""
    if not paths:
        return None
    best = paths[0]
    for candidate in paths[1:]:
        best = compare_bgp_paths(best, candidate)
    return best

Policy-Based Filtering and Route Maps

def apply_route_map(path: BGPPath, route_map_rules: dict) -> BGPPath:
    """
    Simulates a route-map that modifies attributes on ingress/egress.
    This is how operators implement traffic engineering before selection.
    """
    # Example rule: Increase LOCAL_PREF for routes from a preferred peer
    if path.next_hop in route_map_rules.get("prefer_next_hops", []):
        path.local_pref = route_map_rules.get("preferred_local_pref", 200)
        print(f"Route-map: Set LOCAL_PREF {path.local_pref} for {path.prefix} via {path.next_hop}")

    # Example rule: Prepend AS_PATH to de-prefer a backup link
    if path.next_hop in route_map_rules.get("prepend_next_hops", []):
        prepend_count = route_map_rules.get("prepend_count", 2)
        # Prepend our own AS (e.g., 65000) multiple times
        path.as_path = [65000] * prepend_count + path.as_path
        print(f"Route-map: Prepended AS_PATH to {path.as_path}")

    # Example rule: Set MED for inbound traffic influence
    if "set_med" in route_map_rules:
        path.med = route_map_rules["set_med"]

    return path

# Usage example
rules = {
    "prefer_next_hops": ["192.0.2.1"],
    "preferred_local_pref": 250,
    "prepend_next_hops": ["192.0.2.2"],
    "prepend_count": 3
}
path_b_modified = apply_route_map(path_b, rules)
# Now path_b will have longer AS_PATH and may lose even though it was shorter before

Simulating Full Decision with ECMP Support

def select_best_paths_with_ecmp(paths: List[BGPPath], allow_ecmp: bool = False) -> List[BGPPath]:
    """
    Select best path(s) with optional Equal-Cost Multi-Path (ECMP) support.
    ECMP allows multiple best paths if attributes up to IGP metric are equal.
    """
    if not paths:
        return []

    # First find the single best path
    best = select_best_path(paths)
    
    if not allow_ecmp:
        return [best]

    # For ECMP, find all paths equal to best up to step 8 (IGP metric)
    ecmp_group = []
    for p in paths:
        is_equal = (
            p.weight == best.weight and
            p.local_pref == best.local_pref and
            p.originated_locally == best.originated_locally and
            p.as_path_length == best.as_path_length and
            p.origin_rank == best.origin_rank and
            p.med == best.med and
            p.learned_via_ebgp == best.learned_via_ebgp and
            p.igp_metric_to_nexthop == best.igp_metric_to_nexthop
        )
        if is_equal:
            ecmp_group.append(p)
    
    print(f"ECMP group size: {len(ecmp_group)} paths")
    return ecmp_group

# Test ECMP scenario
paths = [path_a, path_b, path_b_modified]
best_only = select_best_paths_with_ecmp(paths, allow_ecmp=False)
best_ecmp = select_best_paths_with_ecmp(paths, allow_ecmp=True)

Step-by-Step Example

Consider a border router in AS 65000 that learns the prefix 198.51.100.0/24 from four different peers. The router must run the bgp path selection algorithm to choose one best path. The candidate paths have the following attributes after inbound route-maps have been applied.

Path 1 is learned via eBGP from ISP-A (AS 64510) with LOCAL_PREF 100 (default), AS_PATH [64510, 64500], MED 20, IGP metric 10 to its next-hop 192.0.2.10, and Router ID 10.0.0.10. Path 2 is learned via eBGP from ISP-B (AS 64511) with LOCAL_PREF 200, AS_PATH [64511, 64500, 64500], MED 10, IGP metric 5, and Router ID 10.0.0.11. Path 3 is learned via iBGP from an internal route reflector with LOCAL_PREF 200, AS_PATH [64510, 64500], MED 20, IGP metric 15, and Router ID 10.0.0.12. Path 4 is locally originated via a network statement with LOCAL_PREF 100, AS_PATH [], MED 0, IGP metric 0, and Router ID 10.0.0.1 (the local router).

The selection proceeds step by step. Step 1 Weight is equal (0) for all learned paths except Path 4 which would have higher weight if locally originated, but we assume Weight is not configured, so all are 0 and we continue. Step 2 Local Preference is decisive. Path 2 and Path 3 both have LOCAL_PREF 200, which is higher than Path 1 and Path 4 with 100. Therefore Path 1 and Path 4 are eliminated immediately, even though Path 4 was locally originated and Path 1 had a short AS_PATH. This demonstrates that Local Preference overrides almost everything else within an AS.

Now only Path 2 and Path 3 remain. Step 3 Locally Originated does not apply as neither is locally originated. Step 4 AS_PATH length is compared. Path 3 has length 2 ([64510, 64500]), while Path 2 has length 3 ([64511, 64500, 64500] due to prepending). Path 3 would normally win here, but recall that Local Preference already tied them. Wait, we must re-evaluate: both have LOCAL_PREF 200, so we move to step 4. Path 3's AS_PATH is shorter, so Path 3 would be selected at this step. However, if the operator had not prepended Path 2, both would have length 2 and we would continue.

For illustration, assume Path 2 was not prepended and both have AS_PATH length 2. Step 5 Origin is IGP for both, so no decision. Step 6 MED is compared. Path 2 has MED 10, Path 3 has MED 20. Since both paths came from different neighboring ASes (64511 vs 64510), MED would normally not be compared unless bgp always-compare-med is enabled. With default behavior, MED is skipped and we move to Step 7. Step 7 prefers eBGP over iBGP, so Path 2 (eBGP) wins over Path 3 (iBGP) and is selected as best. If both were eBGP, Step 8 would compare IGP metrics (5 vs 15) and Path 2 would still win via hot-potato routing. This walkthrough shows how a single attribute change at a higher step can completely alter the outcome.

Complexity Analysis

The bgp path selection algorithm is computationally lightweight per prefix, but its scaling characteristics are critical because a full Internet routing table contains over 900,000 IPv4 prefixes and 200,000 IPv6 prefixes. Each prefix may have multiple candidate paths, typically 2 to 8 in a well-connected network.

For a single prefix with n candidate paths, the algorithm performs a linear scan, comparing each candidate to the current best using a constant-time sequence of up to 12 attribute checks. Therefore, the time complexity per prefix is O(n), where n is the number of paths for that prefix. Since n is small and bounded, this is effectively O(1) per prefix. For the entire RIB with p prefixes, total time is O(p * n), which scales linearly with table size. This is highly efficient and allows routers to reconverge quickly after a peer failure.

Space complexity is O(p * n) to store all candidate paths in the BGP RIB (Adj-RIB-In), plus O(p) for the best paths installed in the Loc-RIB and FIB. In practice, memory is dominated by storing path attributes, especially AS_PATH, which can be up to 255 AS hops long. Modern routers use efficient packing and share attribute structures between paths to reduce memory overhead.

Best case occurs when the first attribute (Weight or Local Preference) differs, requiring only one comparison. Worst case occurs when all paths are nearly identical and the algorithm must traverse all 12 steps down to the final tie-breaker. However, even the worst case remains constant time per comparison.

In real deployments, BGP convergence time is dominated not by algorithm complexity but by I/O, policy processing, and the MinRouteAdvertisementInterval (MRAI) timer that rate-limits updates. Optimizations such as BGP PIC (Prefix Independent Convergence) precompute backup paths to achieve sub-second failover without re-running the full selection.

Variations and Optimizations

While the core bgp path selection algorithm is standardized in RFC 4271, vendors implement important variations and extensions to improve scalability and flexibility.

Vendor-Specific Variations

Cisco's Weight attribute is the most notable deviation. Because Weight is evaluated before Local Preference and is never advertised, it allows a single router to override AS-wide policy for local traffic engineering without affecting iBGP peers. Juniper, by contrast, does not implement Weight and instead relies on Local Preference with careful import policy. Juniper also adds a step to prefer paths with higher Local Preference that are already active, and it evaluates MED differently when multipath is configured. Arista and other vendors closely follow Cisco's order but may expose knobs like bgp bestpath as-path ignore to skip AS_PATH length comparison entirely, which is useful when peering with ASes that prepend excessively.

BGP Multipath and Add-Path

Standard BGP installs only one best path, which limits bandwidth utilization when multiple equal-cost links exist. BGP Multipath relaxes this by installing multiple best paths when attributes up to a certain step (typically IGP metric) are equal. This enables Equal-Cost Multi-Path (ECMP) load sharing across up to 16 parallel links, dramatically increasing throughput without additional protocols. BGP Add-Path is a more recent extension that allows a router to advertise more than one path per prefix to its peers, improving diversity and faster convergence in route reflector topologies where only the best path is normally reflected.

Deterministic MED and Always-Compare-MED

By default, MED comparison is non-deterministic because the order in which paths are compared can affect the result when paths come from different ASes. Enabling bgp deterministic-med ensures paths are grouped by neighboring AS before comparison, guaranteeing a consistent best path regardless of arrival order. bgp always-compare-med forces MED comparison across all paths, even from different ASes, which can be useful in tightly coordinated networks but risks incorrect decisions if MED semantics differ between providers.

Route Reflectors and Confederations

In large ASes with many iBGP peers, a full mesh is impractical. Route reflectors and confederations reduce peering complexity from O(n²) to O(n) but introduce subtle interactions with path selection. A route reflector only advertises its best path, so clients may not see all candidates and could make suboptimal decisions. Modern optimizations like diverse-path route reflectors and optimal route reflection compute the best path from the client's perspective using the client's IGP metric, not the reflector's, restoring optimal hot-potato routing.

Real-World Applications

The bgp path selection algorithm is not confined to carrier core routers; it influences every Internet-connected system, from hyperscale data centers to enterprise SD-WAN deployments.

In Internet Service Provider (ISP) networks, the algorithm is the primary traffic engineering tool. An ISP with multiple transit providers will set Local Preference to prefer cheaper or higher-capacity links for outbound traffic, while using AS_PATH prepending and MED to influence inbound traffic. For example, a tier-1 provider might set LOCAL_PREF 300 for customer routes, 200 for peering routes, and 100 for transit routes, ensuring customer traffic is always preferred regardless of AS_PATH length. This implements the classic valley-free routing policy that underpins Internet economics.

Hyperscale cloud providers like AWS, Google Cloud, and Azure use BGP extensively within their private backbones and at the edge. Inside the data center fabric, BGP with ECMP is used as a scalable alternative to traditional IGPs for Clos topologies, where thousands of switches need to exchange reachability with fast convergence. At the edge, cloud providers use BGP communities and Local Preference to steer traffic between regions, implement cold-potato routing to keep traffic on their private backbone as long as possible, and provide Anycast services where the same prefix is advertised from multiple global points of presence and BGP naturally selects the closest.

Enterprises leverage BGP for multi-homing and disaster recovery. A company connected to two ISPs can use the algorithm to make one ISP primary and the other backup by setting higher Local Preference on the primary link. If the primary fails, BGP automatically re-runs selection and fails over to the backup path within seconds. SD-WAN controllers automate this by dynamically adjusting BGP attributes based on link quality, latency, and cost.

Comparison with Alternatives

BGP is often contrasted with Interior Gateway Protocols (IGPs) and other path selection strategies. Unlike IGPs that optimize for a single metric like cost or bandwidth, BGP is explicitly policy-driven and scales to hundreds of thousands of prefixes across administrative boundaries.

OSPF and IS-IS are link-state protocols that use Dijkstra's Shortest Path First (SPF) algorithm to compute the lowest-cost path based on interface metrics. They converge quickly within an AS but are unsuitable for inter-domain routing because they lack policy controls and would require every router to maintain a global link-state database. EIGRP uses the Diffusing Update Algorithm (DUAL) and offers fast convergence with feasible successors, but it is Cisco-proprietary and limited to a single administrative domain.

Static routing, the simplest alternative, involves manually configuring next-hops. It has zero overhead but no adaptability and cannot implement the dynamic policy that BGP provides. For small networks with a single upstream, static default routes are often sufficient, but they cannot handle multi-homing or traffic engineering.

In practice, these protocols are complementary. A typical enterprise network runs OSPF or IS-IS internally to distribute next-hop reachability and uses BGP at the edge for external connectivity. The IGP metric to the BGP next-hop is itself an input to the bgp path selection algorithm (step 8), illustrating how the two layers interact to achieve hot-potato routing.

Common Mistakes and Best Practices

Misunderstanding the strict order of the bgp path selection algorithm is the source of many outages and suboptimal routing. A common pitfall is attempting to influence path selection with MED when Local Preference or AS_PATH will always override it. Engineers may spend hours tuning MED only to realize the remote AS has set a higher Local Preference that makes MED irrelevant. Always verify which step is actually deciding the outcome using show ip bgp and show ip bgp detail to see all attributes.

Another frequent mistake is inconsistent MED handling. Forgetting that MED is only compared between paths from the same neighboring AS leads to confusion when a path with MED 10 loses to a path with MED 200 from a different AS. Enabling bgp always-compare-med without coordinating MED semantics with peers can cause unpredictable routing. Similarly, improper AS_PATH prepending, such as prepending too many times or prepending on all advertisements, can make a prefix unreachable via that path during normal conditions and hinder fast failover.

Best practices include documenting routing policy with BGP communities. Instead of directly setting Local Preference on each peer, tag routes with communities like 65000:100 for low preference and 65000:300 for high preference, then use a single route-map to translate communities to Local Preference. This makes policy auditable and consistent. Always use bgp deterministic-med to ensure deterministic results, and implement peer-specific prefix-lists and max-prefix limits to protect the RIB from route leaks and memory exhaustion.

For stability, enable BGP Graceful Restart and Bidirectional Forwarding Detection (BFD) for fast failure detection without waiting for the BGP hold timer. Use route dampening cautiously, as aggressive dampening can suppress valid paths after flapping. Finally, lab-test all route-maps and attribute manipulations before deploying to production, and maintain a looking glass or route analytics platform to verify that the intended best path is actually selected across the network.

Interview Questions

1. What is the exact order of the BGP best path selection algorithm, and which attribute wins first?

Answer: The order is Weight (Cisco, highest wins), Local Preference (highest), locally originated, AS_PATH length (shortest), Origin type (IGP < EGP < Incomplete), MED (lowest, only if same neighboring AS), eBGP over iBGP, IGP metric to next-hop (lowest), oldest path, lowest Router ID, lowest Cluster List length, and lowest neighbor IP. Weight is evaluated first and overrides everything else, but it is local to the router. In non-Cisco implementations, Local Preference is the first decisive attribute. Interviewers want to see that you know Local Preference beats AS_PATH and MED.

2. How would you make one ISP link preferred for outbound traffic and another link preferred for inbound traffic?

Answer: For outbound traffic (leaving your AS), set a higher Local Preference or Weight on routes learned via the preferred ISP. For example, set LOCAL_PREF 250 on ISP-A and 100 on ISP-B. For inbound traffic (entering your AS), you cannot directly control remote AS decisions, but you can influence them by AS_PATH prepending on the less preferred link (making it appear longer) and by setting a lower MED on the preferred link. Communities can also signal to the upstream provider to set Local Preference on their side. This tests understanding of attribute scope and direction of influence.

3. Why does BGP prefer eBGP over iBGP, and what is hot-potato routing?

Answer: BGP prefers eBGP over iBGP at step 7 because eBGP paths are learned directly from an external AS and are considered more reliable than paths learned indirectly via iBGP. Hot-potato routing occurs at step 8, where BGP chooses the path with the lowest IGP metric to the next-hop, effectively handing traffic off to the neighboring AS as quickly as possible. Cold-potato routing is the opposite, where an AS carries traffic longer on its own backbone before handing off, often achieved by using MED or communities to override the IGP metric decision.

4. What is the difference between MED and Local Preference, and when is each compared?

Answer: Local Preference is exchanged only within an AS via iBGP, controls outbound traffic, and is compared early (step 2) with higher values preferred. MED is exchanged between eBGP peers, controls inbound traffic, and is compared late (step 6) with lower values preferred, and only between paths from the same neighboring AS by default. Local Preference has AS-wide scope and overrides MED, while MED has limited scope to a peering relationship. This distinction is crucial for traffic engineering interviews.

5. How does BGP handle equal-cost paths, and what is BGP Multipath?

Answer: By default, BGP installs only one best path. If multiple paths are equal up to the IGP metric step, the oldest path or lowest Router ID breaks the tie. BGP Multipath allows the router to install multiple equal-cost best paths in the FIB for load sharing, typically up to 8 or 16 paths, when attributes up to a configurable step are equal. This enables ECMP without violating BGP loop prevention. BGP Add-Path extends this by allowing advertisement of multiple paths to peers, improving path diversity in route reflector topologies.