BGP Configuration Guide for Cisco 8000 Series Routers, Cisco IOS XR Releases

PDF

Advanced path selection features

Updated: February 28, 2026

Want to summarize with AI?

Log in

Overview

Introduces advanced features for BGP path selection, covering best paths and multipaths, additional paths, and selection using controller-programmed metrics, with benefits, operational details, and configuration steps.

BGP best paths and multipaths

A best path and multipath prefix is a BGP routing outcome that

  • identifies the optimal route (best path) for each destination prefix based on established selection rules

  • enables the installation of multiple qualified paths (multipaths) in the forwarding table to enhance load balancing and redundancy, and

  • determines which routes are advertised to BGP peers and how traffic is forwarded throughout the network.

BGP best path selection and advertisement

BGP routers receive multiple paths to the same destination prefix. By default, the BGP best path algorithm compares all valid paths and selects one as the best path to install in the local IP routing table and use for traffic forwarding. Only this best path is typically advertised to other BGP peers, which ensures consistent routing decisions across the network.

Multipath selection for load balancing and redundancy

However, to improve bandwidth utilization and provide redundancy, BGP implementations can select additional paths-called multipaths-if certain conditions are met. These multiple eligible paths are installed in the forwarding table, and incoming packets are load-balanced across the best path and the multipaths.

Community strings and the BGP add-path feature

Route reflectors in BGP can use community strings to signal local path decisions, differentiating between best paths and multipaths. The introduction of the BGP add-path feature allows a router to advertise more than the best path, signaling all equivalent or backup paths as per network policy and multipath rules.

Key considerations and limitations

  • By default, BGP only advertises the best path to its peers. This behavior may not show you the entire routing state available on a BGP speaker.

  • If Add-Path is not configured, installing multipath does not change what is advertised to peers.

A BGP router receives three paths to destination 10.1.1.0/24 from different peers. It selects one best path for routing and advertises only that path to other peers. If multipath is enabled and two paths qualify, both are used for forwarding traffic, providing load balancing and redundancy, though only the best path is advertised unless BGP add-path feature is configured.

Modify BGP best-path selection criteria

Change the default selection behavior of the BGP best-path algorithm to suit specific routing requirements.

BGP routers may learn multiple paths to a destination. By default, they use a specific algorithm to choose the best path. You can tune this behavior to influence routing and traffic flow between autonomous systems (ASes).

Before you begin

  • Ensure you have access to global configuration mode on your router.

  • Confirm that BGP is already enabled on the router.

Follow these steps to modify BGP best-path selection criteria:

Procedure

1.

Enter BGP configuration mode, and adjust MED comparison behavior.

  • Use the bgp bestpath med missing-as-worst command to treat missing MED as least desirable.
  • Use the bgp bestpath med always command to compare MED across all paths, regardless of AS.
  • Use the bgp bestpath med confed command to compare MED values for confederation peers.

Example:

Router(config)# router bgp 126
Router(config-bgp)# bgp bestpath med missing-as-worst
2.

Customize path attribute evaluation.

  • Use the bgp bestpath as-path ignore command to ignore AS path length for best-path selection.
  • Use the bgp bestpath compare-routerid command to compare router IDs among otherwise equal paths.

Example:

Router(config)# router bgp 126
Router(config-bgp)# bgp bestpath as-path ignore

The BGP best-path algorithm selects routes based on your modified criteria.

BGP additional paths

A BGP additional path is a BGP feature that

  • enables a BGP speaker to advertise multiple paths for the same network prefix

  • provides path diversity to improve convergence and operational flexibility, and

  • supports granular control of path selection and advertisement types per neighbor based on outbound policy configuration.

Table 1. Feature history table

Feature Name

Release Information

Feature Description

Additonal path control per neighbor

 Release 25.4.1

Introduced in this release on: Fixed Systems (8010 [ASIC: A100])(select variants only*)

*This feature is now supported on:

  • 8011-32Y8L2H2FH

  • 8011-12G12X4Y-A

  • 8011-12G12X4Y-D

Additonal path control per neighbor

 Release 25.1.1

