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

PDF

BGP nexthop resolutions over MPLS LSPs with RSVP-TE tunnels

Updated: February 28, 2026

Want to summarize with AI?

Log in

Overview

Describes BGP nexthop resolution procedures over MPLS LSPs using RSVP-TE tunnels, including benefits, operational workflows, policy usage guidelines, and step-by-step configuration of nexthop route policies in BGP.

A BGP nexthop resolution over MPLS LSPs with RSVP-TE tunnels is a BGP feature that

  • resolves BGP nexthops over RSVP-TE tunnels instead of native IP paths

  • enforces controlled and predictable traffic steering by forwarding prefixes exclusively through MPLS LSPs, and

  • prevents traffic drops caused by the lack of downstream BGP routing information in core networks.

Table 1. Feature History Table

Feature Name

Release Information

Feature Description

BGP nexthop resolution over MPLS LSPs with RSVP-TE tunnels

Release 25.1.1

Introduced in this release on: Fixed Systems (8200 [ASIC: Q200, P100], 8700 [ASIC: P100, K100], 8010 [ASIC: A100]); Centralized Systems (8600 [ASIC: Q200]); Modular Systems (8800 [LC ASIC: Q100, Q200, P100])

You can now prevent BGP prefixes from defaulting to native IP paths, which could lead to traffic drops due to the lack of BGP routing information on downstream core routers, by enforcing BGP nexthop resolution over MPLS LSPs with RSVP-TE tunnels. The feature gives you precise control over traffic steering by defining how BGP resolves nexthops and enabling route policies that consistently forward prefixes over RSVP-TE tunnels.

Previously, in core networks, downstream routers without BGP routes caused traffic to default to native IP paths instead of RSVP-TE LSPs, leading to potential drops.

The feature introduces these changes:

CLI:

The next-hop-type is introduced as a filter type in RPL.

YANG Data Models:

Cisco-IOS-XR-um-route-policy-cfg (see GitHub, YANG Data Models Navigator)

BGP nexthop resolution over MPLS LSPs with RSVP-TE tunnels enables network operators to control BGP nexthop selection using route policies, ensuring prefixes are always forwarded over RSVP-TE engineered paths. This approach avoids traffic drops that can occur when downstream routers lack BGP routing information and traffic otherwise defaults to native IP paths. By integrating filtering based on route-type and next-hop-type, the feature optimizes path selection, prevents congestion, and supports predictable traffic engineering.

Importance in multihomed BGP environments

This feature is critical in multihomed BGP environments, where destination prefixes are reachable via multiple Label Edge Routers (LERs). It ensures that ingress LERs choose nexthops resolving over RSVP-TE LSPs, and not native IP paths, helping keep traffic within engineered tunnels.

Effect on traffic when RSVP-TE tunnels Are unavailable

When no RSVP-TE tunnel is available, BGP marks routes as inaccessible and drops packets, enforcing strict resolution over RSVP-TE tunnels. If a tunnel fails, BGP reroutes traffic through another available RSVP-TE tunnel to maintain continuous traffic flow.

Controlled traffic steering with RSVP-TE tunnels

Suppose a service provider core network has multiple downstream routers, some of which lack complete BGP information. With this feature enabled, BGP will resolve traffic only over RSVP-TE tunnels, which avoids unexpected drops even when native IP paths are present.

Benefits of nexthop resolution with RSVP-TE tunnels

Nexthop resolution over MPLS Label Switched Paths (LSPs) with RSVP-TE tunnels provides several key advantages in scalable network environments:

  • Controls traffic steering by directing BGP prefixes over engineered traffic engineering (TE) paths, improving reliability and reducing packet drops.

  • Enables flexible integration with multiple transport types and protocols, supporting seamless network expansion and future upgrades.

  • Supports thousands of BGP nexthops and prefixes, maintaining high performance in large-scale deployments.

How BGP nexthop resolution over RSVP-TE tunnels works

Summary

