MPLS Label Allocation Mode (Cisco and Juniper)

References:
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_l3_vpns/configuration/15-mt/mp-l3-vpns-15-mt-book/mp-vpn-vrf-label.html
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_l3_vpns/configuration/15-mt/mp-l3-vpns-15-mt-book/mp-vpn-ce-label.html
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_l3_vpns/configuration/xe-16/mp-l3-vpns-xe-16-book/mpls-vpn-per-vrf-label.html#GUID-21A61C5D-5A8F-40C0-AE78-14C4E1290247
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_l3_vpns/configuration/xe-16/mp-l3-vpns-xe-16-book/mpls-vpn-per-customer-edge-ce-label.html
http://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r4-1/interfaces/configuration/guide/hc41asr9kbook/hc41irb.html
https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r5-3/routing/command/reference/b-routing-cr53xasr9k/b-routing-cr53xasr9k_chapter_01.html#wp3514062886
MPLS in the SDA Era - p135 & p156

Per-Prefix Label
This is the default mode in IOS, IOS-XE and IOS-XR. When using per prefix label allocation mode every prefix received from a CE within a VRF (over eBGP for example) is allocated a local MPLS label on the PE, even though they all have the same next-hop (the CE IP address) and all reside within the same VRF. All prefixes locally originated by the PE into the VRF (when using for example "redistribute connected", "redistribute static", BGP aggregate routes etc) are all allocated to the same local aggregate label. For these prefixes when an MPLS transported IP packet arrives, there needs to be a local IP lookup to determine the L2 next-hop write information.

 

Per-CE/NH Label
This is the default mode for Junos. When using per CE label allocation mode (sometimes called per-NextHop) a PE allocates one label per next hop. In the case a CE sends 1000 routes they all fall under one label on the PE that points to a layer 2 re-write towards the CE IP. This mode uses less labels than per-prefix mode but without added excessive overheads to the PE, each incoming MPLS transported IP packet is still matched to a layer 2 next-hop rewrite entry. On Junos any loopbacks within the VRF (routing instance) will also receive a unique label.

 

Per-VRF/Table Label
When using per VRF label allocation mode, one label is allocated on the PE for all routes in the VRF (locally originated through "redistribute connected" or "redistribute static" or learnt from CPE using eBGP for example). This mode is the most resource efficient however every incoming labelled packet requires the next-hop IP lookup to be performed and then the layer 2 re-write information.

Some IOS and IOS-XE devices support a mode called "vrf-conn-aggr" which is mix of per-prefix and per-VRF. In this mode the local PE assigns an aggregate label for all locally connected prefixes and aggregate routes originated from itself. Other prefixes learnt via eBGP from a CE for example, all within the same VRF (Option A) will still receive per-prefix labels despite sharing the same next-hop.

Despite per-prefix labelling being the default mode on IOS-XR, for locally connected routes or locally originated aggregate routes within a VRF, IOS-XR will allocate an aggregate table label for these routes.

When enabling per VRF table labels on Junos, the device creates a Label-Switched Interface (LSI) for each VRF label/VRF. This logical interface maps the incoming aggregate labelled packet to a local routing instance (VRF), the label is popped and a layer 2 forwarding lookup performed and then the layer 2 rewrite is made.

 

IOS Per-VRF Label Limitations
From the Cisco docs, limitations on IOS devices when using per-VRF labelling:

- Enabling the MPLS VPN Per VRF Label feature causes Border Gateway Protocol (BGP) reconvergence, which can result in data loss for traffic coming from the Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) core.
- There is no performance degradation when you configure up to 511 VRFs; however, when you add more than 511 VRFs, your network might experience some minor performance degradation (similar to the normal degradation experienced by any of the directly connected VRF prefixes present in the device).
- Per-prefix MPLS counters for VPN prefixes are lost when you enable the MPLS VPN Per VRF Label feature.
- You cannot use this feature with Carrier Supporting Carrier (CSC) and external/internal Border Gateway Protocol (EIBGP) multipath features.
- When you enable the MPLS VPN Per VRF Label feature, any existing Per VRF Aggregate label is used. If no Per VRF Aggregate label is present, the software creates a new Per VRF label.
- When you enable the MPLS VPN Per VRF Label feature, the CE device's learned local routes will experience some data loss.
- The CE does not lose data when you disable the MPLS VPN Per VRF Label feature because when you disable the feature, the configuration reverts to the default labeling configuration, which uses the Per VRF Aggregate label from the local nonCE-sourced routes.
- When you disable the MPLS VPN Per VRF Label feature, the configuration reverts to the default configuration.
- A Per VRF label forwarding entry is deleted only if the VRF or the Border Gateway Protocol (BGP) configuration is removed.

