Segment Routing LSP Configuration
Enabling Distributed CSPF for Segment Routing LSPs
Prior to Junos OS Release 19.2R1S1, for traffic engineering of segment routing paths, you could either explicitly configure static paths, or use computed paths from an external controller. With the distributed Constrained Shortest Path First (CSPF) for segment routing LSP feature, you can compute a segment routing LSP locally on the ingress device according to the constraints you have configured. With this feature, the LSPs are optimized based on the configured constraints and metric type (traffic-engineering or IGP). The LSPs are computed to utilize the available ECMP paths to the destination with segment routing label stack compression enabled or disabled.
- Distributed CSPF Computation Constraints
- Distributed CSPF Computation Algorithm
- Distributed CSPF Computation Database
- Configuring Distributed CSPF Computation Constraints
- Distributed CSPF Computation
- Interaction Between Distributed CSPF Computation and SR-TE Features
- Distributed CSPF Computation Sample Configurations
Distributed CSPF Computation Constraints
Segment routing LSP paths are computed when all the configured constraints are met.
The distributed CSPF computation feature supports the following subset of constraints specified in the Internet draft, draft-ietf-spring-segment-routing-policy-03.txt, Segment Routing Policy for Traffic Engineering:
-
Inclusion and exclusion of administrative groups.
-
Inclusion of loose or strict hop IP addresses.
Note:You can specify only router IDs in the loose or strict hop constraints. Labels and other IP addresses cannot be specified as loose or strict hop constraints in Junos OS Release 19.2R1-S1.
-
Maximum number of segment IDs (SIDs) in the segment list.
-
Maximum number of segment lists per candidate segment routing path.
The distributed CSPF computation feature for segment routing LSPs does not support the following types of constraints and deployment scenarios:
-
IPV6 addresses.
-
Inter domain segment routing traffic engineering (SR-TE) LSPs.
-
Unnumbered interfaces.
-
Multiple protocols routing protocols such as, OSPF, ISIS, and BGP-LS, enabled at the same time.
-
Computation with prefixes or anycast addresses as destinations.
-
Including and excluding interface IP addresses as constraints.
Distributed CSPF Computation Algorithm
The distributed CSPF computation feature for segment routing LSPs uses the label stack compression algorithm with CSPF.
Label Stack Compression Enabled
A compressed label stack represents a set of paths from a source to a destination. It generally consists of node SIDs and adjacency SIDs. When label stack compression is enabled, the result of the computation is a set of paths that maximize ECMP to the destination, with minimum number of SIDs in the stack, while conforming to constraints.
Label Stack Compression Disabled
The multipath CSPF computation with label stack compression disabled finds up to N segment lists to destination, where:
-
The cost of all segment lists is equal to and the same as the shortest traffic-engineering metric to reach the destination.
-
Each segment list is comprised of adjacency SIDs.
-
The value of N is the maximum number of segment lists allowed for the candidate path by configuration.
-
No two segment lists are identical.
-
Each segment list satisfies all the configured constraints.
Distributed CSPF Computation Database
The database used for
SR-TE
computation has all links, nodes, prefixes and their characteristics irrespective of
whether traffic-engineering is enabled in those advertising nodes. In other words,
it is the union of the traffic-engineering database (TED) and the IGP link state
database of all domains that the computing node has learnt from. As a result, for
CSPF to work, you must include the igp-topology statement at the
[edit protocols isis traffic-engineering] hierarchy level.
Configuring Distributed CSPF Computation Constraints
You can use a compute profile to logically group the computation constraints. These compute profiles are referenced by the segment routing paths for computing the primary and secondary segment routing LSPs.
To configure a compute profile, include the compute-profile statement at the [edit protocols
source-packet-routing] hierarchy level.
The configuration for the supported computation constraints include:
-
Administrative groups
You can configure admin-groups under the
[edit protocols mpls]hierarchy level. Junos OS applies the administrative group configuration to the segment routing traffic-engineering (SR-TE) interfaces.To configure the computation constraints you can specify three categories for a set of administrative groups. The computation constraint configuration can be common to all candidate segment routing paths, or it can be under individual candidate paths.
-
include-any—Specifies that any link with at least one of the configured administrative groups in the list is acceptable for the path to traverse. -
include-all—Specifies that any link with all of the configured administrative groups in the list is acceptable for the path to traverse. -
exclude—Specifies that any link which does not have any of the configured administrative groups in the list is acceptable for the path to traverse.
-
-
Explicit path
You can specify a series of router IDs in the compute profile as a constraint for computing the SR-TE candidate paths. Each hop has to be an IPv4 address and can be of type strict or loose. If the type of a hop is not configured, strict is used. You must include the
computeoption under the segment-list statement when specifying the explicit path constraint. -
Maximum number of segment lists (ECMP paths)
You can associate a candidate path with a number of dynamic segment-lists. The paths are ECMP paths, where each segment-list translates into a next hop gateway with active weight. These paths are a result of path computation with or without compression.
You can configure this attribute using the
maximum-computed-segment-lists maximum-computed-segment-listsoption under the compute-profile configuration statement. This configuration determines the maximum number of such segment lists computed for a given primary and secondary LSP. -
Maximum segment list depth
The maximum segment list depth computation parameter ensures that amongst the ECMP paths that satisfy all other constraints such as administrative group, only the paths that have segment lists less than or equal to the maximum segment list depth are used. When you configure this parameter as a constraint under the compute-profile, it overrides the
maximum-segment-list-depthconfiguration under the[edit protocols source-packet-routing]hierarchy level, if present.You can configure this attribute using the
maximum-segment-list-depth maximum-segment-list-depthoption under the compute-profile configuration statement. -
Protected or unprotected adjacency SIDs
You can configure protected or unprotected adjacency SID as a constraint under the compute-profile to avoid links with the specified SID type.
-
Metric type
You can specify the type of metric on the link to be used for computation. By default, SR-TE LSPs use traffic-engineering metrics of the links for computation. The traffic-engineering metric for links is advertised by traffic-engineering extensions of IGP protocols. However, you may also choose to use the IGP-metric for computation by using the metric-type configuration in the compute profile.
You can configure this attribute using the
metric-type (igp | te)option under the compute-profile configuration statement.
Distributed CSPF Computation
The SR-TE candidate paths are computed locally such that they satisfy the configured constraints. When label stack compression is disabled, the multi-path CSPF computation result is a set of adjacency SID stacks. When label stack compression is enabled, the result is a set of compressed label stacks (composed of adjacent SIDs and node SIDs).
When secondary paths are computed, the links, nodes and SRLGs taken by the primary paths are not avoided for computation. For more information on primary and secondary paths, see Configuring Primary and Secondary LSPs.
For any LSPs with unsuccessful computation result, the computation is retried as traffic-engineering database (TED) changes.
Interaction Between Distributed CSPF Computation and SR-TE Features
- Weights Associated With Paths of an SR-TE Policy
- BFD Liveliness Detection
- inherit-label-nexthops
- Auto-Translate Feature
Weights Associated With Paths of an SR-TE Policy
You can configure weights against computed and static SR-TE paths, which contribute to the next hops of the route. However, a single path that has computation enabled can result in multiple segment lists. These computed segment lists are treated as ECMP amongst themselves. You can assign hierarchical ECMP weights to these segments, considering the weights assigned to each of the configured primaries.
BFD Liveliness Detection
You can configure BFD liveliness detection for the computed primary or secondary paths. Every computed primary or secondary path can result in multiple segment lists, as a result, the BFD parameters configured against the segment lists are applied to all the computed segment lists. If all the active primary paths go down, the pre-programmed secondary path (if provided) becomes active.
inherit-label-nexthops
You are not required to explicitly enable the
inherit-label-nexthops configuration under the
[edit protocols source-packet-routing segment-list
segment-list-name] hierarchy for the computed
primary or secondary paths, as it is a default behavior.
Auto-Translate Feature
You can configure the auto-translate feature on the segment lists, and the primary or secondary paths with the auto-translate feature reference these segment lists. On the other hand, the primary or secondary on which compute feature is enabled cannot reference any segment list. As a result, you cannot enable both the compute feature and the auto-translate feature for a given primary or secondary path. However, you could have an LSP configured with a primary path with compute type and another with auto-translate type.
Distributed CSPF Computation Sample Configurations
Example 1
In Example 1,
-
The non-computed primary path references a configured segment-list. In this example, the configured segment list static_sl1 is referenced, and it also serves as the name for this primary path.
-
A computed primary should have a name configured, and this name should not reference any configured segment list. In this example, compute_segment1 is not a configured segment list.
-
The compute_profile_red compute-profile is applied to the primary path with the name compute_segment1.
-
The compute_profile_red compute-profile includes a segment list of type
compute, which is used to specify the explicit path constraint for the computation.
[edit protocols source-packet-routing]
segment-list static_sl1{
hop1 label 80000
}
segment-list exp_path1 {
hop1 ip-address 10.1.1.1 loose
hop2 ip-address 10.2.2.2
compute
}
compute-profile compute_profile_red {
include-any red
segment-list exp_path1
maximum-segment-list-depth 5
}
The weights for computed path next-hops and static next-hops are 2 and 3, respectively. Assuming the next-hops for computed paths are comp_nh1, comp_nh2, and comp_nh3, and the next-hop for static path is static_nh, the weights are applied as follows:
|
Next-Hop |
Weight |
|---|---|
|
comp_nh1 |
2 |
|
comp_nh2 |
2 |
|
comp_nh3 |
2 |
|
static_nh |
9 |
Example 2
In Example 2, both the primary and secondary paths can be of compute type and can have their own compute-profiles.
[edit protocols source-packet-routing]
compute-profile compute_profile_green{
include-any green
maximum-segment-list-depth 5
}
compute-profile compute_profile_red{
include-any red
maximum-segment-list-depth 8
}
Example 3
In Example 3, when compute is mentioned under a primary or secondary path, it results in local computation of a path to the destination without any constraints or other parameters for the computation.
[edit protocols source-packet-routing]
source-routing-path srte_colored_policy1 {
to 10.5.5.5
color 5
binding-sid 10001
primary {
compute_segment1 {
compute
}
}
}
Static Segment Routing Label Switched Path
The segment routing architecture enables the ingress devices in a core network to steer traffic through explicit paths. You can configure these paths using segment lists to define the paths that the incoming traffic should take. The incoming traffic may be labeled or IP traffic, causing the forwarding operation at the ingress device to be either a label swap, or a destination-based lookup.
- Understanding Static Segment Routing LSP in MPLS Networks
- Example: Configuring Static Segment Routing Label Switched Path
Understanding Static Segment Routing LSP in MPLS Networks
Source packet routing or segment routing is a control-plane architecture that enables an ingress router to steer a packet through a specific set of nodes and links in the network without relying on the intermediate nodes in the network to determine the actual path it should take.
- Introduction to Segment Routing LSPs
- Benefits of using Segment Routing LSPs
- Colored Static Segment Routing LSP
- Non-Colored Static Segment Routing LSP
- Static Segment Routing LSP Provisioning
- Static Segment Routing LSP Limitations
- Dynamic Creation of Segment Routing LSPs
- Color-Based Mapping of VPN Services
- Tunnel Templates for PCE-Initiated Segment Routing LSPs
Introduction to Segment Routing LSPs
Segment routing leverages the source routing paradigm. A device steers a packet through an ordered list of instructions, called segments. A segment can represent any instruction, topological or service-based. A segment can have a local semantic to a segment routing node or to a global node within a segment routing domain. Segment routing enforces a flow through any topological path and service chain while maintaining per-flow state only at the ingress device to the segment routing domain. Segment routing can be directly applied to the MPLS architecture with no change on the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack.
Segment routing LSPs can either be dynamic or static in nature.
|
Dynamic segment routing LSPs—When a segment routing LSP is created either by an external controller and downloaded to an ingress device through Path Computation Element Protocol (PCEP) extensions, or from a BGP segment routing policy through BGP segment routing extensions, the LSP is dynamically provisioned. The segment list of the dynamic segment routing LSP is contained in the PCEP Explicit Route Object (ERO), or the BGP segment routing policy of the LSP. |
|
Static segment routing LSPs—When a segment routing LSP is created on the ingress device through local configuration, the LSP is statically provisioned. A static segment routing LSP can further be classified as colored
and non-colored LSPs based on the configuration of the
For example: [edit protocols]
source-packet-routing {
source-routing-path lsp_name {
to destination_address;
color color_value;
binding-sid binding-label;
primary segment_list_1_name weight weight;
...
primary segment_list_n_name weight weight;
secondary segment_list_n_name;
sr-preference sr_preference_value;
}
}
Here, each primary and secondary statement refers to a segment list. [edit protocols]
source-packet-routing {
segment-list segment_list_name {
hop_1_name label sid_label;
...
hop_n_name label sid_label;
}
}
|
Benefits of using Segment Routing LSPs
-
Static segment routing does not rely on per LSP forwarding state on transit routers. Hence, removing the need of provisioning and maintaining per LSP forwarding state in the core.
-
Provide higher scalability to MPLS networks.
Colored Static Segment Routing LSP
A static segment routing LSP configured with the color statement is
called a colored LSP.
Understanding Colored Static Segment Routing LSPs
Similar to a BGP segment routing policy, the ingress route of the colored LSP is
installed in the inetcolor.0 or inet6color.0
routing tables, with destination-ip-address, color as key for
mapping IP traffic.
A static colored segment routing LSP may have a binding SID, for which a route is
installed in the mpls.0 routing table. This binding SID label
is used to map labeled traffic to the segment routing LSP. The gateways of the
route are derived from the segment list configurations under the primary and
secondary paths.
Segment List of Colored Segment Routing LSPs
The colored static segment routing LSPs already provide support for first hop label mode of resolving an LSP. However, first hop IP mode is not supported for colored segment routing LSPs. Starting in Junos OS Release 19.1R1, a commit check feature is introduced to ensure that all the segment lists contributing to the colored routes have the minimum label present for all hops. If this requirement is not met, the commit is blocked.
Non-Colored Static Segment Routing LSP
A static segment routing LSP that is configured without the color
statement is a non-colored LSP. Similar to PCEP segment routing tunnels, the ingress
route is installed in the inet.3 or inet6.3
routing tables.
Junos OS supports non-colored static segment routing LSPs on ingress routers. You can provision non-colored static segment routing LSP by configuring one source routed path and one or more segment lists. These segment lists can be used by multiple non-colored segment routing LSPs.
Understanding Non-Colored Segment Routing LSPs
The non-colored segment routing LSP has a unique name and a destination IP address. An ingress route to the destination is installed in the inet.3 routing table with a default preference of 8 and a metric of 1. This route allows non-colored services to be mapped to the segment routing LSP pertaining to the destination. In case the non-colored segment routing LSP does not require an ingress route then the ingress route can be disabled. A non-colored segment routing LSP uses binding SID label to achieve segment routing LSP stitching. This label that can be used to model the segment routing LSP as a segment that may be further used to construct other segment routing LSPs in a hierarchical manner. The transit of the binding SID label, by default, has a preference of 8 and a metric of 1.
Starting in Junos OS Release 18.2R1, statically configured non-colored segment routing LSPs on the ingress device are reported to the Path Computation Element (PCE) through a Path Computation Element Protocol (PCEP) session. These non-colored segment routing LSPs may have binding service identifier (SID) labels associated with them. With this feature, the PCE can use this binding SID label in the label stack to provision PCE-initiated segment routing LSP paths.
A non-colored segment routing LSP can have a maximum of 8 primary paths. If there
are multiple operational primary paths then the packet forwarding engine (PFE)
distributes traffic over the paths based on the load balancing factors like the
weight configured on the path. This is equal cost multi path (ECMP) if none of
the paths have a weight configured on them or weighted ECMP if at least one of
the paths has a non-zero weight configured on the paths. In both the cases, when
one or some of the paths fail, the PFE rebalances the traffic over the remaining
paths that automatically leads to achieving path protection. A non-colored
segment routing LSP can have a secondary path for dedicated path protection.
Upon failure of a primary path, the PFE rebalances the traffic to the remaining
functional primary paths. Otherwise, the PFE switches the traffic to the backup
path, hence achieving path protection. A non-colored segment routing LSP may
specify a metric at [edit protocols source-packet-routing
source-routing-path lsp-name] for its ingress
and binding-SID routes. Multiple non-colored segment routing LSPs have the same
destination address that contribute to the next hop of the ingress route.
Multiple non-colored segment routing LSPs have the same destination address that contribute to the next hop of the ingress route. Each path ,either primary or secondary, of each segment routing LSP is considered as a gateway candidate, if the path is functional and the segment routing LSP has the best preference of all these segment routing LSPs. However, the maximum number of gateways that the next-hop can hold cannot exceed the RPD multi-path limit, which is 128 by default. Extra paths are pruned, firstly secondary paths and then primary paths. A given segment list may be referred multiple times as primary or secondary paths by these segment routing LSPs. In this case, there are multiple gateways, each having a unique segment routing LSP tunnel ID. These gateways are distinct, although they have identical outgoing label stack and interface. A non-colored segment routing LSP and a colored segment routing LSP may also have the same destination address. However, they correspond to different destination addresses for ingress routes, as the colored segment routing LSP’s destination address is constructed with both its destination address and color.
In the case where a static non-colored segment routing LSP and a PCEP-created segment routing LSP co-exist and have the same to address that contributes to the same ingress route, if they also have the same preference. Otherwise, the segment routing LSP with the best preference is installed for the route.
Segment List of Non-Colored Segment Routing LSPs
A segment list consists of a list of hops. These hops are based on the SID label
or an IP address. The number of SID labels in the segment list should not exceed
the maximum segment list limit. Maximum segment-list binding to a LSP tunnel is
increased from 8 to 128, with maximum 1000 tunnels per system. A maximum of 128
primary paths are supported per static segment routing LSP. You can configure
the maximum segment list limit at the [edit protocols source-packet-routing] hierarchy level.
Prior to Junos OS Release 19.1R1, for a non-colored static segment routing LSP to be usable, the first hop of the segment list had to be an IP address of an outgoing interface and the second to nth hops could be SID labels. Starting in Junos OS Release 19.1R1, this requirement does not apply, as the first hop of the non-colored static LSPs now provides support for SID labels, in addition to IP addresses. With the first hop label support, MPLS fast reroute (FRR) and weighted equal-cost multipath is enabled for resolving the static non-colored segment routing LSPs, similar to colored static LSPs.
For the first-hop label mode to take effect, you must include the
inherit-label-nexthops statement globally or individually
for a segment list, and the first hop of the segment list must include both IP
address and label. If the first hop includes only IP address, the
inherit-label-nexthops statement does not have any
effect.
You can configure inherit-label-nexthops at any one of the
following hierarchies. The inherit-label-nexthops statement
takes effect only if the segment list first hop includes both IP address and
label.
-
Segment list level—At the
[edit protocols source-packet-routing segment-list segment-list-name]hierarchy level. -
Globally—At the
[edit protocols source-packet-routing]hierarchy level.
When the inherit-label-nexthops statement is configured
globally, it takes precedence over the segment-list level configuration, and the
inherit-label-nexthops configuration is applied to all the
segment lists. When the inherit-label-nexthops statement is not
configured globally, only segment lists with both labels and IP address present
in the first hop, and configured with inherit-label-nexthops
statement are resolved using SID labels.
For dynamic non-colored static LSPs, that is the PCEP-driven segment routing
LSPs, the inherit-label-nexthops statement must be enabled
globally, as the segment-level configuration is not applied.
Table 1 describes the mode of segment routing LSP resolution based on the first hop specification.
|
First Hop Specification |
Mode of LSP Resolution |
|---|---|
|
IP address only For example: segment-list path-1 {
hop-1 ip-address 172.16.12.2;
hop-2 label 1000012;
hop-3 label 1000013;
hop-4 label 1000014;
}
|
The segment list is resolved using the IP address. |
|
SID only For example: segment-list path-2 {
hop-1 label 1000011;
hop-2 label 1000012;
hop-3 label 1000013;
hop-4 label 1000014;
}
|
The segment list is resolved using SID labels. |
|
IP address and SID (without the
For example: segment-list path-3 {
hop1 {
label 801006;
ip-address 172.16.1.2;
}
hop-2 label 1000012;
hop-3 label 1000013;
hop-4 label 1000014;
}
|
By default, the segment list is resolved using IP address. |
|
IP address and SID (with the
For example: segment-list path-3 {
inherit-label-nexthops;
hop1 {
label 801006;
ip-address 172.16.1.2;
}
hop-2 label 1000012;
hop-3 label 1000013;
hop-4 label 1000014;
}
|
The segment list is resolved using SID labels. |
You can use the show route ip-address protocol
spring-te active-path table inet.3 command to view the non-colored
segment routing traffic-engineered LSPs having multiple segment lists installed
in the inet.3 routing table.
For example:
user@host> show route 10.7.7.7 protocol spring-te active-path table inet.3
inet.3: 42 destinations, 59 routes (41 active, 0 holddown, 1 hidden)
+ = Active Route, - = Last Active, * = Both
10.7.7.7/32 *[SPRING-TE/8] 00:01:25, metric 1, metric2 0
> to 10.11.1.2 via et-0/0/0.1, Push 801007
to 10.21.1.2 via et-0/0/2.1, Push 801007
to 10.102.1.2 via et-0/0/0.2, Push 801007, Push 801002(top)
to 10.21.1.2 via et-0/0/2.2, Push 801007, Push 801005(top)
to 10.103.1.2 via et-0/0/0.3, Push 801007, Push 801003(top)
to 10.203.1.2 via et-0/0/2.3, Push 801007, Push 801006(top)
to 10.104.1.2 via et-0/0/0.4, Push 801007, Push 801003, Push 801002(top)
to 10.204.1.2 via et-0/0/2.4, Push 801007, Push 801006, Push 801005(top)
The first hop type of segment lists of a static segment routing LSP can cause a commit to fail, if:
-
Different segment lists of a tunnel have different first hop resolution types. This is applicable to both colored and non-colored static segment routing LSPs. However, this does not apply for PCEP-driven LSPs; a system log message is generated for the mismatch in the first hop resolution type at the time of computing the path.
For example:
segment-list path-1 { hop-1 ip-address 172.16.12.2; hop-2 label 1000012; hop-3 label 1000013; hop-4 label 1000014; } segment-list path-2 { hop-1 label 1000011; hop-2 label 1000012; hop-3 label 1000013; hop-4 label 1000014; } source-routing-path lsp1 { to 172.16.10.1; primary { path-1; path-2; } }The commit of tunnel lsp1 fails, as path-1 is of IP address mode and path-2 is of label mode.
-
The binding SID is enabled for the static non-colored LSP whose segment list type is SID label.
For example:
segment-list path-3 { hop-1 label 1000011; hop-2 label 1000012; hop-3 label 1000013; hop-4 label 1000014; } source-routing-path lsp1 { to 172.16.10.1; binding-sid 333; primary { path-3; } }Configuring binding SID over label segment list is supported only for colored static LSPs and not for no-colored static LSPs.
Static Segment Routing LSP Provisioning
Segment provisioning is performed on per-router basis. For a given segment on a router, a unique service identifier (SID) label is allocated from a desired label pool which may be from the dynamic label pool for an adjacency SID label or from the segment routing global block (SRGB) for a prefix SID or node SID. The adjacency SID label can be dynamically allocated, which is the default behavior, or be allocated from a local static label pool (SRLB). A route for the SID label is then installed in the mpls.0 table.
Junos OS allows static segment routing LSPs by configuring the
segment statement at the [edit protocols mpls
static-label-switched-path
static-label-switched-path] hierarchy level. A
static segment LSP is identified by a unique SID label that falls under Junos OS
static label pool. You can configure the Junos OS static label pool by configuring
the static-label-range static-label-range
statement at the [edit protocols mpls label-range] hierarchy level.
Static Segment Routing LSP Limitations
-
Junos OS currently has a limitation that the next hop cannot be built to push more than the maximum segment list depth labels. So, a segment list with more than the maximum SID labels (excluding the SID label of the first hop which is used to resolve forwarding next-hop) is not usable for colored or non-colored segment routing LSPs. Also, the actual number allowed for a given segment routing LSP may be even lower than the maximum limit, if an MPLS service is on the segment routing LSP or the segment routing LSP is on a link or a node protection path. In all cases, the total number of service labels, SID labels, and link or node protection labels must not exceed the maximum segment list depth. You can configure the maximum segment list limit at
[edit protocols source-packet-routing]hierarchy level. Multiple non-colored segment routing LSPs with less than or equal to the maximum SID labels can be stitched together to construct a longer segment routing LSP. This is called segment routing LSP stitching. It can be achieved using binding-SID label. -
The segment routing LSP stitching is actually performed at path level. If a non-colored segment routing LSP has multiple paths that is multiple segment lists, each path can be independently stitched to another non-colored segment routing LSP at a stitching point. A non-colored segment routing LSP which is dedicated to stitching may disable ingress route installation by configuring
no-ingressstatement at[edit protocols source-packet-routing source-routing-path lsp-name]hierarchy level. -
A maximum of 128 primary paths and 1 secondary path are supported per non-colored static segment routing LSP. If there is a violation in configuration, commit check fails with an error.
-
Maximum segment-list binding to a LSP tunnel is increased from 8 to 128, with maximum 1000 tunnels per system. A maximum of 128 primary paths are supported per static segment routing LSP. As a limitation, the maximum sensor support for LSP path is 32000 only.
-
If any segment-list is configured with more labels than the maximum segment list depth, the configuration commit check fails with an error.
Dynamic Creation of Segment Routing LSPs
In segment routing networks that have each provider edge (PE) device connected to every other PE device, a large amount of configuration is required for setting up the segment routing label-switched paths (LSPs), although only a few segment routing traffic-engineered (SR-TE) paths may be used. You can enable BGP-trigerred dynamic creation of these LSPs to reduce the amount of configuration in such deployments.
- Configuring Dynamic Segment Routing LSP Template
- Resolving Dynamic Segment Routing LSPs
- Considerations for Configuring Dynamic Creation of Segment Routing LSPs
- Services Supported over Dynamic Segment Routing LSPs
- Behavior With Multiple Tunnel Sources in Segment Routing
- Dynamic Segment Routing LSPs Limitations
Configuring Dynamic Segment Routing LSP Template
To configure the template for enabling dynamic creation of segment routing LSPs,
you must include the spring-te statement at the [edit routing-options
dynamic-tunnels] hierarchy.
-
The following is a sample configuration for color dynamic segment routing LSP template:
[edit routing-options] dynamic-tunnels { <dynamic-tunnel-name> { spring-te { source-routing-path-template { <template-name1> color [c1 c2]; <template-name2> color [c3]; <template-name3> color-any; } destination-networks { <dest1>; <dest2>; } } } } -
The following is a sample configuration for non-color dynamic segment routing LSP template:
dynamic-tunnels { <dynamic-tunnel-name> { spring-te { source-routing-path-template { <template-name1>; } destination-networks { <dest1>; <dest2>; } } } }
Resolving Dynamic Segment Routing LSPs
Resolving Colored Dynamic Segment Routing LSP
When the BGP prefixes are assigned with color community, they initially get resolved over the catch-all-route-for-that–particular-color policy, and in turn, the SR-TE template on which the BGP prefix should be resolved onto is identified. The destinations SID is then derived from the BGP payload prefix next-hop attribute. For example, if the next hop of the BGP payload prefix is an IP address that belongs to Device A, then the node-SID of Device A is taken and a corresponding label is prepared and pushed to the bottom of the stack. The BGP payload prefix is resolved in a color-only mode, where the node-SID of Device A is at the bottom of the final label stack, and the SR-TE path labels are on top.
The final LSP template name is a combination of prefix, color, and tunnel
name; for example,
<prefix>:<color>:dt-srte-<tunnel-name>.
The color in the LSP name is displayed in hexadecimal format, and the
format of the tunnel name is similar to that o RSVP-triggered tunnel LSP
names.
To successfully resolve a colored destination network, the color should
have a valid template mapping, either to a specific color, or through
the color-any template. Without a valid mapping, the
tunnel is not created and the BGP route requesting for resolution
remains unresolved.
Resolving Uncolored Dynamic Segment Routing LSPs
The catch-all routes for non-colored LSPs are added to the inet.3 routing
table. The non-colored tunnel destination must be configured in a
different spring-te configuration with only one
template name in the mapping list. This template name is used for all
the tunnel routes matching any of the destination networks configured
under the same spring-te configuration. These tunnels
are similar to RSVP tunnels in functionality.
The final LSP template name is a combination of prefix and tunnel name;
for example,
<prefix>:dt-srte-<tunnel-name>.
Dynamic Segment Routing LSP Sample Configuration
The dynamic segment routing LSP template always carries a partial path. The last hop node SID is derived automatically at the tunnel creation time depending on the protocol next-hop address (PNH) node SID. The same template can be used by multiple tunnels to different destinations. In such cases, the partial path remains the same, and only the last hop changes depending on the PNH. Dynamic segment routing LSP templates are not common to a single tunnel, as a result a full path cannot be carried on it. You can use a segment list if a full path is to be used.
Colored Dynamic Segment Routing LSPs
Sample configuration for colored dynamic segment routing LSPs:
protocols source-packet-routing {
source-routing-path-template sr_lsp1 {
primary sr_sl1
primary sr_sl2 weight 2
sr-preference 180;
}
}
dynamic-tunnels tunnel1 {
spring-te {
source-routing-path-template {
sr_lsp1 color [101 124];
sr_lsp2 color-any
}
destination-networks {
10.22.44.0/24;
}
}
}
If BGP service PNH is 10.22.44.0/24 with color community
123/124/125, then it uses SR-TE template sr_lsp1 to create
tunnel. Any other color for same PNH prefix uses sr_lsp2
template due to color-any configuration.
For the above-mentioned sample configuration, the route entries are as follows:
-
inetcolor.0 tunnel route: 10.22.44.0-0/24 --> RT_NH_TUNNEL
-
inet6color.0 tunnel route: ffff::10.22.44.0-0/120 --> RT_NH_TUNNEL
-
BGP prefix to tunnel mapping:
R1(prefix) -> 10.22.44.55-101(PNH) LSP tunnel name = 10.22.44.55:65:dt-srte-tunnel1
R1(prefix) -> ffff::10.22.44.55-101(PNH) LSP tunnel name = 10.22.44.55:65:dt-srte-tunnel1
R1(prefix) -> ffff::10.22.44.55-124(PNH) LSP tunnel name = 10.22.44.55:7c:dt-srte-tunnel1
-
inetcolor.0 tunnel route:
10.22.44.55-101/64 --> <next-hop>
10.22.44.55-124/64 --> <next-hop>
-
inet6color.0 tunnel route:
ffff::10.22.44.55-101/160 --> <next-hop>
ffff::10.22.44.55-124/160 --> <next-hop>
The color 101 tunnel (10.22.44.55:65:dt-srte-tunnel1) is created
due to color-any configuration.
The IPv6 routes in inet6color.0 are due to mpls
ipv6-tunneling configuration. It allows IPv6 routes
with color community to be resolved over inet6color.0 table by
converting SR-TE routes stored in the inetcolor.0 routing table
to IPv4-mapped IPv6 addresses and then copying them into the
inet6color.0 routing table.
Non-Colored Dynamic Segment Routing LSPs
Sample configuration for non-colored dynamic segment routing LSPs:
protocols source-packet-routing {
source-routing-path-template sr_lsp1 {
primary sr_sl1
primary sr_sl2 weight 2
sr-preference 180;
}
}
dynamic-tunnels {
tunnel1 {
spring-te {
source-routing-path-template {
sr_lsp1 color 101;
}
destination-networks {
10.33.44.0/24;
}
}
}
tunnel2 {
spring-te {
source-routing-path-template {
sr_lsp1;
}
destination-networks {
10.33.44.0/24;
}
}
}
}
For the above-mentioned sample configuration, the route entries are as follows:
-
inet.3 tunnel route: 10.33.44.0/24 --> RT_NH_TUNNEL
-
inet6.3 tunnel route: ffff::10.33.44.0/120 --> RT_NH_TUNNEL
-
BGP prefix to tunnel mapping:
R1(prefix) -> 10.33.44.55(PNH) LSP template name = LSP1 --- 10.33.44.55:dt-srte-tunnel2
R1(prefix) -> ffff::10.33.44.55(PNH) LSP template name = LSP1 --- 10.33.44.55:dt-srte-tunnel2
-
inet.3 tunnel route: 10.33.44.55/32 --> <next-hop>
-
inet6.3 tunnel route: ffff::10.33.44.55/128 --> <next-hop>
The uncolored tunnel (10.33.44.55:dt-srte-tunnel2) is created
using dynamic-tunnel tunnel2 as it does not have color
configured. The IPv6 routes in inet6.3 are due to mpls
ipv6-tunneling configuration. It allows IPv6 routes
to be resolved over an MPLS network by converting SR-TE routes
stored in the inet.3 routing table to IPv4-mapped IPv6 addresses
and then copying them into the inet6.3 routing table.
Unresolved Dynamic Segment Routing LSP
Sample configuration for unresolved dynamic segment routing LSPs:
protocols source-packet-routing {
source-routing-path-template sr_lsp1 {
primary sr_sl1
primary sr_sl2 weight 2
sr-preference 180;
}
}
dynamic-tunnels tunnel1 {
spring-te {
source-routing-path-template {
sr_lsp1 color [120 121 122 123];
}
destination-networks {
10.33.44.0/24;
10.1.1.0/24;
}
}
}
For the above-mentioned sample configuration, the route entries are as follows:
-
inetcolor.0 tunnel route: 10.33.44.0 - 0/24 --> RT_NH_TUNNEL 10.1.1.0 - 0 /24 --> RT_NH_TUNNEL
-
inet6color.0 tunnel route: ffff::10.33.44.0 - 0/120 --> RT_NH_TUNNEL ffff::10.1.1.0 - 0 /24 --> RT_NH_TUNNEL
-
BGP prefix to tunnel mapping: R1(prefix) -> 10.33.44.55-124(PNH) Tunnel is not created. (Template not found for the color).
Considerations for Configuring Dynamic Creation of Segment Routing LSPs
When configuring the dynamic creation of segment routing LSPs, take the following into consideration:
-
A template can be assigned with a color object. When the dynamic tunnel
spring-teconfiguration includes a template with a color object, you must configure all other templates with color objects as well. All destinations are assumed to be colored within that configuration. -
A template can have a list of colors defined on it, or can be configured with the
color-anyoption. Both these options can coexist in the samespring-teconfiguration. In such cases, templates assigned with specific colors have a higher preference. -
In a
spring-teconfiguration, only one template can be defined with thecolor-anyoption. -
The color-to-template mapping is done on a one-to-one basis. One color cannot map to multiple templates.
-
The template name should be configured in the
spring-testatement under the[edit protocols]hierarchy, and should have theprimaryoption enabled. -
Colored and non-colored destinations cannot co-exist in the same
spring-teconfiguration. -
You cannot configure same destination networks, with or without color, under different
spring-teconfiguration statements. -
In non-colored
spring-teconfiguration, only one template can be configured without color object.
Services Supported over Dynamic Segment Routing LSPs
The following services are supported over colored dynamic segment routing LSPs:
-
Layer 3 VPN
-
BGP EVPN
-
Export policy services
The following services are supported over non-colored dynamic segment routing LSPs:
-
Layer 3 VPN
-
Layer 2 VPN
-
Multipath configurations
Behavior With Multiple Tunnel Sources in Segment Routing
When two sources download routes to the same destination from segment routing (for example static and dynamic sourced tunnels), then the segment routing preference is used for choosing the active route entry. A higher value has greater preference. In case the preference remains the same, then the tunnel source is used to determine the route entry.
Dynamic Segment Routing LSPs Limitations
The dynamic SR-TE LSPs do not support the following features and functionalities:
-
IPv6 segment routing tunnels.
-
Static tunnels.
-
6PE is not supported.
-
Distributed CSPF.
-
sBFD and LDP tunnelling is not supported for dynamic SR-TE LSPs and in a template.
-
Install and B-SID routes in a template.
Color-Based Mapping of VPN Services
You can specify color as a protocol next hop constraint (in addition to the IPv4 or IPv6 address) for resolving transport tunnels over static colored and BGP segment routing traffic-engineered (SR-TE) LSPs. This is called the color-IP protocol next hop resolution, where you are required to configure a resolution-map and apply to the VPN services. With this feature, you can enable color-based traffic steering of Layer 2 and Layer 3 VPN services.
Junos OS supports colored SR-TE LSPs associated with a single color. The color-based mapping of VPN services feature is supported on static colored LSPs and BGP SR-TE LSPs.
- VPN Service Coloring
- Specifying VPN Service Mapping Mode
- Color-IP Protocol Next Hop Resolution
- Fallback to IP Protocol Next Hop Resolution
- BGP Labeled Unicast Color-based Mapping over SR-TE
- Supported and Unsupported Features for Color-Based Mapping of VPN Services
VPN Service Coloring
In general, a VPN service may be assigned a color on the egress router where the VPN NLRI is advertised, or on an ingress router where the VPN NLRI is received and processed.
You can assign a color to the VPN services at different levels:
-
Per routing instance.
-
Per BGP group.
-
Per BGP neighbor.
-
Per prefix.
Once you assign a color, the color is attached to a VPN service in the form of BGP color extended community.
You can assign multiple colors to a VPN service, referred to as multi-color VPN services. In such cases, the last color attached is considered as the color of the VPN service, and all other colors are ignored.
Multiple colors are assigned by egress and/or ingress devices through multiple policies in the following order:
-
BGP export policy on the egress device.
-
BGP import policy on the ingress device.
-
VRF import policy on the ingress device.
The two modes of VPN service coloring are:
Egress Color Assignment
In this mode, the egress device (that is, the advertiser of the VPN NLRI)
is responsible for coloring the VPN service. To enable this mode, you
can define a routing policy, and apply it in the VPN service’s
routing-instance vrf-export, group export, or group
neighbor export at the [edit protocols bgp] hierarchy
level. The VPN NLRI is advertised by BGP with the specified color
extended community.
For example:
[edit policy-options]
community red-comm {
members color:0:50;
}
[edit policy-options]
policy-statement pol-color {
term t1 {
from {
[any match conditions];
}
then {
community add red-comm;
accept;
}
}
}
[edit routing-instances]
vpn-X {
...
vrf-export pol-color ...;
}
Or
When you apply the routing policy as an export policy of a BGP group
or BGP neighbor, you must include the
vpn-apply-export statement at the BGP, BGP
group, or BGP neighbor level in order for the policy to take an
effect on the VPN NLRI.
[edit protocols bgp]
group PEs {
...
neighbor PE-A {
export pol-color ...;
vpn-apply-export;
}
}
The routing policies are applied to Layer 3 VPN prefix NLRIs, Layer 2 VPN NRLIs, and EVPN NLRIs. The color extended community is inherited by all the VPN routes, imported, and installed in the target VRFs on one or multiple ingress devices.
Ingress Color Assignment
In this mode, the ingress device (that is, the receiver of the VPN NLRI)
is responsible for coloring the VPN service. To enable this mode, you
can define a routing policy, and apply it to the VPN service’s
routing-instance vrf-import, group import, or group
neighbor import at the [edit protocols bgp] hierarchy
level. All the VPN routes matching the routing policy is attached with
the specified color extended community.
For example:
[edit routing-options]
community red-comm {
members color:0:50;
}
[edit policy-options]
policy-statement pol-color {
term t1 {
from {
[any match conditions];
}
then {
community add red-comm;
accept;
}
}
}
[edit routing-instances]
vpn-Y {
...
vrf-import pol-color ...;
}
Or
[edit protocols bgp]
group PEs {
...
neighbor PE-B {
import pol-color ...;
}
}
Specifying VPN Service Mapping Mode
To specify flexible VPN service mapping modes, you must define a policy using the
resolution-map statement, and refer the policy in a VPN
service’s routing-instance vrf-import, group import, or group
neighbor import at the [edit protocols bgp] hierarchy level.
All the VPN routes matching the routing policy are attached with the specified
resolution-map.
For example:
[edit policy-options]
resolution-map map-A {
<mode-1>;
<mode-2>;
...
}
policy-statement pol-resolution {
term t1 {
from {
[any match conditions];
}
then {
resolution-map map-A;
accept;
}
}
}
You can apply import policy to the VPN service’s routing-instance.
[edit routing-instances]
vpn-Y {
...
vrf-import pol-resolution ...;
}
You can also apply the import policy to a BGP group or BGP neighbor.
[edit protocols bgp]
group PEs {
...
neighbor PE-B {
import pol-resolution ...;
}
}
Each VPN service mapping mode should have a unique name defined in the
resolution-map. Only a single entry of IP-color is supported in the
resolution-map, where the VPN route(s) are resolved using a colored-IP
protocol next hop in the form of ip-address:color.
Color-IP Protocol Next Hop Resolution
The protocol next hop resolution process is enhanced to support colored-IP protocol next hop resolution. For a colored VPN service, the protocol next hop resolution process takes a color and a resolution-map, builds a colored-IP protocol next hop in the form of IP-address:color, and resolves the protocol next hop in the inet6color.0 routing table.
You must configure a policy to support multipath resolution of colored Layer 2 VPN, Layer 3 VPN, or EVPN services over colored LSPs. The policy must then be applied with the relevant RIB table as the resolver import policy.
For example:
[edit policy-options]
policy-statement mpath {
then multipath-resolve;
}
[edit routing-options]
resolution {
rib bgp.l3vpn.0 {
inetcolor-import mpath;
}
}
resolution {
rib bgp.l3vpn-inet6.0 {
inet6color-import mpath;
}
}
resolution {
rib bgp.l2vpn.0 {
inetcolor-import mpath;
}
}
resolution {
rib mpls.0 {
inetcolor-import mpath;
}
}
resolution {
rib bgp.evpn.0 {
inetcolor-import mpath;
}
}
Fallback to IP Protocol Next Hop Resolution
If a colored VPN service does not have a resolution-map applied to it, the VPN service ignores its color and falls back to the IP protocol next hop resolution. Conversely, if a non-colored VPN service has a resolution-map applied to it, the resolution-map is ignored, and the VPN service uses the IP protocol next hop resolution.
The fallback is a simple process from colored SR-TE LSPs to LDP LSPs, by using a RIB group for LDP to install routes in inet{6}color.0 routing tables. A longest prefix match for a colored-IP protocol next hop ensures that if a colored SR-TE LSP route does not exist, an LDP route with a matching IP address should be returned.
BGP Labeled Unicast Color-based Mapping over SR-TE
Starting in Junos OS Release 20.2R1, BGP Labeled Unicast (BGP-LU) can resolve
IPv4 or IPv6 routes over segment routing–traffic engineering (SR-TE) for both
IPv4 and IPv6 address families. BGP-LU supports mapping a BGP community color
and defining a resolution map for SR-TE. A colored protocol
next hop is constructed and it is resolved on a colored SR-TE tunnel in the
inetcolor.0 or inet6color.0 table. BGP
uses inet.3 and inet6.3 tables for non-color
based mapping. This enables you to advertise BGP-LU IPv6 and IPv4 prefixes with
an IPv6 next-hop address in IPv6-only networks where routers do not have any
IPv4 addresses configured. With this feature, Currently we support BGP IPv6 LU
over SR-TE with IS-IS underlay.
In Figure 1, the controller configures 4 colored tunnels in an IPv6 core network configured with SR-TE. Each colored tunnel takes a different path to the destination router D depending on the defined resolution map. The controller configures a colored SR-TE tunnel to 2001:db8::3701:2d05 interface in router D . BGP imports policies to assign a color and resolution map to the received prefix 2001:db8::3700:6/128. Based on the assigned community color, BGP-LU resolves the colored next hop for BGP IPv6 LU prefix according to the assigned resolution map policy.
BGP-LU supports the following scenarios:
-
BGP IPv4 LU over colored BGP IPv4 SR-TE, with ISIS/OSPF IPv4 SR extensions.
-
BGP IPv4 LU over static colored and non-colored IPv4 SR-TE, with ISIS/OSPF IPv4 SR extensions.
-
BGP IPv6 LU over colored BGP IPv6 SR-TE, with ISIS IPv6 SR extensions.
-
BGP IPv6 LU over static colored and non-colored IPv6 SR-TE, with ISIS IPv6 SR extensions.
-
IPv6 Layer 3 VPN services with IPv6 local address and IPv6 neighbor address.
-
IPv6 Layer 3 VPN services over BGP IPv6 SR-TE, with ISIS IPv6 SR extensions.
-
IPv6 Layer 3 VPN services over static-colored and non-colored IPv6 SR-TE, with ISIS IPv6 SR extensions.
Supported and Unsupported Features for Color-Based Mapping of VPN Services
The following features and functionality are supported with color-based mapping of VPN services:
-
BGP Layer 2 VPN (Kompella Layer 2 VPN)
-
BGP EVPN
-
Resolution-map with a single IP-color option.
-
Colored IPv4 and IPv6 protocol next hop resolution.
-
Routing information base (also known as routing table) group based fallback to LDP LSP in inetcolor.0 routing table.
-
Colored SR-TE LSP.
-
Virtual platforms.
-
64-bit Junos OS.
-
Logical systems.
-
BGP labeled unicast.
The following features and functionality are not supported with color-based mapping of VPN services:
-
Colored MPLS LSPs, such as RSVP, LDP, BGP-LU, static.
-
Layer 2 circuit
-
FEC-129 BGP auto-discovered and LDP-signaled Layer 2 VPN.
-
VPLS
-
MVPN
-
IPv4 and IPv6 using resolution-map.
Tunnel Templates for PCE-Initiated Segment Routing LSPs
You can configure a tunnel template for PCE-initiated segment routing LSPs to pass down two additional parameters for these LSPs - Bidirectional forwarding detection (BFD) and LDP tunneling.
When a PCE-Initiated segment routing LSP is being created, the LSP is checked against policy statements (if any) and if there is a match, the policy applies the configured template for that LSP. The template configuration is inherited only if it is not provided by the LSP source (PCEP); for example, metric.
To configure a template:
-
Include the source-routing-path-template statement at the
[edit protocols source-packet-routing]hierarchy level. You can configure the additional BFD and LDP tunneling parameters here. -
Include the source-routing-path-template-map statement at the
[edit protocols source-packet-routing]hierarchy level to list the policy statements against which the PCE-initiated LSP should be checked. -
Define a policy to list the LSPs on which the template should be applied.
The
fromstatement can include either the LSP name or LSP regular expression using thelspandlsp-regexmatch conditions. These options are mutually exclusive, so you can specify only one option at a given point in time.The
thenstatement must include thesr-te-templateoption with an accept action. This applies the template to the PCE-initiated LSP.
Take the following into consideration when configuring a template for PCE-initiated LSPs:
-
Template configuration is not applicable to staticalyy configured segment routing LSPs, or any other client’s segment routing LSP.
-
PCEP-provided configuration has precedence over template configuration.
-
PCEP LSP does not inherit template segment-list configuration.
Example: Configuring Static Segment Routing Label Switched Path
This example shows how to configure static segment routing label switched paths (LSPs) in MPLS networks. This configuration helps to bring higher scalability to MPLS networks.
Requirements
This example uses the following hardware and software components:
-
Seven MX Series 5G Universal Routing Platforms
-
Junos OS Release 18.1 or later running on all the routers
Before you begin, be sure you configure the device interfaces.
Overview
Junos OS a set of explicit segment routing paths are configured on the ingress router
of a non-colored static segment routing tunnel by configuring the
segment-list
statement at the [edit protocols source-packet-routing] hierarchy
level. You can configure segment routing tunnel by configuring the
source-routing-path statement at [edit protocols
source-packet-routing] hierarchy level. The segment routing tunnel has
a destination address and one or more primary paths and optionally secondary paths
that refer to the segment list. Each segment list consists of a sequence of hops.
For non-colored static segment routing tunnel, the first hop of the segment list
specifies an immediate next hop IP address and the second to Nth hop specifies the
segment identifies (SID) labels corresponding to the link or node which the path
traverses. The route to the destination of the segment routing tunnel is installed
in inet.3 table.
Topology
In this example, configure layer 3 VPN on the provider edge routers PE1 and PE5. Configure the MPLS protocol on all the routers. The segment routing tunnel is configured from router PE1 to router PE5 with a primary path configured on router PE1 and router PE5 . Router PE1 is also configured with secondary path for path protection. The transit routers PE2 to PE4 are configured with adjacency SID labels with label pop and an outgoing interface.
Configuration
CLI Quick Configuration
To quickly configure this example, copy the following commands, paste them into a
text file, remove any line breaks, change any details necessary to match your
network configuration, copy and paste the commands into the CLI at the
[edit] hierarchy level, and then enter
commit from configuration mode.
PE1
set interfaces ge-0/0/0 unit 0 family inet address 10.10.12.1/24 set interfaces ge-0/0/0 unit 0 family mpls maximum-labels 5 set interfaces ge-0/0/1 unit 0 family inet address 10.10.13.1/24 set interfaces ge-0/0/1 unit 0 family mpls maximum-labels 5 set interfaces ge-0/0/5 unit 0 family inet address 10.10.17.1/24 set routing-options autonomous-system 65000 set routing-options forwarding-table export load-balance-policy set routing-options forwarding-table chained-composite-next-hop ingress l3vpn set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols mpls label-range static-label-range 1000000 1000999 set protocols bgp group pe type internal set protocols bgp group pe local-address 192.168.147.211 set protocols bgp group pe family inet-vpn unicast set protocols bgp group pe neighbor 192.168.146.181 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols source-packet-routing segment-list sl-15-primary hop-1 ip-address 10.10.13.3 set protocols source-packet-routing segment-list sl-15-primary hop-2 label 1000134 set protocols source-packet-routing segment-list sl-15-primary hop-3 label 1000145 set protocols source-packet-routing segment-list sl-15-backup hop-1 ip-address 10.10.12.2 set protocols source-packet-routing segment-list sl-15-backup hop-2 label 1000123 set protocols source-packet-routing segment-list sl-15-backup hop-3 label 1000134 set protocols source-packet-routing segment-list sl-15-backup hop-4 label 1000145 set protocols source-packet-routing source-routing-path lsp-15 to 192.168.146.181 set protocols source-packet-routing source-routing-path lsp-15 binding-sid 1000999 set protocols source-packet-routing source-routing-path lsp-15 primary sl-15-primary set protocols source-packet-routing source-routing-path lsp-15 secondary sl-15-backup set policy-options policy-statement VPN-A-export term a from protocol ospf set policy-options policy-statement VPN-A-export term a from protocol direct set policy-options policy-statement VPN-A-export term a then community add VPN-A set policy-options policy-statement VPN-A-export term a then accept set policy-options policy-statement VPN-A-export term b then reject set policy-options policy-statement VPN-A-import term a from protocol bgp set policy-options policy-statement VPN-A-import term a from community VPN-A set policy-options policy-statement VPN-A-import term a then accept set policy-options policy-statement VPN-A-import term b then reject set policy-options policy-statement bgp-to-ospf from protocol bgp set policy-options policy-statement bgp-to-ospf from route-filter 10.10.0.0/16 orlonger set policy-options policy-statement bgp-to-ospf then accept set policy-options policy-statement load-balance-policy then load-balance per-packet set policy-options community VPN-A members target:65000:1 set routing-instances VRF1 instance-type vrf set routing-instances VRF1 interface ge-0/0/5.0 set routing-instances VRF1 route-distinguisher 192.168.147.211:1 set routing-instances VRF1 vrf-import VPN-A-import set routing-instances VRF1 vrf-export VPN-A-export set routing-instances VRF1 vrf-table-label set routing-instances VRF1 protocols ospf export bgp-to-ospf set routing-instances VRF1 protocols ospf area 0.0.0.0 interface ge-0/0/5.0
PE2
set interfaces ge-0/0/0 unit 0 family inet address 10.10.12.2/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 10.10.23.2/24 set interfaces ge-0/0/1 unit 0 family mpls set protocols mpls static-label-switched-path adj-23 segment 1000123 set protocols mpls static-label-switched-path adj-23 segment next-hop 10.10.23.3 set protocols mpls static-label-switched-path adj-23 segment pop set protocols mpls static-label-switched-path adj-21 segment 1000221 set protocols mpls static-label-switched-path adj-21 segment next-hop 10.10.12.1 set protocols mpls static-label-switched-path adj-21 segment pop set protocols mpls interface ge-0/0/0.0 set protocols mpls interface ge-0/0/1.0 set protocols mpls label-range static-label-range 1000000 1000999 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0
PE3
set interfaces ge-0/0/0 unit 0 family inet address 10.10.13.3/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 unit 0 family inet address 10.10.23.3/24 set interfaces ge-0/0/1 unit 0 family mpls set interfaces ge-0/0/2 unit 0 family inet address 10.10.34.3/24 set interfaces ge-0/0/2 unit 0 family mpls set protocols mpls static-label-switched-path adj-34 segment 1000134 set protocols mpls static-label-switched-path adj-34 segment next-hop 10.10.34.4 set protocols mpls static-label-switched-path adj-34 segment pop set protocols mpls static-label-switched-path adj-32 segment 1000232 set protocols mpls static-label-switched-path adj-32 segment next-hop 10.10.23.2 set protocols mpls static-label-switched-path adj-32 segment pop set protocols mpls interface ge-0/0/1.0 set protocols mpls interface ge-0/0/2.0 set protocols mpls label-range static-label-range 1000000 1000999 set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
PE4
set interfaces ge-0/0/2 unit 0 family inet address 10.10.34.4/24 set interfaces ge-0/0/2 unit 0 family mpls set interfaces ge-0/0/3 unit 0 family inet address 10.10.45.4/24 set interfaces ge-0/0/3 unit 0 family mpls set protocols mpls static-label-switched-path adj-45 segment 1000145 set protocols mpls static-label-switched-path adj-45 segment next-hop 10.10.45.5 set protocols mpls static-label-switched-path adj-45 segment pop set protocols mpls static-label-switched-path adj-43 segment 1000243 set protocols mpls static-label-switched-path adj-43 segment next-hop 10.10.34.3 set protocols mpls static-label-switched-path adj-43 segment pop set protocols mpls interface ge-0/0/2.0 set protocols mpls interface ge-0/0/3.0 set protocols mpls label-range static-label-range 1000000 1000999 set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 set protocols ospf area 0.0.0.0 interface ge-0/0/3.0
PE5
set interfaces ge-0/0/3 unit 0 family inet address 10.10.45.5/24 set interfaces ge-0/0/3 unit 0 family mpls maximum-labels 5 set interfaces ge-0/0/4 unit 0 family inet address 10.10.56.5/24 set routing-options autonomous-system 65000 set protocols mpls interface ge-0/0/3.0 set protocols mpls label-range static-label-range 1000000 1000999 set protocols bgp group pe type internal set protocols bgp group pe local-address 192.168.146.181 set protocols bgp group pe family inet-vpn unicast set protocols bgp group pe neighbor 192.168.147.211 set protocols ospf area 0.0.0.0 interface ge-0/0/3.0 set protocols ospf area 0.0.0.0 interface lo0.0 set protocols bfd sbfd local-discriminator 0.0.0.32 minimum-receive-interval 1000 set protocols source-packet-routing segment-list sl-51 hop-1 ip-address 10.10.45.4 set protocols source-packet-routing segment-list sl-51 hop-2 label 1000243 set protocols source-packet-routing segment-list sl-51 hop-3 label 1000232 set protocols source-packet-routing segment-list sl-51 hop-4 label 1000221 set protocols source-packet-routing source-routing-path lsp-51 to 192.168.147.211 set protocols source-packet-routing source-routing-path lsp-51 primary sl-51 set policy-options policy-statement VPN-A-export term a from protocol ospf set policy-options policy-statement VPN-A-export term a from protocol direct set policy-options policy-statement VPN-A-export term a then community add VPN-A set policy-options policy-statement VPN-A-export term a then accept set policy-options policy-statement VPN-A-export term b then reject set policy-options policy-statement VPN-A-import term a from protocol bgp set policy-options policy-statement VPN-A-import term a from community VPN-A set policy-options policy-statement VPN-A-import term a then accept set policy-options policy-statement VPN-A-import term b then reject set policy-options policy-statement bgp-to-ospf from protocol bgp set policy-options policy-statement bgp-to-ospf from route-filter 10.10.0.0/16 orlonger set policy-options policy-statement bgp-to-ospf then accept set policy-options community VPN-A members target:65000:1 set routing-instances VRF1 instance-type vrf set routing-instances VRF1 interface ge-0/0/4.0 set routing-instances VRF1 route-distinguisher 192.168.146.181:1 set routing-instances VRF1 vrf-import VPN-A-import set routing-instances VRF1 vrf-export VPN-A-export set routing-instances VRF1 vrf-table-label set routing-instances VRF1 protocols ospf export bgp-to-ospf set routing-instances VRF1 protocols ospf area 0.0.0.0 interface ge-0/0/4.0
CE1
set interfaces ge-0/0/0 unit 0 family inet address 10.10.17.7/24 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0
CE2
set interfaces ge-0/0/4 unit 0 family inet address 10.10.56.6/24 set protocols ospf area 0.0.0.0 interface ge-0/0/4.0
Configuring Device PE1
Step-by-Step Procedure
The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.
To configure Device PE1:
-
Configure the interfaces.
[edit interfaces] set ge-0/0/0 unit 0 family inet address 10.10.12.1/24 set ge-0/0/0 unit 0 family mpls maximum-labels 5 set ge-0/0/1 unit 0 family inet address 10.10.13.1/24 set ge-0/0/1 unit 0 family mpls maximum-labels 5 set ge-0/0/5 unit 0 family inet address 10.10.17.1/24
-
Configure autonomous system number and options to control packet forwarding routing options.
[edit routing-options] set autonomous-system 65000 set forwarding-table export load-balance-policy set forwarding-table chained-composite-next-hop ingress l3vpn
-
Configure the interfaces with the MPLS protocol and configure the MPLS label range.
[edit protocols mpls] set interface ge-0/0/0.0 set interface ge-0/0/1.0 set label-range static-label-range 1000000 1000999
-
Configure the type of peer group, local address, protocol family for NLRIs in updates, and IP address of a neighbor for the peer group.
[edit protocols bgp] set group pe type internal set group pe local-address 192.168.147.211 set group pe family inet-vpn unicast set group pe neighbor 192.168.146.181
-
Configure the protocol area interfaces.
[edit protocols ospf] set area 0.0.0.0 interface ge-0/0/0.0 set area 0.0.0.0 interface lo0.0 set area 0.0.0.0 interface ge-0/0/1.0
-
Configure the IPv4 address and labels of primary and secondary paths for source routing-traffic engineering (TE) policies of protocol source packet routing (SPRING).
[edit protocols source-packet-routing segment-list] set sl-15-primary hop-1 ip-address 10.10.13.3 set sl-15-primary hop-2 label 1000134 set sl-15-primary hop-3 label 1000145 set sl-15-backup hop-1 ip-address 10.10.12.2 set sl-15-backup hop-2 label 1000123 set sl-15-backup hop-3 label 1000134 set sl-15-backup hop-4 label 1000145
-
Configure destination IPv4 address, binding SID label, primary, and secondary source routing path for protocol SPRING.
[edit protocols source-packet-routing source-routing-path] set lsp-15 to 192.168.146.181 set lsp-15 binding-sid 1000999 set lsp-15 primary sl-15-primary set lsp-15 secondary sl-15-backup
-
Configure policy options.
[edit policy-options policy-statement] set VPN-A-export term a from protocol ospf set VPN-A-export term a from protocol direct set VPN-A-export term a then community add VPN-A set VPN-A-export term a then accept set VPN-A-export term b then reject set VPN-A-import term a from protocol bgp set VPN-A-import term a from community VPN-A set VPN-A-import term a then accept set VPN-A-import term b then reject set bgp-to-ospf from protocol bgp set bgp-to-ospf from route-filter 10.10.0.0/16 orlonger set bgp-to-ospf then accept set load-balance-policy then load-balance per-packet
-
Configure BGP community information.
[edit policy-options] set community VPN-A members target:65000:1
-
Configure routing instance VRF1 with instance type, interface, router distinguisher, VRF import, export and table label. Configure export policy and interface of area for protocol OSPF.
[edit routing-instances VRF1] set instance-type vrf set interface ge-0/0/5.0 set route-distinguisher 192.168.147.211:1 set vrf-import VPN-A-import set vrf-export VPN-A-export set vrf-table-label set protocols ospf export bgp-to-ospf set protocols ospf area 0.0.0.0 interface ge-0/0/5.0
Results
From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, show routing-options, and show routing-instances commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.
[edit]
user@PE1# show
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
address 10.10.12.1/24;
}
family mpls {
maximum-labels 5;
}
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 10.10.13.1/24;
}
family mpls {
maximum-labels 5;
}
}
}
ge-0/0/5 {
unit 0 {
family inet {
address 10.10.17.1/24;
}
}
}
}
policy-options {
policy-statement VPN-A-export {
term a {
from protocol [ ospf direct ];
then {
community add VPN-A;
accept;
}
}
term b {
then reject;
}
}
policy-statement VPN-A-import {
term a {
from {
protocol bgp;
community VPN-A;
}
then accept;
}
term b {
then reject;
}
}
policy-statement bgp-to-ospf {
from {
protocol bgp;
route-filter 10.10.0.0/16 orlonger;
}
then accept;
}
policy-statement load-balance-policy {
then {
load-balance per-packet;
}
}
community VPN-A members target:65000:1;
}
routing-instances {
VRF1 {
instance-type vrf;
protocols {
ospf {
area 0.0.0.0 {
interface ge-0/0/5.0;
}
export bgp-to-ospf;
}
}
interface ge-0/0/5.0;
route-distinguisher 192.168.147.211:1;
vrf-import VPN-A-import;
vrf-export VPN-A-export;
vrf-table-label;
}
}
routing-options {
autonomous-system 65000;
forwarding-table {
export load-balance-policy;
chained-composite-next-hop {
ingress {
l3vpn;
}
}
}
}
protocols {
bgp {
group pe {
type internal;
local-address 192.168.147.211;
family inet-vpn {
unicast;
}
neighbor 192.168.146.181;
}
}
mpls {
label-range {
static-label-range 1000000 1000999;
}
interface ge-0/0/0.0;
interface ge-0/0/1.0;
}
ospf {
area 0.0.0.0 {
interface ge-0/0/0.0;
interface lo0.0;
interface ge-0/0/1.0;
}
}
source-packet-routing {
segment-list sl-15-primary {
hop-1 ip-address 10.10.13.3;
hop-2 label 1000134;
hop-3 label 1000145;
}
segment-list sl-15-backup {
hop-1 ip-address 10.10.12.2;
hop-2 label 1000123;
hop-3 label 1000134;
hop-4 label 1000145;
}
source-routing-path lsp-15 {
to 192.168.146.181;
binding-sid 1000999;
primary {
sl-15-primary;
}
secondary {
sl-15-backup;
}
}
}
}
Configuring Device PE2
Step-by-Step Procedure
The following example requires that you navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.
-
Configure the interfaces.
[edit interfaces] set ge-0/0/0 unit 0 family inet address 10.10.12.2/24 set ge-0/0/0 unit 0 family mpls set ge-0/0/1 unit 0 family inet address 10.10.23.2/24 set ge-0/0/1 unit 0 family mpls
-
Configure the static LSP for protocol MPLS.
[edit protocols mpls static-label-switched-path] set adj-23 segment 1000123 set adj-23 segment next-hop 10.10.23.3 set adj-23 segment pop set adj-21 segment 1000221 set adj-21 segment next-hop 10.10.12.1 set adj-21 segment pop
-
Configure interfaces and static label range for protocol MPLS.
[edit protocols mpls] set interface ge-0/0/0.0 set interface ge-0/0/1.0 set label-range static-label-range 1000000 1000999
-
Configure interfaces for protocol OSPF.
[edit protocols ospf area 0.0.0.0] set interface ge-0/0/0.0 set interface ge-0/0/1.0
Results
From configuration mode on router PE2, confirm your configuration by entering the show interfaces and show protocols commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.
[edit]
user@PE2# show
interfaces {
ge-0/0/0 {
unit 0 {
family inet {
address 10.10.12.2/24;
}
family mpls;
}
}
ge-0/0/1 {
unit 0 {
family inet {
address 10.10.23.2/24;
}
family mpls;
}
}
}
protocols {
mpls {
label-range {
static-label-range 1000000 1000999;
}
interface ge-0/0/0.0;
interface ge-0/0/1.0;
static-label-switched-path adj-23 {
segment {
1000123;
next-hop 10.10.23.3;
pop;
}
}
static-label-switched-path adj-21 {
segment {
1000221;
next-hop 10.10.12.1;
pop;
}
}
}
ospf {
area 0.0.0.0 {
interface ge-0/0/0.0;
interface ge-0/0/1.0;
}
}
}Verification
Confirm that the configuration is working properly.
- Verifying Route Entry of Routing Table inet.3 of Router PE1
- Verifying Route Table Entries of Routing Table mpls.0 of Router PE1
- Verifying SPRING Traffic Engineered LSP of Router PE1
- Verifying SPRING Traffic Engineered LSPs on the Ingress Router of Router PE1
- Verifying the Routing Table Entries of Routing Table mpls.0 of Router PE2
- Verifying the Status of Static MPLS LSP Segments of Router PE2
Verifying Route Entry of Routing Table inet.3 of Router PE1
Purpose
Verify the route entry of routing table inet.3 of router PE1.
Action
From operational mode, enter the show route table inet.3
command.
user@PE1> show route table inet.3
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.146.181/32 *[SPRING-TE/8] 03:09:26, metric 1
> to 10.10.13.3 via ge-0/0/1.0, Push 1000145, Push 1000134(top)
to 10.10.12.2 via ge-0/0/0.0, Push 1000145, Push 1000134, Push 1000123(top)Meaning
The output displays the ingress routes of segment routing tunnels.
Verifying Route Table Entries of Routing Table mpls.0 of Router PE1
Purpose
Verify the route entries of routing table mpls.0
Action
From operational mode, enter the show route table mpls.0
command.
user@PE1> show route table mpls.0
mpls.0: 6 destinations, 6 routes (6 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0 *[MPLS/0] 03:25:52, metric 1
Receive
1 *[MPLS/0] 03:25:52, metric 1
Receive
2 *[MPLS/0] 03:25:52, metric 1
Receive
13 *[MPLS/0] 03:25:52, metric 1
Receive
16 *[VPN/0] 03:25:52
> via lsi.0 (VRF1), Pop
1000999 *[SPRING-TE/8] 03:04:03, metric 1
> to 10.10.13.3 via ge-0/0/1.0, Swap 1000145, Push 1000134(top)
to 10.10.12.2 via ge-0/0/0.0, Swap 1000145, Push 1000134, Push 1000123(top)
Meaning
The output displays the SID labels of segment routing tunnels.
Verifying SPRING Traffic Engineered LSP of Router PE1
Purpose
Verify SPRING traffic engineered LSPs on the ingress routers.
Action
From operational mode, enter the show spring-traffic-engineering
overview command.
user@PE1> show spring-traffic-engineering overview
Overview of SPRING-TE:
Route preference: 8
Number of LSPs: 1 (Up: 1, Down: 0)
External controllers:
< Not configured >
Meaning
The output displays the overview of SPRING traffic engineered LSPs on the ingress router.
Verifying SPRING Traffic Engineered LSPs on the Ingress Router of Router PE1
Purpose
Verify SPRING traffic engineered LSPs on the ingress router.
Action
From operational mode, enter the show spring-traffic-engineering lsp
detail command.
user@PE1# show spring-traffic-engineering lsp detail
Name: lsp-15
To: 192.168.146.181
State: Up
Path: sl-15-primary
Outgoing interface: ge-0/0/1.0
BFD status: N/A (Up: 0, Down: 0)
SR-ERO hop count: 3
Hop 1 (Strict):
NAI: IPv4 Adjacency ID, 0.0.0.0 -> 10.10.13.3
SID type: None
Hop 2 (Strict):
NAI: None
SID type: 20-bit label, Value: 1000134
Hop 3 (Strict):
NAI: None
SID type: 20-bit label, Value: 1000145
Path: sl-15-backup
Outgoing interface: ge-0/0/0.0
BFD status: N/A (Up: 0, Down: 0)
SR-ERO hop count: 4
Hop 1 (Strict):
NAI: IPv4 Adjacency ID, 0.0.0.0 -> 10.10.12.2
SID type: None
Hop 2 (Strict):
NAI: None
SID type: 20-bit label, Value: 1000123
Hop 3 (Strict):
NAI: None
SID type: 20-bit label, Value: 1000134
Hop 4 (Strict):
NAI: None
SID type: 20-bit label, Value: 1000145
Total displayed LSPs: 1 (Up: 1, Down: 0)Meaning
The output displays details of SPRING traffic engineered LSPs on the ingress router
Verifying the Routing Table Entries of Routing Table mpls.0 of Router PE2
Purpose
Verify the routing table entries of routing table mpls.0 of router PE2.
Action
From operational mode, enter the show route table mpls.0
command.
user@PE2> show route table mpls.0
mpls.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0 *[MPLS/0] 03:22:29, metric 1
Receive
1 *[MPLS/0] 03:22:29, metric 1
Receive
2 *[MPLS/0] 03:22:29, metric 1
Receive
13 *[MPLS/0] 03:22:29, metric 1
Receive
1000123 *[MPLS/6] 03:22:29, metric 1
> to 10.10.23.3 via ge-0/0/1.0, Pop
1000123(S=0) *[MPLS/6] 03:22:29, metric 1
> to 10.10.23.3 via ge-0/0/1.0, Pop
1000221 *[MPLS/6] 03:22:29, metric 1
> to 10.10.12.1 via ge-0/0/0.0, Pop
1000221(S=0) *[MPLS/6] 03:22:29, metric 1
> to 10.10.12.1 via ge-0/0/0.0, PopVerifying the Status of Static MPLS LSP Segments of Router PE2
Purpose
Verify the status of MPLS LSP segments of router PE2.
Action
From operational mode, enter the show mpls static-lsp
command.
user@PE2> show mpls static-lsp
Ingress LSPs:
Total 0, displayed 0, Up 0, Down 0
Transit LSPs:
Total 0, displayed 0, Up 0, Down 0
Bypass LSPs:
Total 0, displayed 0, Up 0, Down 0
Segment LSPs:
LSPname SID-label State
adj-21 1000221 Up
adj-23 1000123 Up
Total 2, displayed 2, Up 2, Down 0Meaning
The output displays the status of static MPLS LSP segments of router PE2.
Routing Engine-based S-BFD for Segment-Routing Traffic Engineering with First-Hop Label Resolution
You can run seamless Bidirectional Forwarding Detection (S-BFD) over non-colored and colored label-switched paths (LSPs) with first-hop label resolution, using S-BFD as a fast mechanism to detect path failures.
- Understanding RE-based S-BFD for Segment-Routing Traffic Engineering with First-Hop Label Resolution
- Configuring RE-based S-BFD for Segment-Routing Traffic Engineering with First-Hop Label Resolution
- Example
- Verify That LSPs Are Configured for Static Segment-Routing Tunnels and That S-BFD Session Status Is Visible
- Verify the Segment-Routing Tunnel Route with a Primary Next Hop and a Secondary Next Hop
- Verify the S-BFD Session of the Primary Path
Understanding RE-based S-BFD for Segment-Routing Traffic Engineering with First-Hop Label Resolution
- S-BFD Static Segment-Routing Tunnels for First-Hop Labels
- Limitations
- Auto Derivation of Remote Discriminator (RD) for SBFD Session
S-BFD Static Segment-Routing Tunnels for First-Hop Labels
Segment-routing architecture enables ingress nodes in a core network to steer traffic through explicit paths through the network. The segment-routing traffic engineering (TE) next hop is a list or lists of segment identifiers (SIDs). These segment lists represent paths in the network that you want incoming traffic to take. The incoming traffic may be labeled or IP traffic and the forwarding operation at the ingress node may be a label swap or a destination-based lookup to steer the traffic onto these segment-routing TE paths in the forwarding path.
You can run seamless BFD (S-BFD) over non-colored and colored static segment-routing LSPs with first-hop label resolution and use S-BFD as a fast mechanism to detect path failures and to trigger global convergence. S-BFD requires fewer state changes than BFD requires, thus speeding up the reporting of path failures.
Given a segment-routing tunnel with one or multiple primary LSPs and optionally a secondary LSP, you can enable S-BFD on any of those LSPs. If an S-BFD session goes down, the software updates the segment-routing tunnel’s route by deleting the next hops of the failed LSPs. If the first-hop label of the LSP points to more than one immediate next hop, the kernel continues to send S-BFD packets if at least one next hop is available (underlying next-hop reachability failure detection must be faster than the duration of the S-BFD detection timer).
This model is supported for auto-translate-derived LSPs.
LSP-level S-BFD
An S-BFD session is created for each unique label-stack+address-family combination. You can configure identical segment lists and enable S-BFD for all of them. The segment lists that have identical label-stack+address-family combinations share the same S-BFD session. The source address for the S-BFD session is set to the least configured loopback address (except the special addresses) under the main instance.
Ensure that the chosen source address is routable.
The address family of an LSP is derived based on the address family of the “to” address in the segment-routing TE tunnel. The state of the LSP with S-BFD configured also depends on whether BFD is up—if S-BFD is configured for an LSP, the LSP route isn’t calculated until S-BFD reports the path is alive.
S-BFD Parameters
The following S-BFD parameters are supported for segment-routing TE paths:
-
Remote discriminator
-
Minimum interval
-
Multiplier
-
No router alert option
In S-BFD, each responder may have multiple discriminators. The discriminators may be advertised by IGP to other routers, or they may be statically configured on these routers. On an initiator, a particular discriminator is chosen as the remote discriminator for an S-BFD session by static configuration, based on the decision or resolution made by you or by a central controller. When multiple LSPs are created with the same key label stack and S-BFD is enabled on each of them with different parameters, the aggressive value of each parameter is used in the shared S-BFD session. For the discriminator parameter, the lowest value is considered as most aggressive. Similarly for the router alert option, if one of the configurations no router alert is configured, the derived S-BFD parameter will have no router alert option.
Limitations
-
Only global repair is supported.
-
Even though S-BFD detects failures depending on the configured timer values, convergence time depends on the global repair time (seconds).
Auto Derivation of Remote Discriminator (RD) for SBFD Session
Starting in Junos OS Release 22.4R1, you can use the auto-derived remote
discriminator for SBFD sessions for the SR-TE paths. With this feature, you need
not configure a remote-discriminator in the SFBD configuration
on the ingress or transit device and a matching local-discriminator on its
respective endpoint. Instead, the egress PE device will now accept IP addresses
as its local discriminator. To allow IP address as local-discriminator in BFD,
use the set protocols bfd sbfd local-discriminator-ip
configuration.
You can also use a common SBFD template with the SBFD configurations on multiple controller provisioned SR-TE policies. In these SBFD sessions, Junos OS automatically derives the remote discriminator from the tunnel endpoint for matching SR-TE policies.
-
We support auto derivation of RD only for IPv4 endpoints, not for IPv6 endpoints.
-
We do not support auto derivation of RD for color-only tunnels. If RD is not configured (by auto derivation of RD) for statically configured SR-TE color-only tunnels, the system will display a commit error. If RD is not configured (by auto derivation of RD) for dynamic color-only tunnels by using SR-TE template configuration, Junos OS skips the sbfd configuration for that tunnel.
Configuring RE-based S-BFD for Segment-Routing Traffic Engineering with First-Hop Label Resolution
To enable LSP-level S-BFD for a segment list, you configure
the bfd-liveness-detection configuration statement at the [edit protocols source-packet-routing source-routing-path lsp-path-name primary segment-list-name] hierarchy and the [edit protocols source-packet-routing
source-routing-path lsp-path-name secondary segment-list-name] hierarchy.
The following steps give the basic configuration and then operation of S-BFD with first-hop label resolution:
The steps immediately below describe the outlines of the basic configuration:
On an ingress router, you configure one or more segment lists with first-hop labels for a static segment-routing tunnel to use as primary and secondary paths.
On the ingress router, you configure the static segment-routing tunnel, with either multiple primary paths (for load balancing), or one primary path and one secondary path (for path protection). Each primary or secondary path (LSP) refers to one of the segment lists you configured already, creating routes using the next hops derived from the first-hop labels from contributing LSPs.
On the ingress router, you enable per-packet load-balancing so that routes resolving over ingress routes and the binding-SID route (which all have first-hop labels) install all active paths in the Packet Forwarding Engine. An S-BFD session under an LSP protects all routes that use that LSP.
On the egress router of the segment-routing tunnel, you configure S-BFD responder mode with a local discriminator D, creating a distributed S-BFD listener session for D on each FPC.
On the ingress router, you configure S-BFD for any LSP for which you want to see path-failure detection. You specify a remote-discriminator D to match the local S-BFD discriminator of the egress router. An S-BFD initiator session is created with the LSP label-stack+address-family combination as the key, if an initiator session doesn’t already exist for the current LSP key. The S-BFD parameters in the case of a matching BFD session are reevaluated with the new shared LSPs taken into consideration. When the S-BFD parameters are derived, the aggressive value of each parameter is chosen.
The steps immediately below describe basic operation :
The S-BFD initiator session runs in a centralized mode on the Routing Engine. The software tracks S-BFD session up and down states.
When the S-BFD state moves to UP, the LSP is considered for the relevant routes.
On the ingress router, if the software detects an S-BFD session DOWN, a session-down notification is sent to the routing daemon (RPD), and RPD deletes the next hop of the failed LSPs from the segment-routing tunnel’s route.
The total traffic loss in the procedure is bound to the S-BFD failure detection time and the global repair time. The S-BFD failure detection time is determined by the S-BFD minimum-interval and multiplier parameters. The global repair time depends on the segment-routing TE process time and the redownload of the routes to forwarding.
LSP label stacks are changed as follows:
The particular LSP is detached from the existing S-BFD session. If the existing S-BFD session has at least one LSP referring to it, the old BFD session is preserved, but the S-BFD parameters are re-evaluated so that the aggressive parameter values among the existing LSP sessions is chosen. Also, the name of the S-BFD session is updated to the least one if there is a change. If the old S-BFD session has no more LSPs attached to it, that S-BFD session is removed.
The software attempts to find an existing BFD session that matches the new-label-stack+address-family combination value; if such a match exists, the LSP refers to that existing S-BFD session. The S-BFD session is re-evaluated for any change in parameters or session name similarly to the re-evaluations in step 1.
If there is no matching BFD session in the system, a new BFD session is created, and the S-BFD parameters are derived from this LSP.
Note:An S-BFD session’s minimum interval and multiplier determine the failure detection time for the session. The repair time additionally depends on the global repair time.
The following output shows configuration statements you would use for a colored LSP with primary LSPs:
[edit protocols]
source-packet-routing {
source-routing-path lsp_name {
to destination_address;
color color_value;
binding-sid binding-label;
primary segment_list_1_name weight weight;
... {
bfd-liveness-detection {
sbfd {
remote-discriminator value;
}
}
}
}
}
At the responder side, you must configure the correct discriminator:
[edit protocols bfd]
sbfd {
local-discriminator value;
}
By default, router alerts are configured for S-BFD packets. When the MPLS header is removed at the responder end, the packet is sent to the host for processing without a destination address lookup for the packet. If you enable the no-router-alert option on the ingress router, the router-alert option is removed from the IP options and hence from the egress side. You must configure the destination address explicitly in lo0; otherwise the packet is discarded, and S-BFD remains down.
[edit interfaces lo0 unit 0 family inet] address 127.0.0.1/32;
You can use a new trace flag, bfd, to trace BFD activities:
user@host# set protocols source-packet-routing traceoptions flag bfd
Example
The following configuration is an example of a non-colored static segment-routing tunnel with LSP protection.
protocols {
source-packet-routing {
source-routing-path ncsrlsp5 {
to 10.10.10.10;
primary {
ncsrpath12 {
weight 1;
bfd-liveness-detection {
sbfd {
remote-discriminator 100;
}
minimum-interval 100;
}
}
ncsrpath13 {
weight 2;
bfd-liveness-detection {
sbfd {
remote-discriminator 100;
}
minimum-interval 100;
}
}
ncsrpath14 {
weight 3;
bfd-liveness-detection {
sbfd {
remote-discriminator 100;
}
minimum-interval 100;
}
}
ncsrpath15 {
weight 4;
bfd-liveness-detection {
sbfd {
remote-discriminator 100;
}
minimum-interval 100;
}
}
segment-list ncsrpath12 {
hop1 label 50191;
hop2 label 801000;
}
segment-list ncsrpath13 {
hop1 label 50191;
hop2 label 801001;
hop3 label 801000;
}
segment-list ncsrpath14 {
hop1 label 801000;
}
segment-list ncsrpath15 {
hop1 label 801002;
hop2 label 801000;
}
}
}
}
}
Verify That LSPs Are Configured for Static Segment-Routing Tunnels and That S-BFD Session Status Is Visible
Purpose
Use the show spring-traffic-engineering lsp detail command to show LSPs for static segment-routing tunnels, with S-BFD
session status.
Action
user@host> show spring-traffic-engineering lsp detail
Name: abc
To: 77.77.77.77
State: Up
Path: sl1
Outgoing interface: NA
BFD status: Up BFD name: V4-sl1
SR-ERO hop count: 3
Hop 1 (Strict):
NAI: None
SID type: 20-bit label, Value: 801007
Hop 2 (Strict):
NAI: None
SID type: 20-bit label, Value: 22222
Hop 3 (Strict):
NAI: None
SID type: 20-bit label, Value: 3333
Path: sl2
Outgoing interface: NA
BFD status: Up BFD name: V4-sl2
SR-ERO hop count: 2
Hop 1 (Strict):
NAI: None
SID type: 20-bit label, Value: 801006
Hop 2 (Strict):
NAI: None
SID type: 20-bit label, Value: 121212
Path: sl2
Outgoing interface: NA
BFD status: Up BFD name: V4-sl2
SR-ERO hop count: 2
Hop 1 (Strict):
NAI: None
SID type: 20-bit label, Value: 801006
Hop 2 (Strict):
NAI: None
SID type: 20-bit label, Value: 121212
Total displayed LSPs: 1 (Up: 1, Down: 0)
Because many LSPs can share the same BFD session, when the first
LSP with a unique label-stack+address-family combination comes up,
the name of the S-BFD session uses address-family+lsp-name. If more
LSPs later share the same session, the name of the session can change
to address-family+least-lsp-name, without affecting the state of the
S-BFD session. The name of the S-BFD session appears in output from
the show bfd session extensive command as well. Output
for each LSP shows the S-BFD status as well as the S-BFD name it is
referring to as shown in the preceding example as BFD
status: Up BFD name: V4-sl2. Because there might not
be one S-BFD session per LSP, the LSP-level S-BFD counters are not
displayed.
Verify the Segment-Routing Tunnel Route with a Primary Next Hop and a Secondary Next Hop
Purpose
On the Routing Engine of the ingress router, verify the segment-routing tunnel route with a primary next hop and a secondary next hop.
Action
user@host> show route table inet.3
inet.3: 1 destinations, 1 routes (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
128.9.146.157/32 *[SPRING-TE/8] 00:43:16, metric 1
> to 55.1.12.2 via ge-0/0/0.0, Push 1000145, Push 1000134, Push 1000123(top)
to 55.1.12.2 via ge-0/0/1.0, Push 1000934, Push 1000923(top)
Verify the S-BFD Session of the Primary Path
Purpose
On the Routing Engine of the ingress router, verify the S-BFD session of the primary path.
Action
user@host> show bfd session extensive
Detect Transmit
Address State Interface Time Interval Multiplier
127.0.0.1 Up 4.000 1.000 4
Client SPRING-TE, TX interval 1.000, RX interval 1.000
Session up time 00:40:53, previous down time 00:02:08
Local diagnostic None, remote diagnostic None
Remote state Up, version 1
Session type: Multi hop BFD (Seamless)
Min async interval 1.000, min slow interval 1.000
Adaptive async TX interval 1.000, RX interval 1.000
Local min TX interval 1.000, minimum RX interval 1.000, multiplier 4
Remote min TX interval 1.000, min RX interval 0.001, multiplier 4
Local discriminator 28, remote discriminator 32
Echo mode disabled/inactive
Remote is control-plane independent
Path-Name V4-sl-1
1 sessions, 1 clients
Cumulative transmit rate 1.0 pps, cumulative receive rate 1.0 pps
On the Routing Engine of the ingress router, verify the S-BFD session of the secondary path also similarly.
Configuring Static Adjacency Segment Identifier for Aggregate Ethernet Member Links Using Single-Hop Static LSP
In a network where aggregate Ethernet (AE) bundles are in use, an aggregate link could be a bundle of any number of physical links. The traffic sent over these AE bundle interfaces are forwarded on any of the member links of an AE interface. The traffic can take any physical link based on the hash defined for load-balancing the traffic, which makes it difficult to isolate which links have gone bad or are dropping the traffic. One way to test the forwarding path available in the network is to add a single-hop static label switched path (LSP) with the next hop pointing to a specific member link of the AE interface.
The default label operation for the static LSPs must be pop and forward. When a packet hits these labeled routes, the packet is forwarded on to a specific member link. A unique label is used to identify the member link. These labels are referred to as adjacency segment identifiers (SID) and are statically provisioned.
You can control the flow of the packets in the network by constructing a label stack in controller, which includes the labels allocated by all transit static LSP. Operation, Administration, and Maintenance (OAM) packets are crafted and injected into the network with entire label-stack.
When a packet hits this label route the label is popped and traffic is forwarded on the member link specified in the configuration. A destination MAC is chosen while forwarding the packet, the destination Mac is the aggregate interface MAC address (selected based on nexthop address configured).
When the member link goes down and aggregate interface is up, then the route corresponding to that member link is deleted. When an aggregate interface goes down, then all the routes corresponding to member links of the aggregate interface are deleted. When the child physical interface is LACP detached but the child physical interface is up, the labeled route for the child link is deleted. In the case of LACP detach, if the member link is up and invalid forwarding state, then the OAM packets is dropped in the PFE when the child physical interface is detached.
Use the following example to configure single-hop static LSP for an AE member link.
Define a static label range.
user@host# set protocols mpls label-range static-label-range 1000000 1048575;Note:We recommend configuring the default static label range of 1000000-1048575 for the static LSP. If you wish to configure a label range other than the default static label range, configure multiple ranges.
Create a static LSP for the AE member link from the segment routing local block (SRLB) pool of the static label range.
user@host# set protocols mpls static-label-switched-path statc-lsp transit 100001 pop next-hop 10.1.1.1 member-interface ge-0/0/0
In this configuration, a transit labelled router is installed in mpls.0, pops the label, and forwards the packet down the next hop. The next hop address is mandatory for broadcast interfaces (such as ge-, xe-, ae-) and the if-name is used for P2P interfaces (such as so-). The address is required for broadcast interfaces because the next hop IP address is used to pick the destination MAC address. The source MAC address for the packet is the AE’s MAC address.
The sample outputs display the member link name in the next hop output:
show mpls static-lsp extensive
user@host> show mpls static-lsp extensive Ingress LSPs: Total 0, displayed 0, Up 0, Down 0 Transit LSPs: LSPname: static-lsp1, Incoming-label: 1000001 Description: verify-static-lsp-behavior State: Up, Sub State: Traffic via primary but unprotected Nexthop: 10.2.1.1 Via ae0.0 -> ge-0/0/0 LabelOperation: Pop Created: Thu May 25 15:31:26 2017 Bandwidth: 0 bps Statistics: Packets 0, Bytes 0
show route label label-name extensive
user@host> show route label 1000001 extensive
mpls.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
1000001 (1 entry, 1 announced)
TSI:
KRT in-kernel 1000001/52 -> {Pop }
*MPLS Preference: 6
Next hop type: Router, Next hop index: 611
Address: 0xb7a17b0
Next-hop reference count: 2
Next hop: 10.2.1.1 via ae0.0 -> ge-0/0/0 weight 0x1, selected
Label operation: Pop
Load balance label: None;
Label element ptr: 0xb7a1800
Label parent element ptr: 0x0
Label element references: 1
Label element child references: 0
Label element lsp id: 0
Session Id: 0x15d
State: <Active Int>
Age: 3:13:15 Metric: 1
Validation State: unverified
Task: MPLS
Announcement bits (1): 1-KRT
AS path: I
Label 188765184Computing Delay Optimized Intradomain and Interdomain Segment Routing Paths
- Delay-based Metrics for Traffic Engineered Paths Overview
- Benefits of Delay-based Metrics for Path Computation
- DCSPF-based Computation with Delay Metrics for SR Path Overview
- Delay Metrics for Interdomain and Intradomain Use Case Overview
- Delay Metrics in Optical Networks Use Case
Delay-based Metrics for Traffic Engineered Paths Overview
Leveraging dynamic delay-based metrics is becoming a desirable attribute in modern networks. Delay-based metrics is essential for a Path Computation Element (PCE) to compute traffic engineered paths. You can use delay-based metrics to steer packets on the least latency paths, or the least delay path. To do this, you need to measure the delay on every link and advertise it using a suitable routing protocol (IGP or BGP-LS), so that the ingress has the per link delay properties in its TED.
To understand how to advertise the delay on each link, or turn on link measurements, see How to Enable Link Delay Measurement and Advertising in ISIS.
The following sequence of events happen when you measure, advertise, and compute the detection of changes in the network and calculate traffic engineered path with shortest latency:
- Detect changes in the network by measuring the latency, with synthetic probes, router-to-router.
- Flood the results to ingress nodes through IGP extended TE-metric extensions.
- Advertise the results to centralized controllers with corresponding BGP-LS extensions.
- Compute IGP-based shortest cumulative latency metric paths (Flex-algo).
- Compute traffic-engineered explicit paths (source to destination) with shortest cumulative latency or delay metrics (SR-TE).
Benefits of Delay-based Metrics for Path Computation
- Deploy value-added services based on the lowest latency throughout the network.
- Measure per path latency (minimum, maximum, average) using delay-based metrics.
- Steer delay sensitive services (such as VPN or 5G services) on ultra-low latency SR optimized paths.
DCSPF-based Computation with Delay Metrics for SR Path Overview
Using the distributed Constrained Shortest Path First (CSPF) for segment routing LSP feature, you can compute a segment routing LSP locally on the ingress device according to the constraints you have configured. With this feature, the LSPs are optimized based on the configured constraints and metric type (traffic-engineering or IGP). The LSPs are computed to utilize the available ECMP paths to the destination with segment routing label stack compression enabled or disabled.
You can configure distributed CSFP to run on multiple headends and do path computation
independently on each headend. You can apply compute profile on the source path (source
packet routing path). If you have configured compute profile optimized for delay average,
you can also additionally apply a constraint called the
delay-variation-threshold. When you configure a value for
delay-variation-threshold, any link exceeding the threshold value would
be excluded from path computation.
To configure delay metrics for DCSPF-based computation for SR path, you need to enable the
delay configuration statement at the [edit protocols
source-packet-routing compute-profile profile-name metric-type
delay] hierarchy level. You can configure the delay metrics such as minimum,
maximum, average, and delay variation threshold for path calculation.
minimum—Minimum delay metric value from TED for cumulative lowest latency path calculation.average—Average delay metric value from TED for cumulative lowest latency path calculation.maximum—Maximum delay metric value from TED for cumulative lowest latency path calculation.delay-variation-threshold—Link delay variation threshold (1..16777215). Any link exceeding the delay variation threshold would be excluded from path calculation. The delay variation threshold is independent of whether you are doing optimization for minimum, maximum, or average. Thedelay-variation-thresholdconfiguration statement appears at these hierarchy levels:-
[
edit protocols source-packet-routing compute-profile profile-name metric-type delay] -
[
edit protocols source-packet-routing compute-profile profile-name metric-type delay minimum] -
[
edit protocols source-packet-routing compute-profile profile-name metric-type delay maximum] -
[
edit protocols source-packet-routing compute-profile profile-name metric-type delay average]
-
You can configure delay metrics at the following CLI hierarchy:
[edit]
protocols {
source-packet-routing {
compute-profile <name> {
metric-type delay {
minimum;
maximum;
average;
delay-variation-threshold <value>;
}
}
}
}
Delay Metrics for Interdomain and Intradomain Use Case Overview
For the intra-domain case (path resides within a single domain), the link delay is taken
into consideration when doing path computation. Delay metrics for segment routing path
computation is supported on both compressed SIDs and uncompressed SIDs. If you have
uncompressed SIDs, then adjacency segments for segment lists is used to produce multiple
segment lists if there are equal costs. You can configure uncompressed SIDs using the
no-label-stack-compression configuration statement at the [edit
protocols source-packet-routing compute-profile profile-name]
hierarchy level. This provides a fully expanded path using adjacency SIDs. See compute-profile for more information.
The following is a sample configuration for delay metrics:
[edit protocols source-packet-routing]
user@host# show
compute-profile profile1 {
no-label-stack-compression;
metric-type {
delay {
minimum;
delay-variation-threshold 300;
}
}
}
For optical path computation, it is recommended to use the delay metrics as minimum. Minimum is the default configuration.
For interdomain (multi-domain) use case, where there are multiple autonomous systems, you
can use express segments to configure link delays for path computation. Express segments are
links that connect border nodes or ASBRs. See Express Segment LSP Configuration to learn about
express segments. You can configure the delay or inherit the delay of the underlying LSP in
the express segment. You can configure delay at the [edit protocols
express-segments segment-template template-name metric]
hierarchy level and set the values for minimum, maximum, and average delays.
You can configure delay metrics in an express segment at the following CLI hierarchy:
[edit]
protocols {
express-segments {
segment-template <name> {
metric delay [ min <value> | avg <value> | max <value>
}
}
}
For interdomain path computation, you can assign delay metrics on BGP EPE links. You can
configure a value for delay-metric at the [edit protocols bgp group
group-name neighbor ip address
egress-te-adj-segment segment-name egress-te-link attribute]
hierarchy level as shown below:
[edit]
protocols {
bgp {
group <name> {
type external;
}
neighbor <ip_addr> {
egress-te-adj-segment <name> {
egress-te-link-attribute {
delay-metric <value>
}
}
}
}
}
Delay Metrics in Optical Networks Use Case
The following topologies depict an example of an optical use case. Optical protection and restoration solutions result in the underlying physical attributes, mainly path length, changing due to link failures and subsequent DWDM network optimization.
In figure, the link between A and C is through the optical nodes O1 and O3 and has a latency of 10 microseconds. In figure, you can see a link failure between optical nodes O1 and O3 and that the actual optical connection is rerouted through the optical node O2. This increases the latency of 15 microseconds. The metric for the link that connects A and B changes dynamically between time=0 and time=1.
When a change in the per link delay is detected by the ingress, the ingress triggers recomputation of the delay optimized path and the headend router reroutes the path over the next available least latency path. The change in the link delay may result in the ingress choosing another set of links that has the least latency path. In figure B, you can see there is a change in the link between the path A and C and the headend router reroutes and selects the path A-B-C as shown in the topology.
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.