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

PDF

PBTS-based BGP-LU over RSVP-TE

Updated: June 9, 2026

Want to summarize with AI?

Log in

Explains how policy-based tunnel selection enables class-based forwarding for BGP-LU services over RSVP-TE tunnels, allowing differentiated traffic treatment and seamless integration into MPLS networks.

The policy-based tunnel selection (PBTS) for BGP-LU over RSVP-TE is a feature that is a mechasupport for BGP-LU over LDP over RSVP-TE enables the Cisco 8608 to integrate into an existing MPLS core that uses OSPF/LDP, RSVP-TE, and BGP-LU. The feature allows the router to select between multiple RSVP-TE tunnels to the same destination based on QoS marking, using the MPLS EXP value as the forwarding key. In the target design, EXP 0 traffic is forwarded over a Default tunnel, while EXP 1 through 7 traffic is forwarded over a Priority tunnel.

  • enables routers to choose between multiple RSVP-TE to the same destination based on MPLS EXP (QoS) marking

  • integrates with MPLS core environments using OSPF or LDP, RSVP-TE, and BGP-LU, and

  • supports differenentiated traffic handling by mapping EXP 0 to default tunnels and EXP 1–7 to priority tunnels.

In this feature, RSVP-TE tunnels act as the transport underlay while BGP-LU is part of the labeled service reachability model. PBTS provides class-based forwarding across parallel RSVP-TE tunnels to the same destination.

Table 1. Feature History Table

Feature Name

Release

Description

PBTS-based BGP-LU over RSVP-TE

Release 26.3.1

This feature adds class-aware tunnel selection so that BGP-LU traffic is forwarded only over RSVP-TE tunnel paths whose forward class matches the packet QoS marking.

With this feature, the router can carry BGP-LU services across RSVP-TE transport and use PBTS to send EXP 0 traffic over default TE tunnels and EXP 1–7 traffic over priority TE tunnels, matching MPLS network design.

PBTS-based BGP-LU over RSVP-TE

Prior to Cisco IOS XR Release 26.3.1, traffic load balancing occurred across all TE tunnel paths, regardless of the forward-class ID of the tunnel. With PBTS-based BGP-LU over RSVP-TE, traffic is now load balanced across TE tunnel paths that match the packet's DSCP or EXP value. For each destination, the design expects at least two primary TE tunnels:

  • Default tunnel: Carries EXP 0 traffic, handles bulk traffic, supports FRR (fast reroute), and may take longer network paths to find available bandwidth.

  • Priority tunnel: Carries EXP 1–7 traffic, supports FRR, uses auto-bandwidth features, and typically has a highter setup or hold priority than default tunnels.

PBTS examines the MPLS EXP value and selects the appropriate TE tunnel for forwarding. This allows the network to maintain differentiated treatment for default and higher-priority traffic classes while leveraging RSVP-TE traffic engineering.

PBTS applies when two MPLS-TE tunnels to the same destination are active. If only one tunnel is up, all traffic is sent over that tunnel. If the default tunnel is preempted and all traffic temporarily shifts to the priority tunnel, this may trigger auto-bandwidth adjustments on the priority tunnel.

Tunnel priorities

Setting tunnel priorities helps manage preemption during tunnel setup. Lower numbers indicate higher priority. Tunnel priorities enhance network stability and prevent constant preemption when multiple tunnels compete for the same resources.

Tunnel type

Setup priority

Hold priority

Default tunnel

5

5

Priority tunnel

3

3

Benefits of PBTS-based BGP-LU over RSVP-TE

  • Preserves class-based traffic steering using MPLS EXP values.

  • Provides differentiated forwarding for default and priority traffic.

  • Allows high-priority traffic to use engineered, protected TE paths.

  • Improves resiliency through integration with FRR, soft preemption, and MH-BFD (Multihop BFD).

  • Supports scalable tunnel-based traffic engineering in a full-mesh TE deployment.

Restrictions for PBTS-based BGP-LU over RSVP-TE

Follow these restrictions for PBTS-based BGP-LU over RSVP-TE:

  • PBTS is applicable only when two RSVP-TE tunnels to the same destination are active and established.

  • If one tunnel goes down, traffic is forwarded over the remaining active tunnel, which may temporarily alter the intended class-based distribution.

  • Auto-bandwidth is not supported with auto-mesh.

  • TE tunnels in this design are restricted to remain within their OSPF domain or process and do not cross inter-area, inter-AS, or multi-process boundaries.

  • MH-BFD over TE is supported only for point-to-point TE tunnels.

  • Backup tunnels are dimensioned primarily for priority tunnel protection and are not intended to reserve bandwidth for all default tunnel traffic.