The key components involved in the process are:

  • BGP process: A process that exchanges routing updates for destination prefixes and determines next-hop addresses.

  • Routing Information Base (RIB): A database that monitors next-hop resolution status and notifies BGP of changes, such as next-hop types or availability.

  • RSVP-TE tunnels: A tunnel that establishes label-switched paths for traffic forwarding.

BGP uses RSVP-TE tunnels for nexthop resolution by applying route policies and selecting engineered paths. If an RSVP-TE tunnel becomes unavailable, affected routes are marked inaccessible and traffic is dropped until the tunnel is restored.

Workflow

These stages describe the BGP nexthop resolution over RSVP-TE tunnels process.

  1. The BGP process receives routing updates for destination prefixes and attempts to resolve each prefix’s next-hop address.
  2. The RIB monitors the status of next-hop resolution and notifies BGP of any changes, including a change in next-hop type (such as resolution over an RSVP-TE tunnel).
  3. BGP evaluates available paths by applying configured route policies and selects those that can be resolved over RSVP-TE tunnels.
  4. The router forwards packets based on the best path as determined by BGP, steering traffic over the RSVP-TE tunnels specified.
  5. If the RSVP-TE tunnel for a route’s next-hop becomes unavailable, BGP marks the route as inaccessible and the router drops traffic for affected prefixes until resolution is restored.

Best practice for configuring BGP nexthop resolution over RSVP-TE tunnels

When configuring BGP nexthop resolution over RSVP-TE tunnels, follow these best practices:

  • Ensure that route policies with extended filters are applied to the VPNv4, VPNv6, IPv4, and IPv6 address families.

  • Apply the feature to all supported routes within the relevant address families to maintain consistent policy enforcement.

Configure BGP nexthop resolution with RSVP-TE route policy

Limit BGP nexthop resolution to RSVP-TE tunnels by applying a custom route policy.

Before you begin

Ensure RSVP-TE tunnels are established and operational within your network.

Procedure

1.

Define a route policy that permits only nexthops resolved using MPLS-TE.

Example:

Router(config)#route-policy ROUTE-RESOLUTION
Router(config-rpl)#if protocol is isis 100 and route-type is level-1 then
Router(config-rpl-if)#pass
Router(config-rpl-if)#elseif protocol is isis 100 and route-type is level-2 and next-hop-type is mpls-te then
Router(config-rpl-elseif)#pass
Router(config-rpl-elseif)#else 
Router(config-rpl-else)#drop
Router(config-rpl-else)#endif 
Router(config-rpl)#end-policy 
Router(config)#commit
2.

Apply the route policy to the BGP address-family configuration.

Example:

Router(config)# router bgp 100
Router(config-bgp)# address-family ipv4 unicast 
Router(config-bgp-af)# nexthop route-policy ROUTE-RESOLUTION
Router(config-bgp-af)# commit 
Router(config-bgp)# address-family ipv6 unicast
Router(config-bgp-af)# nexthop route-policy ROUTE-RESOLUTION
Router(config-bgp-af)# commit
3.

Use the show bgp ipv4 unicast nexthops command to verify if BGP resolves the nexthop over RSVP-TE tunnels.

Example:

