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

PDF

BGP-LU-based VPN services

Updated: June 9, 2026

Want to summarize with AI?

Explains the BGP-LU-based VPN transport model including supported services, forwarding recursion, supported platforms, restrictions, configuration workflow, and verification checks.

A BGP-LU-based VPN service is a packet forwarding service that:

enables Layer 3 VPN (L3VPN), Layer 2 VPN (L2VPN), and Ethernet VPN (EVPN) services to be transported over BGP-LU
supports the resolution of VPN transport labels through LDP, Segment Routing (SR), and RSVP-TE as underlying label transport mechanisms, and
preserves a three-level forwarding recursion chain, facilitating scalable end-to-end VPN services across multiple IGP or label domains in large service provider backbones.

Table 1. Feature History Table
Feature	Release Information	Feature Description
BGP-LU-based VPN services over LDP, SR, and RSVP-TE	Release 26.3.1	Introduced in this release on: Fixed Systems (8200 [ASIC: P100, P200], 8700 [ASIC: P100, P200,K100, K200], 8010 [ASIC: A100])(select variants only); Modular Systems (8800 [LC ASIC: P100])(select variants only) This feature enables scalable multi-domain Layer 3 and Layer 2 VPN services by stacking service, transport, and BGP labels. The feature supports three-level Multi-Protocol Label Switching (MPLS) label recursion in packet forwarding.

BGP-LU-based VPN services over LDP, SR, and RSVP-TE

This feature enables L3VPN (Layer 3 Virtual Private Network) and L2VPN (Layer 2 Virtual Private Network) services using BGP-LU (BGP Labeled Unicast) as the transport over LDP, Segment Routing, or RSVP-TE tunnels. The design supports three-level label stacks, optimizing multi-domain forwarding without forwarding chain collapse. You can use MPLS transport tunnels with high scale, seamless inter-domain connectivity, and fast reroute (FRR) support. Services include:

L3VPN over BGP-LU over LDP over RSVP-TE
L2VPN (ELINE and ELAN, single-homed and multi-homed) over BGP-LU over LDP or SR over RSVP-TE
EVPN ELINE and ELAN remote multihoming over the same transports

Three-level label recursion model

This feature preserves a three-level forwarding recursion chain without allowing forwarding-chain collapse:

Recursion level 0: L3VPN or L2VPN service label (from remote PE).
Recursion level 1: BGP-LU label (from BGP next hop, typically an Autonomous System Boundary Routers (ASBR) loopback).
Recursion level 2: Transport label (LDP or SR label, carried as RSVP-TE tunnel).

This model allows packets to traverse multiple ASBRs, with each ASBR swapping label information and forwarding accordingly.

In the data plane, the ingress PE pushes a service label, a BGP-LU label, and a transport label stack. The transport label carries the packet to the next transport endpoint. The next node then uses the BGP-LU label to continue forwarding toward the remote destination.

Supported topologies and use cases

Multi-domain service provider networks where connectivity must cross multiple IGP domains or ASBRs
Large-scale deployments requiring per-customer or per-service separation with high route and label scalability

Supported services and transports

Cisco IOS XR Release 26.3.1 supports these services and transports:


Service	Supported transports
L3VPN	BGP-LU over LDP over RSVP-TE BGP-LU over SR over RSVP-TE
L2VPN (ELINE/ELAN)	BGP-LU over LDP over RSVP-TE BGP-LU over SR over RSVP-TE
EVPN (ELINE/ELAN)	BGP-LU over LDP over RSVP-TE (single- and multi-homed) BGP-LU over SR over RSVP-TE (single- and multi-homed)

Benefits of the BGP-LU-based VPN packet forwarding

The BGP-LU-based VPN packet forwarding feature provides several operational and service benefits for deploying L3VPN, L2VPN, and EVPN services with MPLS. These benefits include:

Enables efficient, scalable, end-to-end delivery of VPN services across complex, multi-domain environments using flexible label switching and recursion.
Supports service parity between L2VPN and L3VPN, allowing consistent features across both service types.
Provides fast reroute (FRR) and protection options for improved network resiliency.
Simplifies migration from older forwarding models to three-level recursion, streamling operations and reducing complexity.

Usage guidelines for BGP-LU-based VPN packet forwarding

Follow these guidelines for BGP-LU-based VPN packet forwarding:

Deploy the feature only on supported ASICs: P100, P200, K100, K200, or A100.
Maintain transport feature parity between L3VPN and L2VPN for simplified operations.
For new deployments, prefer using three-level label recursion to optimize scale and support multi-domain connectivity.
Use single-homed or multi-homed EVPN services as needed for redundancy.
Plan migration from existing BGP-LU over LDP or RSVP-TE deployments using the three-level recursion model for improved interoperability and future growth.
Validate label allocation and end-to-end reachability after migration to avoid forwarding disruptions.
Always verify that service, BGP-LU, and transport labels are properly programmed on each PE and ASBR.

Restrictions for BGP-LU-based VPN packet forwarding