Introduced in this release on: Fixed Systems (8010 [ASIC: A100])(select variants only*)

*This feature is supported on Cisco 8011-4G24Y4H-I routers.

Additonal path control per neighbor

 Release 24.4.1

Introduced in this release on: Fixed Systems (8200 [ASIC: P100], 8700 [ASIC: P100, K100])(select variants only); Modular Systems (8800 [LC ASIC: P100])(select variants only*)

*This feature is supported on:

  • 8212-48FH-M

  • 8711-32FH-M

  • 8712-MOD-M

  • 88-LC1-36EH

  • 88-LC1-12TH24FH-E

  • 88-LC1-52Y8H-EM

Additonal path control per neighbor

Release 7.3.15

This features allows flexibility and granular control of the advertisement of additional paths based on the neighbor outbound policy configuration.

This is done by allowing configuration of combinations diff erent path selection procedures unlike singular path selection, and extending neighbor outpound policy to have finer control of the path types to be advertised.

This feature enables operational efficiency to manage additional paths and reduce scale of the paths in a typical clustered network architecture.

Without this feature, the path scale limitation of the memory is impacted, and control plane convergence issues develop because of the excessive number of paths.

The BGP additional paths feature modifies BGP protocol behavior so a BGP speaker can send more than one path for a given prefix.

Benefits for path diversity and convergence

This modification provides network path diversity and enables edge routers to achieve prefix-independent convergence (PIC), especially in iBGP networks.

Enhanced policy control and scalability

By supporting multiple path types and expanded policy controls per neighbor, the feature helps prevent issues like path scale limitations and enables better control plane convergence.

BGP additional paths can advertise the following types of paths for a single prefix:

  • Backup paths - enable fast convergence and rapid restoration of connectivity.

  • Group-best paths - help resolve route oscillation scenarios.

  • All paths - emulate an iBGP full mesh by advertising every possible path.

BGP best path selection using controller-programmed metrics

BGP best path selection using controller-programmed metrics is a BGP path selection feature that

  • enables BGP to select optimal overlay routes using controller-provided path metrics

  • integrates controller agent metrics into the Routing Information Base (RIB) through the SL-APIv2 interface, and

  • ensures that BGP routing decisions for MPLS-forwarded IP routes accurately reflect the underlay path characteristics programmed by the network controller.

SL-APIv2 is version 2 of the Cisco Service Layer API, a programmatic interface that enables external controllers or applications to interact with IOS XR system services. The SL-APIv2 interface operates as part of the Service Layer Application Framework (SLAF) and supports use cases such as controller-injected route metrics, traffic engineering, and dynamic path optimization.

Table 2. Feature History Table

Feature Name

Release Information

Feature Description

BGP best path selection using controller-programmed metrics

 Release 26.1.1

Introduced in this release on: Modular Systems (8800 [LC ASIC: Q200])

Optimize overlay traffic steering using BGP best path selection with controller-programmed metrics, enabling traffic to follow preferred underlay paths. The network controller injects preferred path metrics into the Routing Information Base (RIB) through the Service Layer Application Programming Interface (SL API) version 2. BGP uses these metrics to calculate the best path for overlay routes. This feature supports seamless Segment Routing (SR) label transitions, simplifies migration from legacy protocols, and improves per-prefix traffic visibility.

The feature introduces these changes:

CLI: nexthop preference admin-distance

YANG Data Models:

  • Cisco-IOS-XR-ipv4-bgp-cfg.yang

  • Cisco-IOS-XR-um-router-bgp-cfg.yang

  • New Xpaths for nexthop-preference-admin-distance

(see GitHub, YANG Data Models Navigator)

Suboptimal overlay routing with IGP-based metrics

BGP best path selection in large-scale networks relies on metrics from IGP-installed routes. These metrics do not always represent controller-optimized underlay paths. As a result, BGP can steer overlay traffic along suboptimal paths, which reduces network efficiency and limits centralized traffic engineering benefits.

Controller-injected metrics in BGP path computation

With BGP best path selection using controller-programmed metrics, the network controller uses its agent and the SLAF to inject preferred path metrics into the RIB. BGP tracks next-hop changes through the RIB and uses the injected controller metrics during best path computation. This behavior aligns overlay routing decisions with accurate, controller-selected underlay paths.

