Source Packet Routing in Networking (SPRING) or Segment Routing
-
CBF for SRv6-TE (MX10003, MX10008, and MX10016)—We extend the existing color-based forwarding (CBF) functionality to Segment Routing for IPv6—Traffic Engineering (SRv6-TE) enabling you to adapt to complex network demands. Use this feature to steer traffic across multiple transport tunnels based on class of service (CoS). This approach improves route selection, next-hop resolution, and service quality. Resolver enhancements support SRv6 Segment Identifiers (SIDs) across multipath routes. Use the
preserve-next-hop-hierarchyconfiguration statement to prevent misrouting. -
Performance measurement for SR-MPLS and SRv6 paths (MX204, MX240, MX301, MX304, MX480, MX960, MX9608, MX10003, MX10004, MX10008, MX10016, MX2008, MX2010, and MX2020)—You can now enhance network path selection using the Two-Way Active Measurement Protocol (TWAMP) for performance-based metrics such as latency on Segment Routing over MPLS (SR-MPLS) and Segment Routing over IPv6 (SRv6) paths. This feature allows you to enable end-to-end delay measurement for Segment Routing paths with static segment lists. Employ the new CLI options to configure probe intervals, counts, and advertisement intervals. This helps monitor network performance efficiently, allowing you to make informed path-selection decisions and maintain optimal service levels, particularly in performance-critical environments such as financial networks.
[See delay measurement and show spring-traffic-engineering performance-measurement.]
- Support
for UHP in IS-IS SR-MPLS (MX204, MX240, MX301, MX304, MX480, MX960, MX2008, MX2010,
MX2020, MX10003, MX10004, MX10008, and
MX10016)—Use
ultimate-hop popping (UHP) with IS-IS or OSPF so the egress provider edge can process its
own node
SID. IS-IS
advertises a node SID with the P flag set and E flag unset. In controller-driven segment
routing—traffic engineering (SR–TE), the controller inserts the egress provider edge node
SID beneath the SR-TE binding SID (BSID). If the BSID route fails on the penultimate hop,
the egress provider edge might see its own node SID as the top label instead of
penultimate–hop–popping (PHP). With the P flag set, the provider edge expects UHP and
processes its MPLS label. Include the
ultimate-hop-poppingstatement at the[edit protocols isis source-packet-routing]hierarchy level.[See ultimate-hop-poppingultimate-hop-popping.]
-
SRv6-TE route resolution over BGP without IGP (MX10003, MX10008, and MX10016)—A Segment Routing for IPv6 (SRv6) tunnel consists of paths with Segment Identifiers (SIDs) over an interior gateway protocol (IGP) that steer traffic to a traffic-engineering (TE) path. If IGP is not available, you can configure these SIDs statically and advertise them through external BGP (EBGP). We support this feature on both classic and micro SRv6 SIDs.
Networks that deploy a network orchestrator to steer transit traffic onto a TE path and advertise these transit prefixes using BGP color community typically don't have a service SID. In this case, the last SID must not be removed. The ingress SRv6 TE tunnel acts as a transit tunnel to forward transit traffic with SRv6 encapsulation.
Include the
no-remove-srv6-last-sidstatement at the[edit protocols source-packet-routing]hierarchy level and theuse-ingress-routes-as-transitstatement at the[edit protocols source-packet-routing srv6]hierarchy level.[See no-remove-srv6-last-sid.]
-
Delay normalization for OSPF Flexible Algorithm metrics and advertisements across IGP instances (MX204, MX240, MX301, MX304, MX480, MX960, MX2008, MX2010, MX2020, MX10003, MX10004, MX10008, and MX10016)—Use delay normalization to compute and advertise a normalized delay metric for Flexible Algorithm, to improve path-selection consistency across all interior gateway protocol (IGP) instances. The device normalizes each received delay, compares each value with the previously saved normalized value, and triggers link-state advertisement (LSA) generation when the values differ.
Delay normalization is disabled by default. To enable and configure delay normalization, use the
normalize interval offsetstatement at the[edit protocols ospf area interface delay-measurement]hierarchy level.[See delay-measurement (Protocols OSPF) and How to Configure Flexible Algorithms in OSPF for Segment Routing Traffic Engineering.]
-
Selectively control per-prefix backup paths with OSPF import policy (MX204, MX240, MX301, MX304, MX480, MX960, MX2008, MX2010, MX2020, MX10003, MX10004, MX10008, and MX10016)—You can selectively enable backup paths for specific prefixes to optimize redundancy and resource utilization. By default, a configured backup path applies to all prefixes. To exclude specific prefixes or ranges, create an OSPF import policy and configure the
no-backupoption in thethenclause of the policy to suppress backup path installation for matching routes. You can reserve backup protection for critical prefixes while preventing unnecessary backups for others.[See Understanding Backup Selection Policy for OSPF Protocol.]
-
Preference-based path selection for L-OSPF Flexible Algorithm routes (MX204, MX240, MX301, MX304, MX480, MX960, MX2008, MX2010, MX2020, MX10003, MX10004, MX10008, and MX10016)—You can control path selection by configuring the preference for L-OSPF Flexible Algorithm routes in
inetcolor.0andmpls.0.Configure
flex-algorithm-preferencestatement at the[edit protocols ospf]hierarchy level to prioritize desired routes and improve traffic engineering across IP and MPLS domains.[See How to Configure Flexible Algorithms in OSPF for Segment Routing Traffic Engineering.]
-
Policy-based redistribution of OSPF prefix SIDs across IGP instances (MX204, MX240, MX301, MX304, MX480, MX960, MX2008, MX2010, MX2020, MX10003, MX10004, MX10008, and MX10016)—You can redistribute Segment Routing (SR) prefix-SIDs across OSPF IGP instances using route policy without explicitly specifying a prefix-segment index. This feature standardizes SR labels across instances and improves operational efficiency. Configure a policy with the
from prefix-segmentstatement to match routes carrying prefix-segment information. In thethenclause, useprefix-segment redistributeto inherit segment information from the matched route. We also support stitchingmpls.0routes to enable interoperability between different IGP instances. -
Static SID configuration in SRv6 Manager (MX10003, MX10004, and MX10016)—Configure SRv6 classic, micro node, adjacency SIDs, along with classic END and END-X SIDs, and install them in the routing table without using interior gateway protocols (IGPs) such as IS-IS. Advertise these static routes through a BGP export policy for path computation. This configuration enables controllers to receive static node and adjacency SIDs over BGP and compute SR-TE paths across a domain that does not use IS-IS.