Follow these restrictions when implementing the BGP-LU-based VPN packet forwarding feature:

Do not use the BGP-LU-based VPN transport model on Q100 and Q200 ASICs.
Ensure that your platform and tunnel types are available and supported by your hardware and software release; some older platforms or tunnel types may not be supported.

How BGP-LU-based VPN packet forwarding works

Cross-domain L3VPN and L2VPN forwarding uses a three-label MPLS stack:

service label
BGP-LU label
transport label

The control plane allocates and advertises these labels through BGP for BGP-LU, LDP or SR for transport, and service-specific protocols for the service label.

PE and ASBR devices program BGP-LU routes in the same way. ASBR devices also reflect routes and allocate local BGP-LU labels for cross-domain forwarding.

Summary

BGP-LU-based VPN packet forwarding enables cross-domain transport of L3VPN and L2VPN traffic by using a three-label MPLS stack and role-based label operations at every hop.

The key components involved in this process are:

Ingress PE router: Receives the customer packet and pushes the service, BGP-LU, and transport labels.
Intermediate Provider routers: Forward the packet by using the outer transport label.
ASBR: Receives the packet after transport-label processing and swaps the BGP-LU label for the next transport path.
Destination PE router: Removes the service label and forwards the payload to the target VPN or interface.

Workflow

These stages describe how BGP-LU-based VPN packet forwarding works:

The ingress PE router receives an IP packet or Ethernet frame for delivery to a remote VPN destination. The PE router pushes these labels onto the packet:
- service label
- BGP-LU label
- transport label by using LDP or SR
Intermediate Provider routers forward the packet by using the outer transport label. The penultimate-hop router pops the transport label before the packet reaches the ASBR.
The ASBR receives the packet with the BGP-LU label and service label still present. The ASBR swaps the BGP-LU label for a new transport label that points to the downstream ASBR or the destination PE router.
Further intermediate routers forward the packet by using the updated transport label.
The destination PE router receives the packet with the service label, pops the service label, and forwards the data to the target VPN or interface.

Result

The network delivers L3VPN or L2VPN traffic across domains by using role-based label operations at each hop. The packet reaches the destination PE with the correct service context intact.

Configure BGP-LU-based VPN transport model

Deploy L3VPN, L2VPN, or EVPN services using BGP-LU-based transport across multiple IGP domains.

Use this task to set up BGP-LU-based VPN transport in environments with multiple IGP domains and various service types.

Follow these steps to configure BGP-LU-based VPN transport model:

Before you begin

Verify that BGP-LU-based VPN transport is not deployed on Q100 and Q200 systems.
Ensure your network includes PE nodes and aggregation or ASBR nodes.
Confirm that your underlay design incorporates LDP, SR, RSVP-TE, or the required combination of these transport protocols.
Validate that your service design includes L3VPN, L2VPN, or EVPN services.

Procedure

	1.	Configure the transport underlay in each IGP domain.
	2.	Configure RSVP-TE where the design requires TE transport.
	3.	Configure BGP-LU reachability between PE and ASBR nodes.
	4.	Configure the required VPN service on top of the BGP-LU transport: Choose one of the following services: L3VPN L2VPN ELINE L2VPN ELAN EVPN ELINE EVPN ELAN
	5.	Configure protection where the design requires resiliency, such as TE protection or BGP-LU PIC.
	6.	Validate the intended recursion chain. Ensure the following label stack order is applied: VPN service BGP-LU transport

The network forwards VPN traffic by using the intended layered transport model. The ingress PE pushes the service label, the BGP-LU label, and the transport label stack in the expected order.

Verify BGP-LU-based VPN transport operation

Ensure that Cisco IOS XR correctly programs the control plane, forwarding plane, and service plane correctly for BGP-LU-based VPN transport.

Perform these checks after configuring a BGP-LU-based VPN transport model to ensure the solution operates as expected and is resilient to failures.

Follow these steps to verify the BGP-LU-based VPN transport operation:

Before you begin

Ensure that the underlay is operational.
Confirm BGP-LU peering is established.
Verify that the VPN service is configured.
Make sure service traffic can reach the intended endpoints.

Procedure

	1.	Verify BGP-LU route learning and label advertisement.
	2.	Verify transport path establishment for the intended LDP, SR, or RSVP-TE path by checking path status and label assignments.
	3.	Verify label stack behavior at the ingress PE. Check for the presence of the service label, BGP-LU label, and transport label stack.
	4.	Verify end-to-end service traffic for the deployed service type. For these types, confirm end-to-end traffic traverses the expected path: L3VPN L2VPN ELINE L2VPN ELAN EVPN ELINE EVPN ELAN
	5.	Verify failover and recovery for identified failure cases, such as BGP events, underlay failures, RSVP-TE failures, and PE or CE link failures. Confirm expected traffic restoration and label learning after each simulated failure.

You confirm that Cisco IOS XR learns the required labels, preserves the intended recursion chain, and forwards service traffic over the expected BGP-LU-based transport path.

Need help?

Open a support case

(Requires a Cisco Service Contract)

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.