Benefits of BGP best path selection using controller-programmed metrics

You gain several benefits by using controller-programmed metrics for BGP path selection:

  • Optimized routing and traffic steering

    When the network controller overrides an IGP-installed MPLS-forwarded IP route, you benefit from optimal traffic steering, improved performance, and greater resource efficiency because BGP uses the metric set by the controller for best path calculation.

  • Non-disruptive transitions and enhanced control

    You gain seamless forwarding and non-disruptive transitions of Segment Routing (SR) labels, even when the controller updates metrics. The controller influences BGP routing decisions to support granular traffic engineering and enables you to adapt dynamically to changing network conditions.

  • Simplified migration and reduced complexity

    Controller-based metric updates and steering provide a foundation for decommissioning legacy label distribution protocols. This approach streamlines your operations and simplifies management of multiple control-plane mechanisms.

  • Improved visibility

    Per-prefix egress accounting for controller-programmed prefixes helps you monitor network accuracy, simplifies troubleshooting, and improves visibility into your traffic flows.

How BGP best path selection using controller-programmed metrics works

Summary

The key components involved in the process are:

  • Network controller and agent: The network controller and agent program optimized MPLS-forwarded IP routes and associated metrics into the router using the SL API version 2 interface.

  • Routing Information Base (RIB): The RIB receives labeled and unlabeled routes, prioritizes them by prefix and label, and shares route information with BGP and the Forwarding Information Base (FIB).

  • BGP process: The BGP process registers with the RIB for next-hop tracking (NHT) and uses the most preferred metric during best path computation.

  • Forwarding Information Base (FIB): The FIB programs the forwarding plane based on the path selected by BGP.

The network controller injects optimized underlay metrics into the RIB. This approach enables BGP best-path selection using controller-programmed metrics.

Workflow

These stages describe the BGP best path selection using controller-programmed metrics:

  1. The controller agent injects MPLS-forwarded IP routes and corresponding path metrics into the RIB using the SL API version 2 interface.
  2. The RIB prioritizes routes by prefix and label and makes controller-supplied metrics available to other protocol consumers.
  3. BGP, configured to use administrative distance for next-hop preference, receives updated metrics for relevant prefixes through NHT.
  4. BGP filters candidate paths by administrative distance and selects optimal paths for ECMP, primary, or backup roles based on the controller-provided metric.
  5. The FIB programs the forwarding plane so that overlay traffic follows the controller-optimized underlay path.

Configure BGP best path selection using controller-programmed metrics

Configure BGP best path selection so that the controller can program metrics for optimal path selection.

This task involves enabling specific BGP and RIB settings so that controller-programmed metrics influence the BGP best path selection. The configuration ensures that best paths are chosen from a single protocol source.

Procedure

1.

Configure BGP to use administrative distance–based nexthop preference under the required address family and enable nexthop preference for best path selection.

Example:

Router# configure
Router(config)# router bgp 100
Router(config-bgp)# address-family ipv4 unicast
Router(config-bgp-af)# nexthop preference admin-distance
Router(config-bgp-af)# bgp bestpath nexthop-preference
Router(config-bgp-af)# commit
2.

Check that nexthop preference and admin distance are in use.

Confirm that the output includes statements such as:

  • Nexthop Preference admin distance is configured and in-use

  • BGP Bestpath nexthop preference is configured and in-use

Example:

Router#show bgp process detail 
..          

Address family: IPv4 Unicast
 AS based ECMP Download Delay not configured
 OOR Flag 0 OOR Threshold 0
 Prefix Download Delay 0
 Nexthop Preference admin distance is configured and in-use
 BGP Bestpath nexthop preference is configured and in-use
 Dampening is not enabled
 Client reflection is enabled in global config
 Dynamic MED is Disabled
3.

Verify the BGP route details for a given prefix.

In the output, check for the line: Nexthop Preference: <value>

Example:

