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

Per-VRF label allocation for VPN routes

Updated: February 28, 2026

Want to summarize with AI?

On this page

Overview

Limitations of Per-VRF label allocation for VPN routes
Configure Per-VRF label allocation for VPN routes
Configure Per-VRF label allocation for VPN routes in same RD scenarios
Configure per-VRF label allocation for VPN routes with different RDs

Overview

Explains per-VRF label allocation for VPN routes, covering associated limitations, configuration approaches for same or different RD scenarios, and step-by-step procedures supporting route scale and MPLS VPN deployment flexibility.

A per-VRF label allocation for VPN routes is a label assignment method that

assigns a single label per VPN routing and forwarding (VRF) instance rather than per individual route prefix
conserves label resources, which is especially important on low-end platforms with limited label capacity, and
enables more efficient advertisement and management of imported VPN routes across different route distinguishers (RDs).

Table 1. Feature history table
Feature Name	Release Information	Feature Description
Per-VRF label allocation for VPN routes	Release 25.1.1	Introduced in this release on: Fixed Systems (8700 [ASIC: K100]). This feature is now supported on Cisco 8712-MOD-M routers.
Per-VRF label allocation for VPN routes	Release 24.4.1	Introduced in this release on: Fixed Systems (8200 [ASIC:Q200, P100], 8700 [ASIC: P100, K100] ); Centralized Systems (8600 [ASIC:Q200]); Modular Systems (8800 [LC ASIC: Q100, Q200, P100]) This feature modifies the default label allocation from per-prefix to per-VRF by allowing you to enforce per-VRF label allocation for imported VPN routes using the advertise vpn-imported label-mode per-vrf command. This feature introduces these changes: CLI: advertise vpn-imported label-mode per-vrf YANG Data Model: `Cisco-IOS-XR-um-vrf-cfg.yang` (see GitHub, YANG Data Models Navigator)

Default label allocation behavior

When a Route Reflector (RR) that is also a Provider Edge (PE) router is configured with the same route distinguisher (RD) and the next-hop-self option, the system uses per-prefix mode for local label allocation by default. This default applies even if Prefix Independent Convergence (PIC) is enabled. In this scenario, remote VPN routes with the same RD and matching route targets also receive per-prefix labels.

Label exhaustion in low-end platforms

On devices with limited label capacity, using per-prefix label allocation for imported VPN routes can exhaust available labels. Switching to per-VRF label allocation conserves label space and prevents label exhaustion on these platforms.

Modified label allocation behavior

This feature enables per-VRF label allocation for imported VPN routes with the same RD. By using the advertise vpn-imported label-mode per-vrf command, you can override the default per-prefix allocation in favor of per-VRF label assignment:

Support for differing RDs

For routes with different RDs, the default behavior assigns per-prefix labels to routes with remote RDs, and these routes are advertised. Imported VPN routes are not advertised by default. When per-VRF label allocation is enabled:

Routes with remote RDs do not receive labels and are not advertised.
Imported VPN routes are assigned a single per-VRF label and are advertised.

Per-VRF label allocation example

If you enable per-VRF label allocation on a low-end platform that previously exhausted label space under per-prefix allocation, imported VPN routes will now share a single label per VRF, resolving label exhaustion and optimizing label usage.

Limitations of Per-VRF label allocation for VPN routes

Ensure you understand and adhere to the following limitations when applying per-VRF label allocation for VPN routes:

Apply per-VRF label allocation only to VPNv4 and VPNv6 routes.
Use per-VRF label allocation only with VRF-imported prefixes.
Configure per-VRF label allocation only when the next-hop is changed. If the next-hop is not changed, the label mode defaults to per-prefix even if the per-VRF configuration is present.
Do not use per-VRF label allocation with EVPN.
Use the is-imported-path keyword for import match only at the neighbor outbound route-policy attach-point.

Configure Per-VRF label allocation for VPN routes

You can configure the Per-VRF label allocation for VPN routes feature in two scenarios:

Scenario 1: RR and PE routers are configured with the same RD
Scenario 2: RR and PE routers are configured with different RDs

Configure Per-VRF label allocation for VPN routes in same RD scenarios

Enable per-VRF label allocation for VPN routes when Route Reflectors (RR) and Provider Edge (PE) routers are configured with the same Route Distinguisher (RD).

This is a sample topology where the RR and PEs are configured with the same RD.

Figure 1. Sample topology for same RD configuration

Follow these steps to configure per-VRF label allocation for VPN routes in the same RD scenario:

Procedure

Enable per-VRF label allocation on the RR-PE (for example, RR-PE2).

Example:

Router# configure
Router(config)# vrf vrf_1
Router(config-vrf)# address-family ipv4 unicast 
Router(config-vrf-af)# advertise vpn-imported label-mode per-vrf

Configure the BGP neighbor with the next-hop-self attribute.

Example:

Router(config)# router bgp 100 
Router(config-bgp)# neighbor 10.3.3.3
Router(config-bgp-nbr)# remote-as 100 
Router(config-bgp-nbr)# update-source Loopback0
Router(config-bgp-nbr)# address-family ipv4 unicast
Router(config-bgp-nbr-af)# next-hop-self
Router(config-bgp-nbr-af)# exit
Router(config-bgp-nbr)# address-family ipv6 unicast 
Router(config-bgp-nbr-af)# next-hop-self
Router(config-bgp-nbr-af)# exit

Note

You can configure next-hop-self directly, as shown above, or set it within a neighbor outbound route-policy.

Use these commands to verify that the per-VRF label allocation is enabled.

Example:

Router# show bgp label table

Router# show bgp vpnv4 unicast rd

Router# show mpls label table

Router# show controllers npu resources

Configure per-VRF label allocation for VPN routes with different RDs

Enable per-VRF label allocation for VPN routes in scenarios where the route reflector (RR) and provider edge (PE) routers use different route distinguishers (RDs).

This is a sample topology where the RR and PEs are configured with different RDs.

Figure 2. Sample topology for different RD configuration

Before you begin

Ensure you have access to the relevant routers and their configuration interfaces.
Confirm BGP sessions are established between RRs and PEs.

Procedure

	1.	Enable per-VRF label allocation on the RR-PE (for example, RR-PE2). Example: `Router# configure Router(config)# vrf vrf_1 Router(config-vrf)# address-family ipv4 unicast Router(config-vrf-af)# advertise vpn-imported label-mode per-vrf`
	2.	Configure the BGP neighbor with the next-hop-self attribute for IPv4 and IPv6 address families. Example: `Router(config)# router bgp 100 Router(config-bgp)# neighbor 10.3.3.3 Router(config-bgp-nbr)# remote-as 100 Router(config-bgp-nbr)# update-source Loopback0 Router(config-bgp-nbr)# address-family ipv4 unicast Router(config-bgp-nbr-af)# next-hop-self Router(config-bgp-nbr-af)# exit Router(config-bgp-nbr)# address-family ipv6 unicast Router(config-bgp-nbr-af)# next-hop-self Router(config-bgp-nbr-af)# exit`
	3.	Create and apply route policies to allow only imported VPN paths and local paths, blocking remote VPN paths. Example: `Router(config)# route-policy rp-advertise-imported Router(config-rpl)# if destination is-imported-path or source in (0.0.0.0) then Router(config-rpl-if)# pass Router(config-rpl-if)# else Router(config-rpl-else)# drop Router(config-rpl-else)# endif Router(config-rpl)# end-policy` `Router(config)# router bgp 100 Router(config-bgp)# neighbor 10.3.3.3 Router(config-bgp-nbr)# address-family vpnv4 unicast Router(config-bgp-nbr-af)# route-policy rp-advertise-imported out Router(config-bgp-nbr-af)# exit Router(config-bgp-nbr)# address-family vpnv6 unicast Router(config-bgp-nbr-af)# route-policy rp-advertise-imported out Router(config-bgp-nbr-af)# exit`
	4.	Attach the no-advertise community in the neighbor inbound policy to prevent the advertisement of remote RD paths. Example: `Router(config)# community-set com-set-no-advertise Router(config-comm)# no-advertise Router(config-comm)# end-set` `Router(config)# route-policy rpl-set-no-advertise Router(config-rpl)# set community com-set-no-advertise Router(config-rpl)# end-policy` `Router(config)# router bgp 100 Router(config-bgp)# neighbor 10.1.1.1 Router(config-bgp-nbr)# address-family vpnv4 unicast Router(config-bgp-nbr-af)# route-policy rpl-set-no-advertise in Router(config-bgp-nbr-af)# exit`
	5.	Remove the no-advertise community from the imported paths to enable advertisement of imported VPN paths. Example: `Router(config)# route-policy no-set-community Router(config-rpl)# delete community in com-set-no-advertise Router(config-rpl)# end-policy` `Router# configure Router(config)# vrf vrf_1 Router(config-vrf)# address-family ipv4 unicast Router(config-vrf-af)# import route-policy no-set-community`
	6.	Use these commands to verify that the per-VRF label allocation is enabled. Example: `Router# show bgp label table` `Router# show bgp vpnv4 unicast rd` `Router# show mpls label table` `Router# show controllers npu resources`

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.