Router# show bgp ipv4 unicast nexthops 209.165.200.225
Tue Mar 18 04:47:32.759 UTC
Nexthop: 129.134.99.7
  VRF: default
  Nexthop ID: 0x6000004, Version: 0
  Nexthop Flags: 0x00000000
  Nexthop Handle: 0x7f8d5fab66a8
  Tree Nexthop Handle: 0x7f8d5fab66a8

  RIB Related Information:
  Firsthop interface handle 0x7800004c
    Gateway TBL Id: 0xe0000000    Gateway Flags: 0x00000080
    Gateway Handle: 0x7f8d5d8b9d10
    Gateway: reachable, non-Connected route, prefix length 32
    Resolving Route: 129.134.99.7/32 (isis 1)
    Paths: 0
    RIB Nexthop Route Type: ISIS level-2
    RIB Nexthop Path Type: MPLS-TE
    RIB Nexthop ID: 0x0
    Nexthop sync slot: 15
    Status: [Reachable][Not Connected][Not Local]
    Metric: 30
    ORR afi bits: 0x0
    Inactive Tables: [IPv6 Unicast]
    Registration: Asynchronous, Completed: 00:27:39
    Events: Critical (3)/Non-critical (0)
    Last Received: 00:01:21 (Critical)
    Last gw update: (Crit-notif) 00:01:21(rib)
    Reference Count: 10

    Reachable Notifications:           1 (last at Mar 18 04:19:54.340)
    Unreachable Notifications:         0
    Metric Increase Notifications:     0
    Metric Decrease Notifications:     2
    Nexthop find:                      8
    Most Recent Events:
      Time                 EventType    Metric   Ifhandle     RouteType           PathType
      Mar 18 04:19:54.340  Reachable    30       0x7800004c   ISIS level-2        MPLS-TE
      Mar 18 04:44:47.974  Reachable    30       0x78000014   ISIS level-2        any
      Mar 18 04:46:12.411  Reachable    30       0x7800004c   ISIS level-2        MPLS-TE

  Prefix Related Information
    Active Tables: [IPv4 Unicast]
    Metrices: [0x1e]
    Reference Counts: [10]
    Encapsulations: []
  Interface Handle: 0x0
  Attr ref-count: 13

Review the output for PathType MPLS-TE, indicating successful resolution over RSVP-TE tunnels.
4.

Use the show bgp ipv4 unicast command to verify BGP routing information and nexthop reachability.

Example:

Router# show bgp ipv4 unicast 209.165.201.1/27
Thu Feb 13 12:14:35.626 UTC
BGP routing table entry for 209.165.201.1/27
Versions:
  Process           bRIB/RIB   SendTblVer
  Speaker           38992497     38992497
Last Modified: Feb 13 12:14:25.298 for 00:00:10
Paths: (1 available, no best path)
  Not advertised to any peer
  Path #1: Received by speaker 0
  Not advertised to any peer
  64800, (received & used)
    10.1.9.7 (inaccessible) from 10.3.9.7 (10.4.9.7)
      Origin IGP, localpref 100, valid, internal
      Received Path ID 0, Local Path ID 0, version 0
      Community: 65530:50700

If no RSVP-TE tunnel exists, the nexthop appears as inaccessible.
5.

Use the show rib ipv4 unicast next-hop command to confirm if the RIB is forwarding the route over MPLS-TE tunnels.

Example:

Router#show rib ipv4 unicast next-hop 209.165.201.1/27

Tue Mar 18 04:47:33.806 UTC

Firsthop prefix: 209.165.201.1/27
  Flags: allow default, recurse
  Ext flags: 0x1 (all_path_mpls_te)
  Damped counter: 0
  Damp algo hits: 3
  Last event occurred Mar 18 04:46:12.409, 00:01:21 ago; version 4

  Registered clients:
    te_control/node0_RP0_CPU0 created Mar 18 04:19:23.479, 00:28:10 ago
       read last notification at Mar 18 04:46:12.411, 00:01:21 ago
       reference count is 1

  Destination paths:
    209.165.201.1 - S-AR1-DR1-1-1
    209.165.201.1 - S-AR1-DR1-2-1
    209.165.201.1 - S-AR1-DR1-3-1
    209.165.201.1 - S-AR1-DR1-4-1
    209.165.201.1 - S-AR1-DR1-5-1
    209.165.201.1 - S-AR1-DR1-6-1
    209.165.201.1 - S-AR1-DR1-7-1
    209.165.201.1 - SF-AR1-DR1-1-1

  Resolving route: 209.165.201.1/27 known via "isis 1"
  Metric computed: 30

If Ext flags: 0x1 (all_path_mpls_te) is present, the route is using only MPLS-TE tunnels.