Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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-hierarchy configuration statement to prevent misrouting.

    [See preserve-nexthop-hierarchy (SRv6-TE)]

  • 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-popping statement 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-sid statement at the [edit protocols source-packet-routing] hierarchy level and the use-ingress-routes-as-transit statement 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 offset statement 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-backup option in the then clause 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.0 and mpls.0.

    Configure flex-algorithm-preference statement 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-segment statement to match routes carrying prefix-segment information. In the then clause, use prefix-segment redistribute to inherit segment information from the matched route. We also support stitching mpls.0 routes 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.

    [See Understanding SRv6 Static Segment Identifier.]