Understanding Source Packet Routing in Networking (SPRING)
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. In this context, the term ’source’ means ’the point at which the explicit route is imposed’. Starting with Junos OS Release 17.2R1, segment routing for IS-IS and OSPFv2 is supported on QFX5100 and QFX10000 switches.
Starting with Junos OS Release 17.3R1, segment routing for IS-IS and OSPFv2 is supported on QFX5110 and QFX5200 switches.
Starting in Junos OS Release 20.3R1, Segment routing support for OSPF and IS-IS protocols to provide basic functionality with Source Packet Routing in Networking (SPRING).
Essentially segment routing engages IGPs like IS-IS and OSPF for advertising two types of network segments or tunnels:
First, a strict forwarded single-hop tunnel that carries packets over a specific link between two nodes, irrespective of the link cost, referred to as adjacency segments.
Second, a multihop tunnel using shortest path links between two specific nodes, referred to as node segments.
Ingress routers can steer a packet through a desired set of nodes and links by pre-appending the packet with an appropriate combination of tunnels.
Segment routing leverages the source routing paradigm. A node 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 node 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 can be applied to the IPv6 architecture, with a new type of routing extension header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing extension header. The segment to process is indicated by a pointer in the routing extension header. Upon completion of a segment, the pointer is incremented.
Traffic engineering shortcuts are enabled for labeled IS-IS segment routes, when you configure shortcuts at the following hierarchy levels:
[edit protocols is-is traffic-engineering family inet] for IPv4 traffic.
[edit protocols is-is traffic-engineering family inet6] for IPv6 traffic.
When source packet routing is deployed in the network, the data center, backbone, and peering devices, switch MPLS packets with a label stack built by the source of the traffic; for example, data center servers. In Junos OS Release 17.4R1, the source-routed traffic co-exists with traffic taking RSVP signaled paths, and source routing is implemented as regular label switching through mpls.0 table using the label operations – pop, swap (to the same label value), and swap-push (for interface protection). In all the cases, traffic can be load balanced between multiple Layer 3 interfaces, or within an aggregate interface. Starting in Junos OS Release 17.4R1, the traffic statistics in a segment routing network can be recorded in an OpenConfig compliant format for the Layer 3 interfaces. The statistics is recorded for the Source Packet Routing in Networking (SPRING) traffic only, excluding RSVP and LDP-signaled traffic, and the family MPLS statistics per interface is accounted for separately. The SR statistics also includes SPRING traffic statistics per link aggregation group (LAG) member, and per segment identifier (SID). To enable recording of segment routing statistics, include sensor-based-stats statement at the [edit protocol isis source-packet-routing] hierarchy level.
Prior to Junos OS Release 19.1R1, sensors were available for collecting segment routing statistics for MPLS transit traffic only, which is MPLS-to-MPLS in nature. Starting in Junos OS Release 19.1R1, on MX Series routers with MPC and MIC interfaces and PTX Series routers, additional sensors are introduced to collect segment routing statistics for MPLS ingress traffic, which is IP-to-MPLS in nature. With this feature, you can enable sensors for label IS-IS segment routing traffic only, and stream the statistics to a gRPC client.
You can enable the segment routing statistics for MPLS ingress traffic using the egress option under the per-sid configuration statement. The resource name for the per-sid egress functionality is:
You can view the label IS-IS route association with the sensors using the show isis spring sensor info command output. This command does not display counter values of the actual sensors.
The segment routing statistics records are exported to a server. You can view segment routing statistics data from the following the OpenConfig paths:
Graceful Routing Engine switchover (GRES) is not supported for segment routing statistics.
Nonstop active routing (NSR) is not supported for label IS-IS. During a Routing Engine switchover, a new sensor is created in the new primary Routing Engine, replacing the sensor created by the previous primary Routing Engine. As a result, at the time of a Routing Engine switchover, the segment routing statistics counter start from zero.
Graceful restart is not support for label IS-IS.
In case of graceful restart, the existing sensor is deleted and a new sensor is created during IS-IS initialization. The segment routing statistics counter restarts from zero.
In-service software upgrade (ISSU) and nonstop software upgrade (NSSU) are not supported. In such cases, the segment routing statistics counter is restarted.
Zero-statistics segment routing data is suppresses and does not get streamed to the gRPC clients.