Flexible SR-TE Label Stack Allocation for BGP Services
This chapter provides information about the flexible segment routing traffic engineered (SR-TE) label stack allocation for BGP services.
Topics in this chapter include:
Applicability
The information and MD-CLI configuration in this chapter are based on SR OS Release 23.10.R3.
Flexible SR-TE label stack allocation for BGP services is supported on FP4-based platforms in SR OS Release 22.2.R1, and later.
Overview
FP4-based platforms support pushing 12 labels for SR-TE LSPs used in VPRN services and 10 labels for SR-TE LSPs used in EVPN VPLS or EVPN VPWS services. Layer 2 services, such as VPLS or Epipe services require an inner Ethernet header which reduces the space available for the label stack. In the case of R-VPLS or B-VPLS, even less label space is available for the label stack. For R-VPLS, only 9 labels can be pushed, and for B-VPLS, only 6.
Each SR-TE LSP is configured with a maximum transport label stack size, which is the sum of the values for the label stack size and the number of additional FRR labels. The label stack size ranges from 1 to 11 and the number of additional FRR labels ranges from 0 to 4, as follows. By default, the value for the label stack size is 6 and the number of additional FRR labels is 1.
[ex:/configure router "Base" mpls lsp "to-PE-2-empty" max-sr-labels]
A:admin@PE-1# label-stack-size ?
label-stack-size <number>
<number> - <1..11>
Dynamic Default - 6
Maximum label stack size
[ex:/configure router "Base" mpls lsp "to-PE-2-empty" max-sr-labels]
A:admin@PE-1# additional-frr-labels ?
additional-frr-labels <number>
<number> - <0..4>
Default - 1
Value for the maximum additional overhead labels
For VPRN services, the ingress label edge router (ILER) can push 12 labels, including the service label. A maximum of 11 labels remain for the sum of the label stack size and the number of additional FRR labels. The following error is raised because the sum of 10 and 2 exceeds the maximum of 11 labels:
*[ex:/configure router "Base" mpls lsp "to-PE-2-empty"]
A:admin@PE-1# commit
MINOR: MGMT_CORE #3001: configure router "Base" mpls lsp "to-PE-2-empty" max-sr-labels
label-stack-size
- Sum of label-stack-size and additional-frr-labels exceeds max labels per stack 11
Default egress label stack allocation for BGP services
In addition to the transport labels, the ILER pushes other fields into the packet, such as the service label, control word, Ethernet segment identifier (ESI), OAM labels, hash label, or entropy labels. The service label is present for all types of services, while the other labels depend on the service type. Some of these labels are always computed in the label stack allocation, such as the service label, OAM label, ESI, and control word. The label space for these labels is always reserved when computing the maximum stack; even when no Ethernet segment is used, one label is reserved for an ESI (for the purpose of BGP next hop resolution). Other labels are optional, such as the hash label or the entropy label, which are mutually exclusive. For the entropy label, two labels are required: the entropy label indicator (ELI) and the entropy label (EL) itself. These optional labels are only allocated when the hash or entropy label is configured. Default egress label stack limits for BGP services shows an overview of the default egress label stack limits for BGP services, such as IP-VPN, EVPN-IFL, EVPN VPWS or EVPN VPLS, EVPN-IFF, and EVPN B-VPLS.
| Features that reduce the label stack | IP-VPN (VPRN) | EVPN-IFL (VPRN) | EVPN VPLS or EVPN VPWS | EVPN-IFF (R-VPLS) | EVPN B-VPLS (PBB-EVPN) |
|---|---|---|---|---|---|
| Service label (always allocated) | 1 | 1 | 1 | 1 | 1 |
| OAM label (always allocated) | 1 | 1 | 0 | 0 | 0 |
| Control word (always allocated) | 0 | 0 | 1 | 1 | 1 |
| ESI label (always allocated) | 0 | 0 | 1 | 0 | 0 |
| Hash label (only when configured; mutually exclusive with EL) | 1 | 1 | 0 | 0 | 0 |
| Entropy EL+ELI (only when configured; mutually exclusive with the hash label) | 2 | 2 | 2 | 2 | 2 |
| Number of always-allocated labels | 2 | 2 | 3 | 2 | 2 |
| Number of allocated labels, including the options | 4 | 4 | 5 | 4 | 4 |
| Number of available labels | 12 | 12 | 10 | 9 | 6 |
| Number of available transport labels when no options are configured | 10 | 10 | 7 | 7 | 4 |
| Number of available transport labels with options | 8 | 8 | 5 | 5 | 2 |
The label space is always allocated for the first four features: the service label, OAM label, control word, and ESI label.
For IP-VPN or EVPN IFL VPRN services, only the service label and OAM label can be applied; therefore the transport label stack can have a maximum of 12 – 2 = 10 labels. In the case that the entropy label option is configured, two additional labels are reserved for EL and ELI and the transport label stack can have a maximum of 8 labels. When the hash label option is used, the number of available transport labels is only reduced by 1 and 9 transport labels are available.
For EVPN VPWS or EVPN VPLS services, the service label, control word, and ESI label are always allocated, even when the control word or ESI is not used. The number of available transport labels is 10 – 3 = 7 when no options are used. When the entropy label option is used, the number of available transport labels is further reduced by 2 and only 5 transport labels can be used.
For EVPN-IFF R-VPLS services, the traffic is either bridged traffic containing an ESI label or routed traffic without an ESI label. The ESI label is not accounted for because the routed encapsulation is always larger. For R-VPLS, the ILER can push a maximum of 9 labels, including the service label and control word. The number of available transport labels is 9 – 2 = 7, unless entropy labels are used. When the entropy label option is used, only 7 – 2 = 5 transport labels are available.
For B-VPLS services, the ILER can only push 6 labels, including the service label and control word. The number of available transport labels is only 6 – 2 = 4 when no options are used. When the entropy label option is used, only 4 – 2 = 2 transport labels are available.
SR-TE LSPs are configured with max-sr-labels label-stack-size <..> and max-sr-labels additional-frr-labels <..>. The number of these configured LSP labels must not exceed the number of available transport labels in the table. The BGP route next hop for the LSP cannot be resolved when the number of available labels is exceeded.
Dynamic egress label stack allocation for BGP services
With dynamic egress label stack allocation per service, SR OS accounts for the service label, but not for the labels that are not used. The dynamic-egress-label-limit true command extends the number of available labels in the dynamic egress label stack by not accounting for the labels that are not used. When the dynamic-egress-label-limit command is enabled, the OAM label cannot be used in VPRN services and vprn-ping and vprn-trace are not supported. In EVPN VPWS or EVPN VPLS services, the control word can still be used, as a result, the corresponding label space is allocated. In EVPN VPLS services, the ESI label is only accounted for if the VPLS has a SAP or SDP binding associated to an ES.
Dynamic egress label stack allocation is supported for IP-VPN, EVPN-IFL, EVPN VPWS, EVPN VPLS, EVPN-IFF, and EVPN B-VPLS. Dynamic egress label stack limits for BGP services shows a comparison for the dynamic egress label stack allocation for IP-VPN, EVPN-IFL, EVPN VPLS, and EVPN VPWS, but a similar comparison can be made for EVPN-IFF and EVPN B-VPLS.
| Features that reduce the label stack | dynamic-egress-label-limit false | dynamic-egress-label-limit true | |||||
|---|---|---|---|---|---|---|---|
| IP-VPN (VPRN) | EVPN-IFL (VPRN) | EVPN VPLS EVPN Epipe | IP-VPN (VPRN) | EVPN-IFL (VPRN) | EVPN VPLS EVPN Epipe | ||
| Service label | 1 (always allocated) | 1 (always allocated) | 1 (always allocated) | 1 (always allocated) | 1 (always allocated) | 1 (always allocated) | |
| OAM label | 1 (always allocated) | 1 (always allocated) | 0 | 0 | 0 | 0 | |
| Control word | 0 | 0 | 1 (always allocated) | 0 | 0 | 1 | |
| ESI label | 0 | 0 | 1 (always allocated) | 0 | 0 | 1 | |
| Hash label (mutually exclusive with EL) | 1 | 1 | 0 | 1 | 0 | 0 | |
| Entropy EL+ELI (mutually exclusive with the hash label) | 2 | 2 | 2 | 2 | 2 | 2 | |
| Number of always-allocated labels | 2 | 2 | 3 | 1 | 1 | 1 | |
| Number of allocated labels, including the options | 4 | 4 | 5 | 3 | 3 | 5 | |
| Number of available labels | 12 | 12 | 10 | 12 | 12 | 10 | |
| Number of available transport labels when no options are configured | 10 | 10 | 7 | 11 | 11 | 9 | |
| Number of available transport labels with options | 8 | 8 | 5 | 9 | 9 | 5 | |
When the dynamic-egress-label-limit command is enabled in an IP-VPN or EVPN-IFL service, the OAM label is not used and one additional transport label is available.
For IP-VPN or EVPN-IFL VPRN services, the ILER can push 12 labels and one of these labels is the service label. The remaining 11 labels are available for transport when no options are configured. When entropy labels are configured, 11 – 2 = 9 labels are available for transport.
For EVPN VPWS or EVPN VPLS services, the ILER can push 10 labels and one of these labels is the service label. The control word and ESI label are now considered as options. When no options are configured, 10 – 1 = 9 labels are available for the transport label stack. When the entropy label, control word, and ESI label are configured, only 5 labels are available for the transport label stack.
For EVPN-IFF services, the ILER can push 9 labels and one of these labels is the service label. When no options are configured, 9 – 1 = 8 labels are available for the transport label stack. When the control word and entropy label are configured, only 8 – 3 = 5 transport labels are available.
For EVPN B-VPLS services, the ILER can push 6 labels, including the service label. When no options are configured, 6 – 1 = 5 labels are available for the transport label stack. When the control word and entropy label are configured, only 5 – 3 = 2 transport labels are available.
Configuration
The Example topology consists of two nodes in an MPLS network:
- cards, MDAs, and ports
- router interfaces
- SR-ISIS
- MPLS and RSVP enabled
BGP is configured for the EVPN and VPN-IPv4 address families; on PE-1 as follows:
# on PE-1:
configure {
router "Base" {
autonomous-system 64500
bgp {
rapid-withdrawal true
peer-ip-tracking true
split-horizon true
rapid-update {
evpn true
}
group "internal" {
peer-as 64500
family {
vpn-ipv4 true
evpn true
}
}
neighbor "192.0.2.2" { # on PE-2: 192.0.2.1
group "internal"
}
}
The BGP configuration on PE-2 is similar.
SR-TE LSPs are configured between PE-1 and PE-2, as follows:
# on PE-1:
configure {
router "Base" {
mpls {
admin-state enable
interface "int-PE-1-PE-2" { # on PE-2: "int-PE-2-PE-1"
}
path "empty" {
admin-state enable
}
path "to-PE-2-strict" { # on PE-2: "to-PE-1-strict"
admin-state enable
hop 10 {
ip-address 192.168.12.2 # on PE-2: 192.168.12.1
type strict
}
}
lsp "to-PE-2-empty" { # on PE-2: "to-PE-1-empty"
admin-state enable
type p2p-sr-te
to 192.0.2.2 # on PE-2: to 192.0.2.1
path-computation-method local-cspf
max-sr-labels { # 10 labels - suited for VPRN
label-stack-size 8
additional-frr-labels 2
}
primary "empty" {
}
}
lsp "to-PE-2-strict" { # on PE-2: "to-PE-1-strict"
admin-state enable
type p2p-sr-te
to 192.0.2.2 # on PE-2: to 192.0.2.1
path-computation-method local-cspf
max-sr-labels { # 10 labels - suited for VPRN
label-stack-size 8
additional-frr-labels 2
}
primary "to-PE-2-strict" { # on PE-2: "to-PE-1-strict"
}
}
}
rsvp {
admin-state enable
interface "int-PE-1-PE-2" { # on PE-2: "int-PE-2-PE-1"
}
}
IP-VPN and EVPN-IFL services
For VPRN services, the ILER can push 12 labels: 1 service label, 1 OAM label, and 10 transport labels. VPRN-1 is an IP-VPN with the following configuration:
# on PE-1:
configure {
service {
vprn "VPRN-1" {
admin-state enable
description "VPRN-1 with BGP-IPVPN"
service-id 1
customer "1"
bgp-ipvpn {
mpls {
admin-state enable
route-distinguisher "192.0.2.1:1" # on PE-2: 192.0.2.2:1
vrf-target {
community "target:64500:1"
}
auto-bind-tunnel {
resolution filter
resolution-filter {
bgp false
sr-te true
}
}
}
}
interface "loopback" {
loopback true
ipv4 {
primary {
address 172.16.1.1 # on PE-2: 172.16.1.2
prefix-length 32
}
}
}
}
EVPN-IFL VPRN-2 is configured as follows:
# on PE-1:
configure {
service {
vprn "VPRN-2" {
admin-state enable
description "VPRN-2 with EVPN-IFL"
service-id 2
customer "1"
bgp-evpn {
mpls 1 {
admin-state enable
route-distinguisher "192.0.2.1:2" # on PE-2: 192.0.2.2:2
vrf-target {
community "target:64500:2"
}
auto-bind-tunnel {
resolution filter
resolution-filter {
sr-te true
}
}
}
}
interface "loopback" {
loopback true
ipv4 {
primary {
address 172.16.2.1 # on PE-2: 172.16.2.2
prefix-length 32
}
}
}
}
The BGP next hop is resolved for VPRN-1 and VPRN-2, as follows:
[/]
A:admin@PE-1# show router bgp next-hop vpn-ipv4 service-id 1
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
===============================================================================
BGP VPN Next Hop
===============================================================================
VPN Next Hop Owner
Autobind FibProg Reason
Labels (User-labels) FlexAlgo Metric
Admin-tag-policy (strict-tunnel-tagging) Last Mod.
-------------------------------------------------------------------------------
192.0.2.2 SR_TE
sr-te Y
-- (2) -- 10
-- (N) 00h04m09s
-------------------------------------------------------------------------------
Next Hops : 1
===============================================================================
[/]
A:admin@PE-1# show router bgp next-hop evpn service-id 2
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
===============================================================================
BGP VPN Next Hop
===============================================================================
VPN Next Hop Owner
Autobind FibProg Reason
Labels (User-labels) FlexAlgo Metric
Admin-tag-policy (strict-tunnel-tagging) Last Mod.
-------------------------------------------------------------------------------
192.0.2.2 SR_TE
sr-te Y
-- (2) -- 10
-- (N) 00h04m09s
-------------------------------------------------------------------------------
Next Hops : 1
===============================================================================
The number of user labels is 2 and corresponds to the sum of the service label and OAM label.
The route table for VPRN-1 on PE-1 shows that the BGP VPN-IPv4 route to 172.16.1.2/32 uses an SR-TE tunnel with ID 655362 to PE-2, as follows:
[/]
A:admin@PE-1# show router service-name "VPRN-1" route-table
===============================================================================
Route Table (Service: 1)
===============================================================================
Dest Prefix[Flags] Type Proto Age Pref
Next Hop[Interface Name] Metric
-------------------------------------------------------------------------------
172.16.1.1/32 Local Local 00h04m59s 0
loopback 0
172.16.1.2/32 Remote BGP VPN 00h04m51s 170
192.0.2.2 (tunneled:SR-TE:655362) 10
-------------------------------------------------------------------------------
No. of Routes: 2
Flags: n = Number of times nexthop is repeated
B = BGP backup route available
L = LFA nexthop available
S = Sticky ECMP requested
===============================================================================
The route table for VPRN-2 on PE-1 shows that the EVPN-IFL route to 172.16.2.2/32 also uses the SR-TE tunnel with ID 655362 to PE-2, as follows:
[/]
A:admin@PE-1# show router service-name "VPRN-2" route-table
===============================================================================
Route Table (Service: 2)
===============================================================================
Dest Prefix[Flags] Type Proto Age Pref
Next Hop[Interface Name] Metric
-------------------------------------------------------------------------------
172.16.2.1/32 Local Local 00h04m59s 0
loopback 0
172.16.2.2/32 Remote EVPN-IFL 00h04m51s 170
192.0.2.2 (tunneled:SR-TE:655362) 10
-------------------------------------------------------------------------------
No. of Routes: 2
Flags: n = Number of times nexthop is repeated
B = BGP backup route available
L = LFA nexthop available
S = Sticky ECMP requested
===============================================================================
The following illustrates that the BGP next hop cannot be resolved in a VPRN when the number of labels configured in the SR-TE LSP exceeds 10. In this example, the label stack size is increased to 9, while the number of additional FRR labels remains 2, as follows:
# on PE-1:
configure {
router "Base" {
mpls {
lsp "to-PE-2-empty" { # on PE-2: "to-PE-1-empty"
max-sr-labels {
label-stack-size 9
additional-frr-labels 2
}
}
lsp "to-PE-2-strict" # on PE-2: "to-PE-1-strict"
max-sr-labels {
label-stack-size 9
additional-frr-labels 2
}
}
The following shows that the BGP next hop cannot be resolved for the IP-VPN VPRN-1:
[/]
A:admin@PE-1# show router bgp next-hop vpn-ipv4
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
===============================================================================
BGP VPN Next Hop
===============================================================================
VPN Next Hop Owner
Autobind FibProg Reason
Labels (User-labels) FlexAlgo Metric
Admin-tag-policy (strict-tunnel-tagging) Last Mod.
-------------------------------------------------------------------------------
192.0.2.2 --
sr-te N LabelStackLimit
-- (2) --
-- (N) 00h00m14s
-------------------------------------------------------------------------------
Next Hops : 1
===============================================================================
The route is not programmed in the FIB because of a LabelStackLimit error.
In a similar way, the BGP next hop cannot be resolved for the EPVN-IFL VPRN-2, as follows:
[/]
A:admin@PE-1# show router bgp next-hop evpn service-id 2
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
===============================================================================
BGP VPN Next Hop
===============================================================================
VPN Next Hop Owner
Autobind FibProg Reason
Labels (User-labels) FlexAlgo Metric
Admin-tag-policy (strict-tunnel-tagging) Last Mod.
-------------------------------------------------------------------------------
192.0.2.2 --
sr-te N LabelStackLimit
-- (2) --
-- (N) 00h00m14s
-------------------------------------------------------------------------------
Next Hops : 1
===============================================================================
The route table for VPRN-1 does not contain a route to 172.16.1.2/32 anymore; only the local route remains, as follows:
[/]
A:admin@PE-1# show router service-name "VPRN-1" route-table
===============================================================================
Route Table (Service: 1)
===============================================================================
Dest Prefix[Flags] Type Proto Age Pref
Next Hop[Interface Name] Metric
-------------------------------------------------------------------------------
172.16.1.1/32 Local Local 00h05m52s 0
loopback 0
-------------------------------------------------------------------------------
No. of Routes: 1
Flags: n = Number of times nexthop is repeated
B = BGP backup route available
L = LFA nexthop available
S = Sticky ECMP requested
===============================================================================
In a similar way, the route table for VPRN-2 contains only the local route, as follows:
[/]
A:admin@PE-1# show router service-name "VPRN-2" route-table
===============================================================================
Route Table (Service: 2)
===============================================================================
Dest Prefix[Flags] Type Proto Age Pref
Next Hop[Interface Name] Metric
-------------------------------------------------------------------------------
172.16.2.1/32 Local Local 00h05m52s 0
loopback 0
-------------------------------------------------------------------------------
No. of Routes: 1
Flags: n = Number of times nexthop is repeated
B = BGP backup route available
L = LFA nexthop available
S = Sticky ECMP requested
===============================================================================
If the OAM label is not required, the dynamic-egress-label-limit command can be enabled in the VPRN services, as follows:
# on PE-1, PE-2:
configure {
service {
vprn "VPRN-1" {
bgp-ipvpn {
mpls {
dynamic-egress-label-limit true
}
}
}
vprn "VPRN-2" {
bgp-evpn {
mpls 1 {
dynamic-egress-label-limit true
}
}
}
The ILER can push 12 labels: 1 service label and 11 transport labels. The BGP next hop can be resolved for VPRN-1, as follows:
[/]
A:admin@PE-1# show router bgp next-hop vpn-ipv4 service-id 1
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
===============================================================================
BGP VPN Next Hop
===============================================================================
VPN Next Hop Owner
Autobind FibProg Reason
Labels (User-labels) FlexAlgo Metric
Admin-tag-policy (strict-tunnel-tagging) Last Mod.
-------------------------------------------------------------------------------
192.0.2.2 SR_TE
sr-te Y
-- (1) -- 10
-- (N) 00h00m10s
-------------------------------------------------------------------------------
Next Hops : 1
===============================================================================
The number of user labels is 1 and only the service label is accounted for.
In a similar way, the BGP next hop can be resolved for VPRN-2 and the number of user labels is 1, as follows:
[/]
A:admin@PE-1# show router bgp next-hop evpn service-id 2
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
===============================================================================
BGP VPN Next Hop
===============================================================================
VPN Next Hop Owner
Autobind FibProg Reason
Labels (User-labels) FlexAlgo Metric
Admin-tag-policy (strict-tunnel-tagging) Last Mod.
-------------------------------------------------------------------------------
192.0.2.2 SR_TE
sr-te Y
-- (1) -- 10
-- (N) 00h00m10s
-------------------------------------------------------------------------------
Next Hops : 1
===============================================================================
The following shows that the dynamic-egress-label-limit command is enabled for IP-VPN VPRN-1:
[/]
A:admin@PE-1# show service id "VPRN-1" bgp-ipvpn
===============================================================================
Service 1 BGP-IPVPN MPLS Information
===============================================================================
Admin State : Up Oper State : Up
VRF Import : None
VRF Export : None
Route Dist. : None
Oper Route Dist : 192.0.2.1:1
Oper RD Type : configured
Route Target : target:64500:1
Route Target Impor: None
Route Target Expor: None
Domain-Id : None
Dyn Egr Lbl Limit : Enabled
Auto-Bind Tunnel
Resolution : filter Strict Tnl Tag : False
ECMP : 1 Flex Algo FB : False
Weighted ECMP : False
BGP Instance : 1
Filter Tunnel Type: sr-te
===============================================================================
The following shows that the dynamic-egress-label-limit command is enabled for EVPN-IFL VPRN-2:
[/]
A:admin@PE-1# show service id "VPRN-2" bgp-evpn
===============================================================================
BGP EVPN MPLS Table
===============================================================================
Admin State : Up Oper State : Up
VRF Import : None
VRF Export : None
Route Dist. : 192.0.2.1:2
Oper Route Dist. : 192.0.2.1:2
Oper RD Type : configured
Route Target : target:64500:2
Route Target Import: None
Route Target Export: None
Default Route Tag : None
Domain-Id : None
Dyn Egr Lbl Limit : Enabled
EVI : 0
Advertise : Disabled
Weighted ECMP : Disabled
Auto-Bind Tunnel
Resolution : filter Strict Tnl Tag : False
ECMP : 1 Flex Algo FB : False
Bgp Instance : 1
Filter Tunnel Types: sr-te
Tunnel Encap
MPLS : True MPLSoUDP : False
===============================================================================
EVPN VPWS services
Epipe-3 is configured as follows:
# on PE-1:
configure {
service {
epipe "Epipe-3" {
admin-state enable
service-id 3
customer "1"
bgp 1 {
}
sap 1/1/c10/1:3 {
description "SAP to CE-31" # on PE-2: SAP to CE-32
}
bgp-evpn {
evi 3
local-attachment-circuit "ac-1" { # on PE-2: ac-2
eth-tag 1 # on PE-2: eth-tag 2
}
remote-attachment-circuit "ac-2" { # on PE-2: ac-1
eth-tag 2 # on PE-2: eth-tag 1
}
mpls 1 {
admin-state enable
auto-bind-tunnel {
resolution filter
resolution-filter {
sr-te true
}
}
}
}
}
Layer 2 services, such as EVPN VPWS or EVPN VPLS services, cannot have the same number of labels in the stack as for VPRN services. A LabelStackLimit error causes Epipe-3 to be in an operationally down state, as follows:
[/]
A:admin@PE-1# show service service-using epipe
===============================================================================
Services [epipe]
===============================================================================
ServiceId Type Adm Opr CustomerId Service Name
-------------------------------------------------------------------------------
3 Epipe Up Down 1 Epipe-3
-------------------------------------------------------------------------------
Matching Services : 1
-------------------------------------------------------------------------------
===============================================================================
The following output shows that the BGP next hop cannot be resolved because of a LabelStackLimit error. By default, the number of user labels is 3 and accounts for 1 for the service label, 1 for the ESI label, and 1 for the control word, as follows:
[/]
A:admin@PE-1# show router bgp next-hop evpn service-id 3
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
===============================================================================
BGP VPN Next Hop
===============================================================================
VPN Next Hop Owner
Autobind FibProg Reason
Labels (User-labels) FlexAlgo Metric
Admin-tag-policy (strict-tunnel-tagging) Last Mod.
-------------------------------------------------------------------------------
192.0.2.2 --
sr-te N LabelStackLimit
-- (3) --
-- (N) 00h04m24s
-------------------------------------------------------------------------------
Next Hops : 1
===============================================================================
For EVPN VPWS and EVPN VPLS services, the ILER can push 10 labels, including the service label, ESI label, and control word; therefore, the sum of the label stack size and the additional FRR labels cannot exceed 10 – 3 = 7 transport labels. However, when the service is configured with dynamic-egress-label-limit true, only the service label must be accounted for and the number of transport labels can be 10 – 1 = 9. The SR-TE LSPs are configured with a label stack size of 9 and without additional FRR labels; the Epipe service is configured with dynamic-egress-label-limit true, as follows:
# on PE-1:
configure {
router "Base" {
mpls {
lsp "to-PE-2-empty" { # on PE-2: "to-PE-1-empty"
max-sr-labels {
label-stack-size 9
additional-frr-labels 0
}
}
lsp "to-PE-2-strict" # on PE-2: "to-PE-1-strict"
max-sr-labels {
label-stack-size 9
additional-frr-labels 0
}
}
}
}
service {
epipe "Epipe-3" {
bgp-evpn {
mpls 1 {
dynamic-egress-label-limit true
}
}
The BGP next hop is now resolved and the route is programmed in the FIB. The number of user labels is 1 for the service label, as follows:
[/]
A:admin@PE-1# show router bgp next-hop evpn service-id 3
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
===============================================================================
BGP VPN Next Hop
===============================================================================
VPN Next Hop Owner
Autobind FibProg Reason
Labels (User-labels) FlexAlgo Metric
Admin-tag-policy (strict-tunnel-tagging) Last Mod.
-------------------------------------------------------------------------------
192.0.2.2 SR_TE
sr-te Y
-- (1) -- 10
-- (N) 00h00m18s
-------------------------------------------------------------------------------
Next Hops : 1
===============================================================================
Epipe-3 is now in an operationally up state, as follows:
[/]
A:admin@PE-1# show service service-using epipe
===============================================================================
Services [epipe]
===============================================================================
ServiceId Type Adm Opr CustomerId Service Name
-------------------------------------------------------------------------------
3 Epipe Up Up 1 Epipe-3
-------------------------------------------------------------------------------
Matching Services : 1
-------------------------------------------------------------------------------
===============================================================================
From Epipe-3 on PE-1, the BGP EVPN-MPLS destination 192.0.2.2 can be reached via an SR-TE tunnel with ID 655362, as follows:
[/]
A:admin@PE-1# show service id "Epipe-3" evpn-mpls
===============================================================================
BGP EVPN-MPLS Dest (Instance 1)
===============================================================================
TEP Address Egr Label Last Change
Transport:Tnl-id
-------------------------------------------------------------------------------
192.0.2.2 524286 02/22/2024 14:13:49
sr-te:655362
-------------------------------------------------------------------------------
Number of entries : 1
-------------------------------------------------------------------------------
===============================================================================
---snip---
EVPN VPLS services
On PE-1 and PE-2, EVPN VPLS "VPLS-4" is configured:
# on PE-1:
configure {
service {
vpls "VPLS-4" {
admin-state enable
service-id 4
customer "1"
bgp 1 {
}
bgp-evpn {
evi 4
mpls 1 {
admin-state enable
ingress-replication-bum-label true
ecmp 2
auto-bind-tunnel {
resolution filter
resolution-filter {
sr-te true
}
}
}
}
sap 1/1/c10/1:4 {
description "SAP to CE-41" # on PE-2: "SAP to CE-42"
}
}
The maximum number of transport labels in EVPN VPLS services is the same as for EVPN VPWS services. By default, the ILER can push a maximum of 10 – 3 = 7 transport labels. The SR-TE LSPs are configured with a label stack size of 9 labels; therefore, a LabelStackLimit error occurs and the BGP next hop cannot be resolved. The number of user labels is 3 and accounts for 1 for the service label, 1 for the ESI label, and 1 for the control word, as follows:
[/]
A:admin@PE-1# show router bgp next-hop evpn service-id 4
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
===============================================================================
BGP VPN Next Hop
===============================================================================
VPN Next Hop Owner
Autobind FibProg Reason
Labels (User-labels) FlexAlgo Metric
Admin-tag-policy (strict-tunnel-tagging) Last Mod.
-------------------------------------------------------------------------------
192.0.2.2 --
sr-te N LabelStackLimit
-- (3) --
-- (N) 00h00m11s
-------------------------------------------------------------------------------
Next Hops : 1
===============================================================================
The number of available transport labels can be increased when dynamic-egress-label-limit is enabled on PE-1 and PE-2, as follows:
# on PE-1, PE-2:
configure {
service {
vpls "VPLS-4" {
bgp-evpn {
mpls 1 {
dynamic-egress-label-limit true
With this configuration, only the service label is accounted for and the number of user labels is reduced to 1. The BGP next hop can be resolved, as follows:
[/]
A:admin@PE-1# show router bgp next-hop evpn service-id 4
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
===============================================================================
BGP VPN Next Hop
===============================================================================
VPN Next Hop Owner
Autobind FibProg Reason
Labels (User-labels) FlexAlgo Metric
Admin-tag-policy (strict-tunnel-tagging) Last Mod.
-------------------------------------------------------------------------------
192.0.2.2 SR_TE
sr-te Y
-- (1) -- 10
-- (N) 00h02m21s
-------------------------------------------------------------------------------
Next Hops : 1
===============================================================================
The following EVPN-MPLS destinations are established in VPLS-4 on PE-1:
[/]
A:admin@PE-1# show service id "VPLS-4" evpn-mpls
===============================================================================
BGP EVPN-MPLS Dest (Instance 1)
===============================================================================
TEP Address Transport:Tnl Egr Label Oper Mcast Num
State MACs
-------------------------------------------------------------------------------
192.0.2.2 sr-te:655362 524282 Up bum 0
192.0.2.2 sr-te:655362 524283 Up none 1
-------------------------------------------------------------------------------
Number of entries: 2
-------------------------------------------------------------------------------
===============================================================================
---snip---
EVPN-IFF services
The R-VPLS configuration on PE-1 is as follows:
# on PE-1:
configure {
service {
vpls "R-VPLS-6" {
admin-state enable
description "R-VPLS 6 - broadcast domain 1"
service-id 6
customer "1"
routed-vpls {
}
sap 1/1/c10/1:6 {
description "SAP to CE-61"
}
}
vprn "ip-vrf-66" {
admin-state enable
service-id 66
customer "1"
interface "int-R-VPLS-6" { # toward BD 1 with local CEs
mac 00:00:00:16:06:01
ipv4 {
primary {
address 172.16.6.1
prefix-length 24
}
vrrp 1 {
backup [172.16.6.254]
passive true
ping-reply true
traceroute-reply true
}
}
vpls "R-VPLS-6" {
}
}
interface "int-sbd-600" { # toward PE-2
mac 00:00:00:00:60:01
ipv4 {
primary {
address 10.0.6.1
prefix-length 24
}
}
vpls "sbd-600" {
}
}
}
vpls "sbd-600" {
admin-state enable
description "supplementary broadcast domain R-VPLS 600 - backhaul"
service-id 600
customer "1"
routed-vpls {
}
bgp 1 {
route-distinguisher "192.0.2.1:600"
}
bgp-evpn {
evi 600
routes {
ip-prefix {
advertise true
}
}
mpls 1 {
admin-state enable
auto-bind-tunnel {
resolution filter
resolution-filter {
sr-te true
}
}
}
}
}
The R-VPLS configuration on PE-2 is similar.
For R-VPLS services, the ILER can push a maximum of 9 labels, including the service label and control word. By default, a maximum of 7 transport labels can be pushed. When dynamic-egress-label-limit is enabled in the R-VPLS, a maximum of 8 transport labels are available. The SR-TE LSPs are configured with a label stack size of 8 labels and dynamic-egress-label-limit is enabled in R-VPLS "sbd-600", as follows:
# on PE-1:
configure {
router "Base" {
mpls {
lsp "to-PE-2-empty" { # on PE-2: lsp "to-PE-1-empty"
max-sr-labels {
label-stack-size 8
additional-frr-labels 0
}
}
lsp "to-PE-2-strict" { # on PE-2: lsp "to-PE-1-strict"
max-sr-labels {
label-stack-size 8
additional-frr-labels 0
}
}
}
}
service {
vpls "sbd-600" {
bgp-evpn {
mpls 1 {
dynamic-egress-label-limit true
}
}
The BGP next hop can be resolved in R-VPLS "sbd-600", as follows:
[/]
A:admin@PE-1# show router bgp next-hop evpn service-id 600
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
===============================================================================
BGP VPN Next Hop
===============================================================================
VPN Next Hop Owner
Autobind FibProg Reason
Labels (User-labels) FlexAlgo Metric
Admin-tag-policy (strict-tunnel-tagging) Last Mod.
-------------------------------------------------------------------------------
192.0.2.2 SR_TE
sr-te Y
rvpls (1) -- 10
-- (N) 00h00m18s
-------------------------------------------------------------------------------
Next Hops : 1
===============================================================================
The following EVPN-MPLS destination is established in R-VPLS "sbd-600":
[/]
A:admin@PE-1# show service id "sbd-600" evpn-mpls
===============================================================================
BGP EVPN-MPLS Dest (Instance 1)
===============================================================================
TEP Address Transport:Tnl Egr Label Oper Mcast Num
State MACs
-------------------------------------------------------------------------------
192.0.2.2 sr-te:655362 524281 Up bum 1
-------------------------------------------------------------------------------
Number of entries: 1
-------------------------------------------------------------------------------
===============================================================================
---snip---
EVPN PBB services
The configuration for B-VPLS and I-VPLS is as follows:
# on PE-1:
configure {
service {
vpls "B-VPLS-500" {
admin-state enable
service-id 500
customer "1"
service-mtu 2000
pbb-type b-vpls
pbb {
source-bmac {
address 00:00:00:00:00:01
}
}
bgp 1 {
}
bgp-evpn {
evi 500
mpls 1 {
admin-state enable
auto-bind-tunnel {
resolution filter
resolution-filter {
sr-te true
}
}
}
}
}
vpls "I-VPLS-5" {
admin-state enable
service-id 5
customer "1"
pbb-type i-vpls
pbb {
backbone-vpls "B-VPLS-500" {
isid 5
}
}
sap 1/1/c10/1:5 {
description "SAP to CE-51" # on PE-2: SAP to CE-52
}
}
The SR-TE LSPs are configured with a label stack size of 8 labels; therefore, a LabelStackLimit error occurs for the B-VPLS and the BGP next hop cannot be resolved, as follows:
[/]
A:admin@PE-1# show router bgp next-hop evpn service-id 500
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
===============================================================================
BGP VPN Next Hop
===============================================================================
VPN Next Hop Owner
Autobind FibProg Reason
Labels (User-labels) FlexAlgo Metric
Admin-tag-policy (strict-tunnel-tagging) Last Mod.
-------------------------------------------------------------------------------
192.0.2.2 --
sr-te N LabelStackLimit
bvpls (2) --
-- (N) 00h00m12s
-------------------------------------------------------------------------------
Next Hops : 1
===============================================================================The LER can only push maximum 6 labels for the B-VPLS, including the service label and the control word. By default, only 4 transport labels are available when no options are used. When dynamic-egress-label-limit is enabled in the B-VPLS, only the service label is accounted for and maximum 5 labels are available for transport. The SR-TE LSPs are configured with a label stack size of 5 and dynamic-egress-label-limit is enabled in the B-VPLS:
# on PE-1:
configure {
router "Base" {
mpls {
lsp "to-PE-2-empty" { # on PE-2: LSP "to-PE-1-empty"
max-sr-labels {
label-stack-size 5
additional-frr-labels 0
}
}
lsp "to-PE-2-strict" { # on PE-2: LSP "to-PE-1-strict"
max-sr-labels {
label-stack-size 5
additional-frr-labels 0
}
}
}
}
service {
vpls "B-VPLS-500" {
bgp-evpn {
mpls 1 {
dynamic-egress-label-limit true
}
}
The BGP next hop can now be resolved for the B-VPLS, as follows:
[/]
A:admin@PE-1# show router bgp next-hop evpn service-id 500
===============================================================================
BGP Router ID:192.0.2.1 AS:64500 Local AS:64500
===============================================================================
===============================================================================
BGP VPN Next Hop
===============================================================================
VPN Next Hop Owner
Autobind FibProg Reason
Labels (User-labels) FlexAlgo Metric
Admin-tag-policy (strict-tunnel-tagging) Last Mod.
-------------------------------------------------------------------------------
192.0.2.2 SR_TE
sr-te Y
bvpls (1) -- 10
-- (N) 00h00m13s
-------------------------------------------------------------------------------
Next Hops : 1
===============================================================================
In B-VPLS-500 on PE-1, the EVPN-MPLS destination 192.0.2.2 can be reached via an SR-TE tunnel with ID 655362, as follows:
[/]
A:admin@PE-1# show service id "B-VPLS-500" evpn-mpls
===============================================================================
BGP EVPN-MPLS Dest (Instance 1)
===============================================================================
TEP Address Transport:Tnl Egr Label Oper Mcast Num
State MACs
-------------------------------------------------------------------------------
192.0.2.2 sr-te:655362 524280 Up bum 1
-------------------------------------------------------------------------------
Number of entries: 1
-------------------------------------------------------------------------------
===============================================================================
---snip---Conclusion
Flexible SR-TE label stack allocation can increase the number of available transport labels in services when OAM labels, ESI labels, or control word are not used.