NorthStar Controller supports Source Packet Routing in Networking (SPRING), also known as segment routing. 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. For more information about segment routing, see Understanding Source Packet Routing in Networking (SPRING).
Junos OS Release 17.2R1 or later is required to utilize NorthStar Controller SPRING features. However, NorthStar Controller does not report the correct record route object (RRO) in the web UI and via the REST API when routers are configured with Junos OS Release 17.2R1. Instead of showing a list of link adjacency SIDs, the web UI and REST API report a list of “zero” labels. This issue has been fixed in Junos OS Releases 17.2.R1-S1 and 17.2R2.
OSPF is not supported for SPRING.
Segment ID Labels
Adjacency segment ID (SID) labels (associated with links) and node SID labels (associated with nodes) can be displayed on the topological map.
You can use either BGP-LS peering or IGP adjacency from the JunosVM to the network to acquire network topology. However, for SPRING information to be properly learned by NorthStar when using BGP-LS, the network should have RSVP enabled on the links and the TED database available in the network.
To display adjacency SID labels on the map, select Options in the left side pane of the Topology view, and select the check box for Show Link Labels. Click Settings at the bottom of the left side pane and select Configure Link Label. Click the radio button for the new option, SID A-Z. An example topology map showing adjacency SID labels is shown in Figure 1
To view adjacency SID labels in the network information table, click the down arrow beside any column heading under the Link tab, and click Columns to display the full list of available columns. Click the check boxes beside SID A and SID Z.
When you display the detailed information for a specific link (by double clicking the link in the map or in the network information table), you will see an attribute folder for both endA and endZ called SR (segment routing). You can drill down to display attributes for each SID as shown in Figure 2. At present, only IPv4 SIDs are supported, and only one per interface.
Node SID labels are displayed a little differently because the value of the label depends on the perspective of the node assigning it. A node might be given different node SID labels based on the perspective of the assigning nodes. To display node SID labels on the topology map, specify the perspective by right-clicking on a node and selecting Node SIDs from selected node. The node SID labels are then assigned from the perspective of that selected node.
For example, Figure 3 shows a topology displaying the SID node labels from the perspective of node vmx101. Note that the node SID label for node vmx106 is 1106.
If you right-click on node vmx104 and select Node SIDs from selected node, the node SID labels on the topology change to reflect the perspective of node vmx104 as shown in Figure 4. Note that the node SID label for node vmx106 is now 4106.
The selected node does not display a node SID label for itself. Any other nodes in the topology map that do not display a node SID label do not have the segment routing protocol configured.
Node SID information is not available in the network information table.
SR-LSP tunnels can be created using both adjacency SID and node SID labels.
An SR-LSP tunnel is a label stack that consists of a list of adjacency SID labels, node SID labels, or a mix of both. To create an SR-LSP, navigate to the Tunnel tab in the network information table and click Add at the bottom of the table to display the Provision LSP window. The Provision LSP window has a Provisioning Type drop-down selection offering RSVP and SR options. Select SR. Complete the remaining fields as needed and click Submit to see the new path highlighted in the topology map.
There are multiple ways to view the details of the path:
The IP address and the SID are the two parts of the explicit route. The IP address part is displayed in the ERO column in the network information table, Tunnel tab. The SID part is displayed in the Record Route column.
Double-click on the tunnel row in the network information table and drill down into the liveProperties to see the details of the ERO.
Use Junos OS show commands on the router. Some examples are:
show spring-traffic-engineering lsp name lsp-name detailto display the LSP status and SID labels.
show route table inet.3to display the mapping of traffic destinations with SPRING LSPs.
If a link in a path is used in both directions, it is highlighted in a different color in the topology, and does not have arrowheads to indicate direction. Figure 5 shows an example in which the link between vmx105 and vmx106 is used in both directions.
To avoid encountering an equipment limitation on the maximum SID depth (MSD), you can use the Routing Method drop-down menu in the Provision LSP window (Design tab) to select routeByPCC as shown in Figure 6. This option allows the router to control part of the routing, so fewer labels need to be explicitly specified.
routeByPCC is to be used when you want to create an SR-LSP with Node SID.
A symptom of encountering the MSD limitation when you are not using routeByPCC is that although a row for the new LSP is added to the network information table, the Op Status is listed as Unknown and the Controller Status is listed as Reschedule in x minutes.
In Figure 7, the routing paths highlighted are the equal cost paths for the t2 LSP.
For t2 in this example:
Node A is vmx101 and Node Z is vmx104.
The provisioning type is SR, designated in the Properties tab of the Provision LSP window.
The routing method is routeByPCC, designated in the Advanced tab of the Provision LSP window. The highlighting of the equal cost paths can only be viewed in the topology if the routing is being done by the PCC.
The mandatory transit router can be part of the generated ERO using the adjacency SID passing through that transit router. However, specifying a mandatory transit router usually increases the label stack depth, violating the MSD. In that case, you can try using the routeByPCC method. To specify a mandatory transit router using Node SID, select the routing method as routeByPCC (Design tab), and specify the loopback of the mandatory transit router as loose hop (Path tab).
A possible downside to using routeByPCC is that other constraints you impose on the LSP links (bandwidth, coloring, and so on) cannot be guaranteed. The NorthStar Controller does not provision the LSP if it sees that the constraints cannot be met. But if the information available indicates that the constraints can be met, the NorthStar Controller provisions the LSP even though those constraints are not guaranteed. Turning on the path optimization timer enables NorthStar to periodically check the constraints.
If the NorthStar Controller later learns (during the execution of an optimization request, for example) that the constraints are no longer being met, it will try to reroute the tunnel by changing the first hop outgoing interface if a specific one was not configured. If that is not possible, the LSP remains in the network, even though constraints are violated.
For SR-LSPs, the router is only able to report on the operational status (Op Status in the Network Information Table) of the first hop. After the first hop, the NorthStar Controller takes responsibility for monitoring the SID labels, and reporting on the operational status. If the labels change or disappear from the network, the NorthStar Controller tries to reroute and re-provision the LSPs that are in a non-operational state.
If NorthStar is not able to find an alternative routing path that complies with the constraints, the LSP is deleted from the network. These LSPs are not, however, deleted from the data model (they are deleted from the network, and persist in the data storage mechanism). The goal is to minimize traffic loss from non-viable SR-LSPs (black holes) by deleting them from the network. Op Status is listed as Unknown when an SR-LSP is deleted, and the Controller Status is listed as No path found or Reschedule in x minutes.
You can mitigate the risk of traffic loss by creating a secondary path for the LSP with fewer or more relaxed constraints. If the NorthStar Controller learns that the original constraints are not being met, it first tries to reroute using the secondary path.
Although NorthStar permits adding a secondary path to an SR-LSP, it is not provisioned as a secondary path to the PCC because the SR-LSP protocol itself does not support secondary paths.
Some additional notes about SR-LSPs:
Provisioning of an SR-LSP can include hop information that somewhat influences the routing. In the Provision LSP window, select the Path tab. There, you can select hops up to the MSD hop limitation that is imposed on the ingress router, and specify Strict or Loose adherence.
NorthStar diverse LSP and multiple LSP provisioning supports segment routing. Select SR from the Provisioning Type drop-down menu on the Provision Diverse LSP or Provision Multiple LSPs window.
Maintenance events are supported with SR-LSPs.