Usage guidelines for PBTS-based BGP-LU over RSVP-TE

Follow these best practices when configuring PBTS-based BGP-LU over RSVP-TE tunnels:

  • Configure at least on default tunnel and one priority tunnel per destination when PBTS-based class selection is required.

  • Use MPLS EXP marking consistently to ensure PBTS applies the intended forwarding policy, where EXP 0 is reserved for the default tunnel and EXP 1–7 are used for the priority tunnel.

  • Enable targeted LDP over the TE transport to allow remote label bindings to be learned throughout the full-mesh TE design.

  • Restore preempted or failed tunnels quickly to minimize the period during which all traffic is forced onto a single surviving tunnel.

Configure PBTS-based BGP-LU over RSVP-TE

Enable PBTS-based forwarding by configuring BGP-LU over RSVP-TE hardware profiles, forward-class lists, QoS classification, tunnel paring, and fallback.

Use this task to set up PBTS forwarding for BGP-LU over RSVP-TE. This configuration is typically required in networks where traffic prioritization, failover, and tunnel-specific forwarding are needed for optimal performance.

Follow these steps to configure PBTS-based BGP-LU over RSVP-TE:

Before you begin

  • For each destination that requires PBTS-based forwarding, two RSVP-TE tunnels (default tunnel and priority tunnel).

  • Ensure QoS classification is available to map traffic into forwarding classes—FC0 for default traffic and FC1 for priority traffic.

Procedure

1.

Enable the BGP-LU over RSVP-TE hardware profile and configure the PBTS forward-class list.

Example:

Router# hw-module profile cef bgplu-over-rsvpte enable
Router# reload
2.

Configure PBTS forward-class profile. Include all forwarding classes required by the deployment.

Example:

Router# hw-module profile cef cbf forward-class-list 0 1
3.

Configure QoS ingress classification so that traffic is assigned to the appropriate forwarding class.

Example:

class-map match-any PRIORITY-TRAFFIC
 match dscp ef
 match dscp af41
 match mpls experimental topmost 5
!

policy-map PBTS-CLASSIFY
 class PRIORITY-TRAFFIC
  set forward-class 1
 class class-default
  set forward-class 0
!
4.

Configure paired RSVP-TE tunnels to the same destination. One tunnel is used for default traffic and the other tunnel is used for priority traffic.

Example:

interface tunnel-te 100
 forward-class 1
!

interface tunnel-te 200
 forward-class 0
!
5.

Configure fallback behavior so traffic can continue to forward over the surviving tunnel if one tunnel becomes unavailable.

Example:

Router# cef pbts class 1 fallback-to 0
Router# cef pbts class 0 fallback-to 1
!

Add the release-specific targeted LDP or tunneled LDP configuration for the TE tunnel interfaces as required.
6.

Apply the QoS policy to the ingress interface so traffic is classified before recursive forwarding over the BGP-LU next hop.

Example:

interface TenGigE0/0/0/0
 service-policy input PBTS-CLASSIFY
!
7.

Verify BGP-LU router resolution.

Example:

Router# show bgp ipv4 labeled-unicast 10.2.0.0/16

Check that the labeled-unicast route is installed, resolves through the expected next hop, associates with RSVP-TE transport, and both default and priority TE tunnel paths are available.
8.

Verify PBTS-aware CEF programming.

Example:

Router# show cef 10.2.0.0/16 detail

Ensure the route is programmed as PBTS-aware, the PBTS group is present, FC0 maps to the default tunnel, and FC1 maps to the priority tunnel.
9.

Verify RSVP-TE tunnel state and targeted LDP sessions.

Example:

Router# show mpls traffic-eng tunnels tabular
Router# show mpls ldp neighbor

Both tunnels should be up, with correct forward-class assignment and FRR protection. Both tunnels must to the same destination.

Confirm targeted LDP sessions are established to the expected remote ABRs and targeted LDP adjacencies are operational over the TE transport.
PBTS-based forwarding for BGP-LU over RSVP-TE is successfully enabled; traffic is classified and forwarded according to the configured policies, with fallback protection and verifiable tunnel and route status.

What to do next

Review operational status regularly, update QoS and tunnel configurations as needed based on network changes.