Establishing SR-TE (CSPF) LSPs through inter OSPF areas is a challenge, as these LSPs rely on TED, and this TED is per OSPF area or IS-IS level.
In our previous tech post "Migrating from OSPF/LDP to OSPF/SR-MPLS", we explored how to transition from OSPF/LDP to OSPF/SR-MPLS for SR and the associated benefits it brings to modern networks.
In this post, we will explore how to create four types of SR-TE LSPs across an inter-OSPF areas network. Specifically, we will focus on the process of establishing SR-TE LSPs across multiple OSPF areas, with particular emphasis on the reliance of these LSPs on the TED.
SR-TE LSPs can be leveraged to migrate traffic from LDP to SR. In this tech post, we will review the migration options, focusing on static SR-TE LSPs with a Dynamic TE (CSPF) Path
From a JUNOS perspective, Static LSPs are mainly configured through CLI or Netconf, while Dynamic LSPs are PCE Initiated (e.g., Juniper Paragon), BGP-SRTE and ODN (dynamic tunnels).
In this tech post, we will consider four types of LSPs with transport class and BGP color community, each with different constraints on OSPF Areas:
IGP Metric
TE Metric
Delay Metric
Admin Groups
When setting up LSPs, dynamic paths through OSPF require TED from multiple areas, as TED is area-specific. To bring up an LSP, a BGP-LS producer (typically ABRs), a BGP-LS consumer (such as ingress PEs or PCE), and a Route Reflector are necessary. In this post, we will use BGP-LS TED distribution as a controllerless inter-area solution for SR-TE LSPs.
Our test topology consists of three OSPF Areas: Area 0, Area 1, and Area 2. Routers P1 to P4 are connected through OSPF Area 0. PE11 and PE12 are connected to P1 and P2 in OSPF area 1, while PE13 and PE14 are connected to P3 and P4 in OSPF area 2.
Figure 1: Multi OSPF Area and LDP
The entire network is based on IPv4/OSPF with Segment Routing as the MPLS signaling protocol. BGP is used among PEs and the Route Reflector for inet, inet-vpn, inet6, inet6-vpn, and evpn address families. Our core network is a BGP-free core.
The network topology is also IPv6-free, with a shared L3VPN across all PEs for both IPv4 and IPv6 CE traffic. 6VPE and 6PE are utilized to enable IPv6 communication among CEs over an IPv4/MPLS network.
EVPN E-Line (EPL) is used between PE11 and PE13 for IPv4 and IPv6 traffic.
EVPN E-Line (EVPL) for VLAN 600 is used between PE12 and PE14 for IPv4 and IPv6 traffic.
EVPN E-LAN for VLAN 700 is used between PE12 and PE14 for IPv4 and IPv6 traffic.
TE LSPs do not use the LSDB to calculate paths; instead, they rely on the TED for TE path calculation. TE information is included in the IGP's LSDB, and this TE information can be copied into the TED.
Both OSPF and IS-IS populate TED per OSPF area or IS-IS level. However, TED population is not automatic and requires specific configuration. This is possible through OSPF or IS-IS extensions, which allow TE link attributes, such as TE metrics, delay metrics, or administrative groups, to be advertised.
When enabling the "l3-unicast-topology" knob under OSPF traffic engineering on all routers, IGP topology information is downloaded into the TED. The L3 unicast topology, along with any received TE information from other routers, is copied into the TED. However, locally configured TE information is not automatically copied into TED.
The "Advertisement always" knob under OSPF traffic engineering ensures that TE information is advertised into SR.
The following configuration is required to populate TED per OSPF area.
Before diving into our four types of SR-TE LSPs, let's first explore how TED and BGP-LS work. When attempting to configure an SR-TE (CSPF) LSP across multiple areas or domains, the LSP will fail to be established because TED is specific to each area or domain. We can validate this behavior through the example and verification process outlined below.
In this case, we're trying to establish an LSP from PE11 in OSPF Area 1 to PE13 in OSPF Area 2, using IGP as the metric type.
jnpr@MX304-PE11# run show spring-traffic-engineering lsp
To State LSPname
192.168.0.13-130<c> Down PE11_to_PE13_COLOR_130
jnpr@MX304-PE11# run show spring-traffic-engineering lsp detail |no-more
E = Entropy-label Capability
Name: PE11_to_PE13_COLOR_130
Tunnel-source: Static configuration
Tunnel Forward Type: SRMPLS
To: 192.168.0.13-130<c>
State: Down
Path: TO_PE13
Path Status: NA
Outgoing interface: NA
Auto-translate status: Disabled Auto-translate result: N/A
Compute Status:Enabled , Compute Result:failure , Compute-Profile Name:TO_PE13_IGP_METRIC
Total number of computed paths: 0
From a TE perspective, multi-domain refers to multiple OSPF areas or instances, multiple IS-IS levels or instances, and multiple BGP autonomous systems. TED can be populated through the IGP's LSDB and BGP-LS.
BGP-LS allows TE link and node information to span multiple areas or autonomous systems, enabling LSP path computation across multiple domains. It leverages the proven scalability of BGP and its policies.
In this context, BGP-LS producers (such as ABRs) advertise their local TED via BGP-LS, typically to a Route Reflector. From the lsdist0 perspective, this means importing TED. BGP-LS consumers (such as the Ingress PE) import the BGP-LS information, and from the lsdist0 perspective, this means exporting lsdist0 to TED.
TED import or export is considered from the lsdist0 perspective, as shown in
Figure 2: JUNOS Implementation of BGP Link-State Distribution
Based on our topology, the BGP-LS and TED import/export configuration for P1, PE, and the Route Reflector is shown. The same configuration applies to the other P and PE routers.
In this way, all routers have the same TED through BGP-LS, enabling PEs to establish a multi-domain LSP. The next four sections will explain how to set up SR-TE (CSPF) LSPs with dynamic paths through a multi-area OSPF network. We are not merging OSPF's LSDBs, so OSPF scale remains unaffected. Additionally, summarized addresses can be added without leaking /32s between domains.
We're configuring a color 130 LSP from PE11 to PE13. This LSP will use a dynamic path through OSPF areas, with IGP as the metric type. The LSP route will be added to the routing table of transport class 130, which will then be used to resolve BGP PNH for routes with the same community color. To enable dynamic creation of transport classes, we can use the "auto-create" knob under the transport-class configuration stanza.
A compute profile allows the ingress PE to calculate the LSP's dynamic path based on the constraints defined within the profile. In this case, we are using an IGP metric-type constraint.
This LSP will be used exclusively for IPv4 traffic from PE11 to PE13.
policy-options {
community color:0:130 members color:0:130;
}
routing-options {
route-distinguisher-id 192.168.0.11;
resolution {
preserve-nexthop-hierarchy;
}
transport-class {
}
name 130 {
color 130;
}
}
}
protocols {
source-packet-routing {
compute-profile TO_PE13_IGP_METRIC {
no-label-stack-compression;
metric-type {
igp;
}
}
source-routing-path PE11_to_PE13_COLOR_130 {
to 192.168.0.13;
color 130;
primary {
TO_PE13 {
compute {
TO_PE13_IGP_METRIC;
}
}
}
}
use-transport-class;
}
}
Figure 3: SR-TE LSP with IGP Metric CSPF
The LSP is in an up state and has four paths. The figure above illustrates one of these paths and the corresponding label stack. Note that adjacency labels are used due to the "no-label-stack-compression" knob. Label compression is not equivalent to ECMP (Equal-Cost Multi-Path). Our compute service computes ECMP regardless of whether label compression is enabled or not.
jnpr@MX304-PE11# run show route table junos-rti-tc-130.inet.3
junos-rti-tc-130.inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.0.13/32 *[SPRING-TE/8] 04:42:26, metric 1, metric2 30
> to 192.168.7.1 via et-0/0/1.0, Push 24, Push 20(top)
> to 192.168.7.1 via et-0/0/1.0, Push 24, Push 16(top)
to 192.168.10.1 via et-0/0/3.0, Push 24, Push 16(top)
to 192.168.10.1 via et-0/0/3.0, Push 24, Push 18(top)
IPv4 BGP routes tagged with the 130 color community will resolve PNH in transport class instance 130. If no route to resolve PNH in this instance, the routes will fall back to the inet.3 table.
In our topology, we will map PE13's IPv4 "Purple" VRF traffic from PE11 to PE13 into this LSP.
As shown below, we define the color community with a color value of 130. In the egress PE (in this case, PE13), IPv4 "Purple" VRF traffic will be tagged with this community through a policy statement attached as an export to the VRF.
policy-options {
policy-statement VRF_PURPLE_IPv4_COLOR_130 {
term 1 {
from family inet;
then {
community add color:0:130;
community add target:65511:100;
accept;
}
}
}
community color:0:130 members color:0:130;
community target:65511:100 members target:65511:100;
}
routing-instances {
VRF_PURPLE {
instance-type vrf;
vrf-export VRF_PURPLE_IPv4_COLOR_130;
}
}
PE13 receives IPv4 "Purple" VRF routes within color community 130. Below is the label stack for these IPv4 routes.
jnpr@MX304-PE11# run show route table VRF_PURPLE.inet.0 10.13/16 extensive expanded-nh | match inet.3
192.168.0.12/32 Originating RIB: inet.3
192.168.0.13/32 Originating RIB: junos-rti-tc-130.inet.3
192.168.0.14/32 Originating RIB: inet.3
The IPv4 traffic targeted to the CE22 LAN crosses through the nodes defined in the PE11 to PE13 LSP, with the label stack being reduced as the traffic passes through each LSP node.
jnpr@MX304-PE11# run traceroute routing-instance VRF_PURPLE 10.13.3.1
traceroute to 10.13.3.1 (10.13.3.1), 30 hops max, 52 byte packets
1 192.168.1.1 (192.168.1.1) 0.985 ms 0.672 ms 0.708 ms
MPLS Label=20 CoS=0 TTL=1 S=0
MPLS Label=24 CoS=0 TTL=1 S=0
MPLS Label=16 CoS=0 TTL=1 S=1
2 192.168.11.1 (192.168.11.1) 4.919 ms 0.768 ms 0.616 ms
MPLS Label=24 CoS=0 TTL=1 S=0
MPLS Label=16 CoS=0 TTL=2 S=1
3 172.16.3.1 (172.16.3.1) 0.737 ms 0.484 ms 0.473 ms
4 10.13.3.1 (10.13.3.1) 3.976 ms 4.781 ms 5.098 ms
EVPN E-Line traffic between PE11 and PE13 is still utilizing SR. As a result, EVPN BGP routes are not marked with a color community, unlike the VRF routes.
The next SR-TE LSP will have color 131, established from PE11 to PE13. This LSP uses a dynamic path through OSPF areas with TE as the metric type. The default optimization for the compute request is TE. If TE hasn't been explicitly configured, it will be inherited from the IGP metric.
This LSP route will be added to the routing table of transport class 131, and this table will be used to resolve BGP PNH for routes with the same community color. A compute profile enables the ingress PE to calculate the LSP's dynamic path based on the constraints defined in the profile. In this case, we're using the TE metric-type constraint.
This LSP will be used exclusively for IPv6 traffic from PE11 to PE13. By leveraging color LSPs and color communities, we can apply distinct constraints for IPv4 and IPv6 traffic, enabling separate dynamic path calculations for each.
policy-options {
community color:0:131 members color:0:131;
}
routing-options {
route-distinguisher-id 192.168.0.11;
resolution {
preserve-nexthop-hierarchy;
}
transport-class {
name 131 {
color 131;
}
}
}
protocols {
source-packet-routing {
compute-profile TO_PE13_TE_METRIC {
no-label-stack-compression;
metric-type {
te;
}
}
source-routing-path PE11_to_PE13_COLOR_131 {
to 192.168.0.13;
color 131;
primary {
TO_PE13_TE_METRIC {
compute {
TO_PE13_TE_METRIC;
}
}
}
}
use-transport-class;
}
}
We will configure a higher TE link metric between P1 and P3 and P2 and P4, ensuring that our LSP avoids these links due to their higher TE metrics. Below, we illustrate the TE metric between P1 and P3.
The LSP is in an up state and has two paths. The figure above shows these two paths and the corresponding label stack. Note that adjacency labels are used due to the "no-label-stack-compression" knob.
jnpr@MX304-PE11# run show spring-traffic-engineering lsp
To State LSPname
192.168.0.13-130<c> Up PE11_to_PE13_COLOR_130
192.168.0.13-131<c> Up PE11_to_PE13_COLOR_131
jnpr@MX304-PE11# run show spring-traffic-engineering lsp detail | no-more
Name: PE11_to_PE13_COLOR_131
Tunnel-source: Static configuration
Tunnel Forward Type: SRMPLS
To: 192.168.0.13-131<c>
State: Up
Path: TO_PE13_TE_METRIC
Auto-translate status: Disabled Auto-translate result: N/A
Compute Status:Enabled , Compute Result:success , Compute-Profile Name:TO_PE13_TE_METRIC
Total number of computed paths: 2
Computed-path-index: 2
TE metric: 30, IGP metric: 30
Delay metrics: Min: 3, Max: 3, Avg: 3
Metric optimized by type: TE
computed segments count: 3
computed segment : 1 (computed-adjacency-segment):
label: 18
source router-id: 192.168.0.11, destination router-id: 192.168.0.2
source interface-address: 192.168.10.2, destination interface-address: 192.168.10.1
computed segment : 2 (computed-adjacency-segment):
label: 26
source router-id: 192.168.0.2, destination router-id: 192.168.0.3
source interface-address: 192.168.5.1, destination interface-address: 192.168.5.2
computed segment : 3 (computed-adjacency-segment):
label: 18
source router-id: 192.168.0.3, destination router-id: 192.168.0.13
source interface-address: 192.168.11.1, destination interface-address: 192.168.11.2
The LSP path, illustrated in orange, goes from PE11 to P1, P4, and finally to PE13. The first adjacency label, "18", represents the interface from PE11 to P2. This label is not pushed into the label stack; rather, it is used to determine the outgoing interface. The second adjacency label, "26", is the top label, which means that when P2 receives this label, it is popped, and traffic is sent to P3 via the P2 to P3 link. The final transport adjacency label, "18", is the label advertised from P3 to P2. When P3 receives this label, it pops it and forwards traffic to PE13 via the P3 to PE13 link. The last label, "16", in the stack is the VRF service label, advertised from PE13 to the Route Reflector (RR).
Our LSP is programmed into junos-rti-tc-131.inet.3 and junos-rti-tc-131.inet6.3 for IPv4 and IPv6 destinations, respectively, as SPRING-TE with a protocol preference of 8. The label stack shows the labels pushed into packets for this LSP.
jnpr@MX304-PE11# run show route table junos-rti-tc-131.inet6.3 | no-more
junos-rti-tc-131.inet6.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
::ffff:192.168.0.13/128
*[SPRING-TE/8] 00:21:16, metric 1, metric2 30
> to 192.168.10.1 via et-0/0/3.0, Push 18, Push 26(top)
to 192.168.7.1 via et-0/0/1.0, Push 20, Push 18(top)
IPv6 BGP routes tagged with the 131 color community will resolve PNH in transport class instance 131. If there is no route to resolve PNH in this instance, the routes will fall back to the inet.3 table.
In our topology, we will map PE13's IPv6 "Purple" VRF traffic from PE11 to PE13 into this LSP.
As shown below, we define the color community with a 131 color value. In the egress PE (in this case, PE13), IPv6 "Purple" VRF traffic will be tagged with this community through a policy statement, which is attached as an export to this VRF.
policy-options {
policy-statement VRF_PURPLE_IPv6_COLOR_131 {
term 1 {
from family inet6;
then {
community add target:65511:100;
community add color:0:131;
accept;
}
}
}
community color:0:131 members color:0:131;
community target:65511:100 members target:65511:100;
}
routing-instances {
VRF_PURPLE {
instance-type vrf;
vrf-export [ VRF_PURPLE_IPv4_COLOR_130 VRF_PURPLE_IPv6_COLOR_131 ];
}
}
PE13 receives IPv6 "Purple" VRF routes within color community 131. Below is the label stack for these IPv6 routes.
jnpr@MX304-PE11# run show route table VRF_PURPLE.inet6.0 2001:10:13::/48 extensive expanded-nh | match inet6.3
::ffff:192.168.0.12/128 Originating RIB: inet6.3
::ffff:192.168.0.13/128 Originating RIB: junos-rti-tc-131.inet6.3
::ffff:192.168.0.14/128 Originating RIB: inet6.3
The IPv6 traffic destined for the CE22 LAN traverses the nodes defined in the PE11 to PE13 LSP, with the label stack being reduced as it passes through the LSP nodes.
This SR-TE LSP will have color 132 from PE11 to PE14. It uses a dynamic path through OSPF areas, with DELAY as the metric type. The LSP route will be added to the 132 transport class routing table, which will be used to resolve BGP PNH for routes with the same color community. A compute profile enables the ingress PE to calculate the LSP's dynamic path based on the constraints defined in this profile. In this case, we're using a DELAY metric-type constraint.
We will use this LSP exclusively for IPv4 traffic from PE11 to PE14. By leveraging color LSPs and color communities, we can apply distinct constraints for IPv4 and IPv6 traffic, enabling separate dynamic path calculations for each.
policy-options {
community color:0:132 members color:0:132;
}
routing-options {
route-distinguisher-id 192.168.0.13;
resolution {
preserve-nexthop-hierarchy;
}
transport-class {
name 132 {
color 132;
}
}
}
protocols {
source-packet-routing {
compute-profile TO_PE12_DELAY_METRIC {
no-label-stack-compression;
metric-type {
delay;
}
}
source-routing-path PE13_to_PE12_COLOR_132 {
to 192.168.0.12;
color 132;
primary {
TO_PE12_DELAY_METRIC {
compute {
TO_PE12_DELAY_METRIC;
}
}
}
}
use-transport-class;
}
}
We will configure a delay link metric among all PEs and Ps, as shown below for P1 and marked with a red number in This delay link metric is configured statically and included as a metric in the TE-link within TED. Additionally, the delay link can be measured dynamically using TWAMP-Light and reported to TED for path calculation.
jnpr@MX304-PE11# run show spring-traffic-engineering lsp
To State LSPname
192.168.0.13-130<c> Up PE11_to_PE13_COLOR_130
192.168.0.13-131<c> Up PE11_to_PE13_COLOR_131
192.168.0.14-132<c> Up PE11_to_PE14_COLOR_132
jnpr@MX304-PE11# run show spring-traffic-engineering lsp detail | no-more
Name: PE11_to_PE14_COLOR_132
Tunnel-source: Static configuration
Tunnel Forward Type: SRMPLS
To: 192.168.0.14-132<c>
State: Up
Path: TO_PE14_DELAY_METRIC
Compute Status:Enabled , Compute Result:success , Compute-Profile Name:TO_PE14_DELAY_METRIC
Total number of computed paths: 1
TE metric: 30, IGP metric: 30
Delay metrics: Min: 3, Max: 3, Avg: 3
Metric optimized by type: Minimum-Delay
computed segments count: 3
computed segment : 1 (computed-adjacency-segment):
label: 18
source router-id: 192.168.0.11, destination router-id: 192.168.0.2
source interface-address: 192.168.10.2, destination interface-address: 192.168.10.1
computed segment : 2 (computed-adjacency-segment):
label: 26
source router-id: 192.168.0.2, destination router-id: 192.168.0.3
source interface-address: 192.168.5.1, destination interface-address: 192.168.5.2
computed segment : 3 (computed-adjacency-segment):
label: 17
source router-id: 192.168.0.3, destination router-id: 192.168.0.14
source interface-address: 192.168.12.1, destination interface-address: 192.168.12.2
This LSP's path goes from PE11 to P2, P3, and PE14. The first adjacency label, "18", represents the interface from PE11 to P2. This label is not pushed into the label stack; instead, it is used to determine the outgoing interface. The second adjacency label, "26", is the top label, meaning that when P2 receives this label, it is popped, and traffic is forwarded to P3 via the P2 to P3 link. The last transport adjacency label, "17", is advertised from P3 to P2, and when P3 receives this label, it pops the label and forwards traffic to PE14 via the P3 to PE14 link. The final label, "18", in the stack is the VRF service label, which is advertised from PE14 to the RR.
Our LSP is programmed into junos-rti-tc-132.inet.3 and junos-rti-tc-132.inet6.3 for IPv4 and IPv6 destinations, respectively, as SPRING-TE with a protocol preference of 8. The label stack displays the labels pushed into packets for this LSP.
jnpr@MX304-PE11# run show route table junos-rti-tc-132.inet.3 | no-more
junos-rti-tc-132.inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.0.14/32 *[SPRING-TE/8] 00:05:59, metric 1, metric2 30
> to 192.168.10.1 via et-0/0/3.0, Push 17, Push 26(top)
IPv4 BGP routes tagged with the 132 color community will resolve PNH in transport class instance 132. If no route is available to resolve PNH within this instance, the routes will fall back to the inet.3 table.
In our topology, we will map PE14's IPv4 "Purple" VRF traffic from PE11 to PE14 into this LSP.
As shown below, we define the color community with a value of 132. On the egress PE (in this case, PE14), IPv4 "Purple" VRF traffic will be tagged with this community via a policy statement attached as an export to this VRF.
policy-options {
policy-statement VRF_PURPLE_IPv4_COLOR_132 {
term 1 {
from family inet;
then {
community add color:0:132;
community add target:65511:100;
accept;
}
}
}
community color:0:132 members color:0:132;
community target:65511:100 members target:65511:100;
}
routing-instances {
VRF_PURPLE {
instance-type vrf;
vrf-export VRF_PURPLE_IPv4_COLOR_132;
}
}
PE14 IPv4 "Purple" VRF routes are received within color community 132. Below is the label stack for these IPv4 routes.
jnpr@MX304-PE11# run show route table VRF_PURPLE.inet.0 10.13/16 extensive expanded-nh | match inet.3
192.168.0.12/32 Originating RIB: inet.3
192.168.0.13/32 Originating RIB: inet.3
192.168.0.14/32 Originating RIB: junos-rti-tc-132.inet.3
The IPv4 traffic destined for the CE24 LAN traverses the nodes defined in the PE11 to PE14 LSP, with the label stack being reduced as it passes through the LSP nodes.
jnpr@MX304-PE11# run traceroute routing-instance VRF_PURPLE 10.13.4.1
traceroute to 10.13.4.1 (10.13.4.1), 30 hops max, 52 byte packets
1 192.168.5.1 (192.168.5.1) 1.177 ms 0.746 ms 0.726 ms
MPLS Label=26 CoS=0 TTL=1 S=0
MPLS Label=17 CoS=0 TTL=1 S=0
MPLS Label=18 CoS=0 TTL=1 S=1
2 192.168.12.1 (192.168.12.1) 0.848 ms 0.886 ms 0.732 ms
MPLS Label=17 CoS=0 TTL=1 S=0
MPLS Label=18 CoS=0 TTL=2 S=1
3 10.13.4.1 (10.13.4.1) 4.383 ms 4.874 ms 5.008 ms
4 10.13.4.1 (10.13.4.1) 5.009 ms 4.924 ms 4.965 m
SR-TE LSP with DELAY Metric and Admin Groups CSPF¶
Our last SR-TE LSP will have color 133 from PE11 to PE14. This LSP will use a dynamic path through OSPF areas, with DELAY as the metric type and Admin Groups as additional constraints. The LSP route will be added to the 133 transport class' routing table, and this table will be used to resolve BGP PNH for routes tagged with the same community color. A compute profile enables the ingress PE to calculate the LSP's dynamic path based on the constraints defined in this profile, which in this case includes DELAY and Admin Groups constraints.
This LSP will be used exclusively for IPv6 traffic from PE11 to PE14. By utilizing color LSPs and color communities, we can apply different constraints for IPv4 and IPv6 traffic, allowing for separate dynamic path calculations.
We will use the Delay link metric, which has been configured across all PEs and Ps for the previous LSP. Additionally, we will configure a common "BLUE" Admin Group in all routers. The P1 and P4 link, as well as the P2 and P3 link, will be marked with the "BLUE" Admin Group. See the P1 configuration below.
This delay link metric is configured statically, but it can also be measured dynamically using TWAMP-Light and reported to TED for path calculation.
jnpr@MX304-PE11# run show spring-traffic-engineering lsp
To State LSPname
192.168.0.13-130<c> Up PE11_to_PE13_COLOR_130
192.168.0.13-131<c> Up PE11_to_PE13_COLOR_131
192.168.0.14-132<c> Up PE11_to_PE14_COLOR_132
192.168.0.14-133<c> Up PE11_to_PE14_COLOR_133
jnpr@MX304-PE11# run show spring-traffic-engineering lsp detail | no-more
Name: PE11_to_PE14_COLOR_133
Tunnel-source: Static configuration
Tunnel Forward Type: SRMPLS
To: 192.168.0.14-133<c>
State: Up
Path: TO_PE14_ADMIN_GROUP
Compute Status:Enabled , Compute Result:success , Compute-Profile Name:TO_PE14_ADMIN_GROUP
Total number of computed paths: 2
Computed-path-index: 2
TE metric: 120, IGP metric: 30
Delay metrics: Min: 12, Max: 12, Avg: 12
Metric optimized by type: Minimum-Delay
computed segments count: 3
computed segment : 1 (computed-adjacency-segment):
label: 18
source router-id: 192.168.0.11, destination router-id: 192.168.0.1
source interface-address: 192.168.7.2, destination interface-address: 192.168.7.1
computed segment : 2 (computed-adjacency-segment):
label: 26
source router-id: 192.168.0.1, destination router-id: 192.168.0.3
source interface-address: 192.168.1.1, destination interface-address: 192.168.1.2
computed segment : 3 (computed-adjacency-segment):
label: 17
source router-id: 192.168.0.3, destination router-id: 192.168.0.14
source interface-address: 192.168.12.1, destination interface-address: 192.168.12.2
The above LSP's path goes from PE11 to P1, P3, and PE14. The first adjacency label, "18", represents the interface from PE11 to P1. This label is not pushed into the label stack; instead, it is used to determine the outgoing interface. The second adjacency label, "26", is the top label. When P1 receives this label, it pops the label and sends traffic to P3 via the P1 to P3 link. The final transport adjacency label, "17", is the label advertised from P3 to P1. When P3 receives this label, it pops the label and forwards traffic to PE14 via the P3 to PE14 link. The last label in the stack, "18", is the VRF service label advertised from PE14 to the Route Reflector (RR).
Our LSP is programmed into junos-rti-tc-133.inet.3 and junos-rti-tc-133.inet6.3 for IPv4 and IPv6 destinations, respectively, as SPRING-TE with a protocol preference of 8. The label stack illustrates the labels that are pushed into packets for this LSP.
jnpr@MX304-PE11# run show route table junos-rti-tc-133.inet6.3 | no-more
junos-rti-tc-133.inet6.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
::ffff:192.168.0.14/128
*[SPRING-TE/8] 00:09:30, metric 1, metric2 30
> to 192.168.10.1 via et-0/0/3.0, Push 23, Push 18(top)
to 192.168.7.1 via et-0/0/1.0, Push 17, Push 26(top)
IPv6 BGP routes tagged with the 133 color community will resolve PNH in transport class instance 133. If there is no route available to resolve PNH in this instance, the routes will fall back to the inet.3 table.
In our topology, we will map PE14's IPv6 "Purple" VRF traffic from PE11 to PE14 into this LSP.
As shown below, we define the color community with a 133 color value. At the egress PE (in this case, PE14), IPv6 "Purple" VRF traffic will be tagged with this community through a policy statement attached as an export to this VRF.
policy-options {
policy-statement VRF_PURPLE_IPv6_COLOR_133 {
term 1 {
from family inet6;
then {
community add target:65511:100;
community add color:0:133;
accept;
}
}
}
community color:0:133 members color:0:133;
community target:65511:100 members target:65511:100;
}
routing-instances {
VRF_PURPLE {
instance-type vrf;
vrf-export [ VRF_PURPLE_IPv4_COLOR_132 VRF_PURPLE_IPv6_COLOR_133 ];
}
}
PE14 IPv6 "Purple" VRF routes are received within the color community 133. Below label stack stack for these IPv6 routes.
jnpr@MX304-PE11# run show route table VRF_PURPLE.inet6.0 2001:10:13::/48 extensive expanded-nh | match inet6.3
::ffff:192.168.0.12/128 Originating RIB: inet6.3
::ffff:192.168.0.13/128 Originating RIB: inet6.3
::ffff:192.168.0.14/128 Originating RIB: junos-rti-tc-133.inet6.3
The IPv6 traffic destined for the CE24 LAN traverses the nodes defined in the PE11 to PE14 LSP, with the label stack being reduced as it passes through the LSP nodes.
SR-TE (CSPF) LSPs can calculate their dynamic paths across a multi-domain network. Ingress PEs need to have TE information from other areas or levels, and BGP-LS facilitates the distribution of TE across these areas or levels. Additionally, Juniper Paragon PCE Initiated can compute SR-TE LSPs across a multi-domain network from a central point.
Thanks to Nicolas Fevrier for the opportunity and guidance in writing this tech post. A special thanks to Dirk van den Borne for encouraging me to create it, and to Colby Barth, Anton Elita, and Aris Georgakas for their insightful reviews and valuable comments. I would also like to express my gratitude to Jose Rosa, Octavio Leonel, Ricardo Lopez, and Alberto Cruz for their unwavering support and for providing the resources to set up this lab.