BGP PIC is not supported with per-vrf labelling. Despite not being clearly listed as unsupported this was confirmed by TAC specifically for the 7600s, ME3600s/ME3800s, ASR920s, but generally it isn't supported on any IOS/IOS-XE devices (probably not IOS-XR either).

 

IOS Per-CE/NH Label Limitation
From the Cisco docs, limitations on IOS devices when using per-CE labelling:

- Enabling the MPLS VPN per CE Label feature causes Border Gateway Protocol (BGP) reconvergence, which can result in data loss for traffic coming from the Multiprotocol Label Switching (MPLS) VPN core.
- IPv6 Provider Edge devices (6PE) are not supported.
Prefix-Independent Convergence (PIC) is not supported. Per CE Label with only multipath is supported. You cannot use this feature with:
- - Internal Border Gateway Protocol (IBGP) multipath feature
- - Carrier Supporting Carrier (CSC) feature
- When per CE label is configured, MPLS Forwarding Infrastructure (MFI) has to back up key and label information to a standby device. This will impact software downgrades.
- The BGP Best External feature provides the network with a backup external route to avoid loss of connectivity of the primary external route. This feature is not supported.
- Importing routes from protocols other than BGP on a PE device is not supported.
- Any network with a zero next hop is assigned one label per network, because the next hop cannot be reliably determined.
- Do not use per CE labels if there are multiple neighbors with the same address in a VRF domain.
- Only single hop EBGP is supported. Multihop EBGP is not supported.
- In high availability configurations, labels will be preserved after switchover from standby only if BGP Graceful Restart is configured before establishing BGP sessions.

 

IOS-XE Per-CE Label Limitations
From the Cisco docs, limitations on IOS-XE devices when using per-CE labelling:

- IPv6 Provider Edge devices (6PE) are not supported.
- Prefix-Independent Convergence (PIC) is not supported.
- Carrier Supporting Carrier (CSC) is not supported.
- When per CE label is configured, MPLS Forwarding Infrastructure (MFI) has to back up key and label information to a standby device. This will impact software downgrades.
- The BGP Best External feature provides the network with a backup external route to avoid loss of connectivity of the primary external route. This feature is not supported.
- Importing routes from protocols other than BGP on a PE device is not supported.
- Any network with a zero next hop is assigned one label per network, because the next hop cannot be reliably determined.
- Do not use per CE labels if there are multiple neighbors with the same address in a VRF domain.
- Only single hop EBGP is supported. Multihop EBGP is not supported.

IOS-XE Per-VRF Limitations
From the Cisco docs, limitations on IOS-XE devices when using per-VRF labelling:

- Enabling the MPLS VPN Per VRF Label feature causes Border Gateway Protocol (BGP) reconvergence
- There is no performance degradation when you configure up to 511 VRFs; however, when you add more than 511 VRFs, your network might experience some minor performance degradation (similar to the normal degradation experienced by any of the directly connected VRF prefixes present in the device).
- Per-prefix MPLS counters for VPN prefixes are lost when you enable the MPLS VPN Per VRF Label feature.
- You cannot use this feature with Carrier Supporting Carrier (CSC) and external/internal Border Gateway Protocol (EIBGP) multipath features.

IOS-XR Per-VRF Limitations
From the Cisco docs, limitations on IOS-XR for using per-VRF labelling and BVIs:

- BVI use is only supported with per-VRF label
- BVI in VRF with IPv4 address supports per-VRF labelling only
- BVI in VRF with IPv6 address supports per-VRF labelling only (IPv6 BVI with VRF is also only supported on certain line cards)

These features are not supported on the BVI interfaces on the ASR 9000:
Access Control Lists (ACLs). However, L2 ACLs can be configured on each L2 port of the bridge-domain.
IP Fast Reroute (FRR)
NetFlow
MoFRR (Multicast only Fast Re-Route)
MPLS label switching
mVPNv4
Quality of Service (QoS)
Traffic mirroring
Unnumbered interface for BVI
Video monitoring (Vidmon)
The BVI can be in a Virtual Routing and Forwarding (VRF) configuration, so that traffic received on the BVI is forwarded over MPLS, but per-vrf label-allocation-mode must be used.

 