Router#show bgp ipv4 unicast 192.0.2.0/24 detail 
BGP routing table entry for 192.0.2.0/24
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                 20           20
    Flags: 0x00041001+0x20000000+0x00000000
Last Modified: Apr  7 10:16:26.000 for 00:20:02
Paths: (1 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Flags: 0x2000000005060005+0x00, import: 0x31f
  Not advertised to any peer
  Local, (aggregated by 300 60.60.60.60)
    60.0.0.1 (metric 2) from 60.0.0.1 (60.60.60.60), if-handle 0x00000000
      Origin IGP, localpref 100, valid, internal, atomic-aggregate, best, group-best, import-candidate
      Received Path ID 0, Local Path ID 1, version 20
      Nexthop Preference: 110
4.

Compare BGP best path selection for the prefix.

Review the paths and confirm that nexthop preference values influence best path selection.

Example:

Router# show bgp ipv4 unicast 192.0.2.0/24 bestpath-compare
BGP routing table entry for 192.0.2.0/24, Route Distinguisher: 64499:100001087
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker                 27           27
    Local Label: 24002 (no rewrite); 
    Flags: 0x009630a2+0x00010000+0x00000000 backup available; 
Last Modified: Jun  8 11:19:52.000 for 00:08:38
Paths: (4 available, best #1)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Flags: 0x300000000d040003+0x00, import: 0x31f
  Not advertised to any peer
  502
    15.15.15.6 from 15.15.15.6 (15.15.15.6), if-handle 0x00000000
      Origin IGP, localpref 100, valid, external, best, group-best, import-candidate
      Received Path ID 3, Local Path ID 1, version 27
      Extended community: RT:60633:1100000143 RT:60633:1100000144 
      Nexthop Preference: 0
      Origin-AS validity: (disabled)
      best of AS 502, Overall best
  Path #2: Received by speaker 0
  Flags: 0x3000000000000003+0x00, import: 0x040
  Not advertised to any peer
  502
    20.0.0.7 from 15.15.15.6 (15.15.15.6), if-handle 0x00000000
      Origin IGP, localpref 100, valid, external
      Received Path ID 48, Local Path ID 0, version 0
      Extended community: RT:60633:1100000143 RT:60633:1100000144 
      Nexthop Preference: 1
      Origin-AS validity: (disabled)
      Path has a higher Nexthop Preference than best path (path #1)
  Path #3: Received by speaker 0
  Flags: 0x3000000000000003+0x00, import: 0x040
  Not advertised to any peer
  502
    20.0.0.8 from 15.15.15.6 (15.15.15.6), if-handle 0x00000000
      Origin IGP, localpref 100, valid, external
      Received Path ID 49, Local Path ID 0, version 0
      Extended community: RT:60633:1100000143 RT:60633:1100000144 
      Nexthop Preference: 1
      Origin-AS validity: (disabled)
      Path has a higher Nexthop Preference than best path (path #1)
  Path #4: Received by speaker 0
  Flags: 0x3000000008040003+0x00, import: 0x040
  Not advertised to any peer
  502
    20.0.0.9 from 15.15.15.6 (15.15.15.6), if-handle 0x00000000
      Origin IGP, localpref 100, valid, external, backup, add-path
      Received Path ID 50, Local Path ID 2, version 27
      Extended community: RT:60633:1100000143 RT:60633:1100000144 
      Nexthop Preference: 1
      Origin-AS validity: (disabled)
      Path has a higher Nexthop Preference than best path (path #1)
5.

Display the nexthop administrative distance and status.

Identify entries corresponding to the test prefix's nexthop. Confirm that the AdminDist field matches the expected value, for example, 110.

Example:

Router# show bgp nexthops wide
Total Nexthop Processing

  Time Spent: 0.000 secs

[snip]

Status codes: R/UR Reachable/Unreachable
              C/NC Connected/Not-connected
              L/NL Local/Non-local
              PR   Pending Registration
              I    Invalid (Policy drop)

Event Counter Codes:
              R    Reachable
              U    Unreachable
              MI   Metric Increased
              MD   Metric Decreased
Next Hop                                Status          Metric    AdminDist  Tbl-ID        Notf      LastRIBEvent    RefCount     R     U    MI    MD       F
0.0.0.0                                                                                               11/4
13.0.0.1                                [R][NC][NL]          0          1  e0000000         0/0    00:01:50 (Reg)     0/18        1     0     0     0       4
15.0.0.1                                [UR]        4294967295          0  e0000000         0/0    00:01:53 (Reg)     0/4         0     1     0     0       2
20.0.0.1                                [R][NC][NL]          3        110  e0000000         0/0    00:01:53 (Reg)     2/52        1     0     0     0       8
30.0.0.1                                [R][NC][NL]          3        110  e0000000         0/0    00:01:53 (Reg)     0/40        1     0     0     0      10
40.0.0.1                                [R][NC][NL]          2        110  e0000000         0/0    00:02:05 (Reg)     0/5         1     0     0     0       6
53.0.0.2                                [R][C][NL]           0          0  e0000000         0/0    00:02:05 (Reg)     1/3         1     0     0     0       1
60.0.0.1                                [R][NC][NL]          2        110  e0000000         1/0    00:02:01 (Cri)     2/30        1     0     0     0      11
6.

View detailed nexthop information.

Ensure that the status is [Reachable] and the admin distance aligns with the configuration.

Example:

Router# show bgp nexthops 198.51.100.1 detail
Nexthop: 198.51.100.1
  VRF: default
  Nexthop ID: 0x6000002, Version: 2
  Nexthop Flags: 0x00000180
  Nexthop Handle: 0x3602f90
  Tree Nexthop Handle: 0x3602f90

  RIB Related Information:
  Firsthop interface handle 0x00000020
    Gateway TBL Id: 0xe0000000    Gateway Flags: 0x00000080
    Gateway Handle: 0x39d46c0
    Gateway: reachable, non-Connected route, prefix length 32
    Resolving Route: 198.51.100.1/32 (ospf 0)
    Paths: 0
    RIB Nexthop Route Type: OSPF intra area
    RIB Nexthop Path Type: any
    RIB Nexthop ID: 0x0
    Nexthop sync slot: 1
    Status: [Reachable][Not Connected][Not Local]
    Metric: 2
    Admin Distance: 110 (Gateway), 110 (RIB)
    ORR afi bits: 0x0
    Registration: Asynchronous, Completed: 00:10:03
    Events: Critical (1)/Non-critical (0)
    Last Received: 00:09:23 (Critical)
    Last gw update: (Crit-notif) 00:09:23(rib)
    Reference Count: 2

    Reachable Notifications:           1 (last at Apr  3 17:47:17.989)
    Unreachable Notifications:         1 (last at Apr  3 17:46:37.538)
    Metric Increase Notifications:     0
    Metric Decrease Notifications:     0
    Nexthop find:                     25
    Most Recent Events:
    Time                 EventType    Metric   RIBAdminDist    Ifhandle     RouteType           PathType
      Apr  3 17:46:37.538  Unreachable  -
      Apr  3 17:47:17.989  Reachable    2        110             0x20         OSPF intra area     any

  Prefix Related Information
    Active Tables: [IPv4 Unicast][VPNv4 Unicast][IPv6 Unicast][VPNv6 Unicast]
    Metrices: [0x2][0x2][0x2][0x2]
    Nexthop Preferences: [110][4294967295][4294967295][4294967295]
    Reference Counts: [2][13][1][11]
    Encapsulations: [][][][]
  Interface Handle: 0x0
  Attr ref-count: 30
Next Hop          Addrlen2                 Color/Attr        Ifhandle   RefCount
198.51.100.1           32                             -      0x00000000        2/30

What to do next

(Optional) Validate additional metrics.

Table 3. Commands to validate additional metrics

To verify...

run the...

route installation in RIB

show route <ip-prefix> command.

forwarding details

show cef <ip-prefix> detail command.

the MPLS forwarding path

show mpls forwarding command.

SWAN-imposed routes

show service-layer route command.

the health of the service-layer agent

show grpc service-layer summary command.

agent logs

show appmgr application name swanagent logs command.

the administrative distance for a nexthop

show rib nexthop <ip-address> command.