IOS-XR and Junos Label Allocations

IOS-XR allocates a seperate label for an IPv4 prefix and an IPv6 prefix in each address family. This is different in Junos for which per VRF label allocation mode associates the same label for both IPv4 and IPv6 prefixes.

 

! The IOS-XR output below shows when using per-prefix labelling there is an aggregate label which represends all the local interfaces in this VRF facing each CPE. Then there are individual labels for prefixes learnt over eBGP from the CPEs

RP/0/RSP0/CPU0:abr1#show route vrf CUST-VRF connected

C    100.97.136.4/31 is directly connected, 44w1d, TenGigE0/0/1/0.2102
C    100.97.136.6/31 is directly connected, 44w1d, TenGigE0/0/1/0.2103
C    100.97.136.8/31 is directly connected, 44w1d, TenGigE0/0/1/0.2104
C    100.97.136.10/31 is directly connected, 44w1d, TenGigE0/0/1/0.2105
C    100.97.136.12/31 is directly connected, 38w5d, TenGigE0/0/1/0.2106
C    100.97.136.14/31 is directly connected, 44w1d, TenGigE0/0/1/0.2107
C    100.97.136.16/31 is directly connected, 41w6d, TenGigE0/0/1/0.2108
C    100.97.136.18/31 is directly connected, 19w2d, TenGigE0/0/1/0.2109
C    100.97.136.24/31 is directly connected, 36w3d, TenGigE0/0/1/0.2112
C    100.97.136.26/31 is directly connected, 36w2d, TenGigE0/0/1/0.2113
C    100.97.136.86/31 is directly connected, 24w3d, TenGigE0/0/1/0.2141


RP/0/RSP0/CPU0:abr1#show mpls forwarding vrf CUST-VRF

Local  Outgoing    Prefix             Outgoing     Next Hop        Bytes
Label  Label       or ID              Interface                    Switched
------ ----------- ------------------ ------------ --------------- ------------
18056  Unlabelled  10.194.160.228/30[V]   \
                                      Te0/0/1/0.2108 100.97.136.17   0
23148  Unlabelled  10.63.86.128/26[V]   \
                                      Te0/0/1/0.2103 100.97.136.7    447774
23149  Unlabelled  10.80.22.128/26[V]   \
                                      Te0/0/1/0.2103 100.97.136.7    382311
24196  Unlabelled  10.63.62.0/25[V]  Te0/0/1/0.2108 100.97.136.17   23679248
33737  Unlabelled  10.63.62.128/26[V]   \
                                      Te0/0/1/0.2108 100.97.136.17   1990611
33738  Unlabelled  10.63.62.192/27[V]   \
                                      Te0/0/1/0.2108 100.97.136.17   10234
34538  Unlabelled  10.63.72.176/29[V]   \
                                      Te0/0/1/0.2141 100.97.136.87   4850776
37323  Unlabelled  10.63.62.224/29[V]   \
                                      Te0/0/1/0.2108 100.97.136.17   3194
46981  Unlabelled  10.63.72.128/27[V]   \
                                      Te0/0/1/0.2141 100.97.136.87   8794
49344  Unlabelled  10.63.72.160/28[V]   \
                                      Te0/0/1/0.2141 100.97.136.87   2556
51993  Aggregate            CUST-VRF: Per-VRF Aggr[V]   \
                                      CUST-VRF             74676318

Config Examples:

IOS/XE:

conf t
mpls label mode vrf XXX protocol {all-afs|bgp-vpnv4|bgp-vpnv6} {per-ce|per-prefix|per-vrf|vrf-conn-aggr}
end
show ip vrf detail
show mpls forwarding-table
show mpls forwarding-table summary


IOS-XR:

conf t
router bgp YYY vrf XXX address-family {ipv4|ipv6} unicast label mode {per-ce|per-prefix|per-vrf|route-policy}
commit
end
show mpls forwarding-table
show mpls forwarding-table summary

! IOS-XR doesn't show label mode for a VRF in any "show" comamnd output. Check before
! and after for a specific VRF using the following to detect a change...

RP/0/RSP0/CPU0:ASR9000#show cef vrf XXX summary
...
  NNN prefixes with label imposition, NNN prefixes with label information


Junos:

set routing-instances XXX vrf-table-label

---