Segment Routing

Segment ID Labels

Adjacency segment ID (SID) labels (associated with links) and node SID labels (associated with nodes) can be displayed on the topology map.

Note:

You can use either BGP-LS peering or IGP adjacency from the virtual machine running Junos OS in the NorthStar Controller to the network to acquire the network topology. However, for SPRING information to be properly learned by NorthStar Controller when using BGP-LS, the network must have RSVP enabled on the links and the TED database available in the network.

To display adjacency SID labels on the map:

1. Click the Tools (gear) icon on the right of the topology map.

   The Topology Settings page appears.

2. Click Links.

   The links settings appears.

3. Select Show Label check box and from the drop-down menu select SID A::Z.

   The adjacency SIDs are displayed on the map.

To view adjacency SID labels in the network information table, on the Link tab, click the down arrow besides any column heading and click Columns to display the full list of available columns. Then, click the check boxes beside SID A and SID Z.

An example topology map showing adjacency SID labels is shown in Figure 1.

To display detailed information for a specific link (by double clicking the link in the topology map or in the network information table), you see an attribute folder (named SR) for both endA and endZ. You can drill down to display attributes for each SID as shown in Figure 2. The endA folder contains details related to node A and endZ folder contains details related to node Z. Currently, NorthStar Controller only supports one adjacency SID per interface.

The value of the Node SID labels depend on the perspective of the node assigning the label. A node might be given different node SID labels based on the perspective of the assigning node. 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 the node that you selected.

Note:

Node SID information is not displayed in the network information table.

For example, Figure 3 shows a topology displaying the SID node labels from the perspective of node vmx101. In this case, 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 map changes to reflect from the perspective of node vmx104. As shown in Figure 4, 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 does not display a node SID label does not have the segment routing protocol configured. You can verify whether SR is enabled on a node by navigating to the Node tab in the network information table, and if the node is SR-enabled, the SR field corresponding to the node will have a check mark.

Create SR LSPs

To create an SR LSP:

1. Navigate to the Tunnel tab in the network information table and click Add at the bottom of the table.

   The Provision LSP window (Properties tab) appears.

2. From the Provisioning Method drop-down menu, select either PCEP or NETCONF.

   • PCEP SR LSPs are PCE-initiated and the associated configuration statements do not appear in the device's configuration file. The advantage of PCEP is that LSP information is provided to NorthStar in real time, so changes in path or state are reflected in the NorthStar UI immediately.

   • NETCONF SR LSPs are statically provisioned and the associated configuration statements appear in the device's configuration file. While SR LSPs can be provisioned via NETCONF, they can also be learned via either PCEP or NETCONF.

     Note:

     In Junos OS Release 18.2 R1, PCEP reporting is limited. The alternative is to learn about the details of the NETCONF-provisioned SR LSPs by way of Device Collection configuration parsing in NorthStar Controller. If you opt to use this method for SR LSP provisioning, be aware that because the primary path details come from device collection configuration parsing, updates are not provided to NorthStar in real time, and NorthStar reports the operation status for these LSPs as Unknown.

     In order for the configuration statements to be included in the router configuration file, SR LSPs must be configured in NorthStar via NETCONF.

3. Configure the Name, Node A, and Node Z fields.

4. From the Provisioning Type drop-down menu, select SR.

5. If you selected NETCONF SR LSP as the provisioning method , you can specify a binding SID label value in the Binding SID field on the Advanced tab. See the Binding SID section for more information.

6. On the Design tab, select the routing method from the Routing Method drop-down menu, typically either routeByDevice (which means that the router computes some of the path) or default (NorthStar computes the path).

   The other routing method options are, adminWeight, delay, constant, distance, ISIS,

   and OSPF.

7. On the Path tab, you can specify any specific hops you want in the path, including private forwarding adjacency links generated by the provisioning of binding SID SR LSP pairs. See the Binding SID section for more information.

8. Click Submit.

   • For both PCEP and NETCONF provisioned SR LSPs, once the, the new path is highlighted in the topology map.

   • For NETCONF provisioned SR LSPs, once the , the corresponding configuration statements appear in the router's configuration file.

   You can view the status of the provisioning on the Work Orders page. For more information on work orders, see Work Order Management.

View the SR Path

To view the details of the SR path, do one of the following:

• The IP address and the SID are the two parts of the explicit route. The IP address is displayed in the ERO column and the SID is displayed in the Record Route column in the Tunnel tab of the network information table.

• Double-click on a tunnel entry 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 detail to display the LSP status and SID labels.

  • show route table inet.3 to 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 (highlighted in red) between vmx105 and vmx106 is used in both directions.

Provision Binding SIDs

Binding SIDs are local labels that can stitch together multiple labels (which represent multiple hops in a path) and advertise it as a single label to reduce the label stack depth while configuring explicit paths.

When you provision a pair of binding SID SR LSPs (one going from A (originating node) to Z (destination node) and one for the return path from Z to A) with NETCONF as the provisioning method, a private forwarding adjacency link is automatically generated. The private forwarding adjacency link can then be selected as a destination when you designate hops for a non-binding SID SR LSP. These adjacencies are named with a specific format, with three sections, separated by colons. For example, binding:0110.0000.0105:privatefa57.

• The names all start with “binding” followed by a colon.

• The center section is the name of the originating node and is followed by a colon (0110.0000.0105: in this example).

• The last section is the name you specified for the binding SID SR LSP in the Name field on the Properties tab of the Provision LSP window (privatefa57 in this example). This name must be the same for the binding SID SR LSPs in both directions, to ensure they can be properly matched during the automatic generation of the corresponding private forwarding adjacency link.

In the topology map, you can opt to display private forwarding adjacency links or not. In the left pane drop-down menu, select Types and then select or clear the check box for privateForwardingAdjacency under Link Types. When you choose to display private forwarding adjacency links,, the adjacencies are shown as dotted lines on the topology map, as shown in Figure 6.

You can tunnel only a non-binding SID SR LSP over a binding SID SR LSP. The binding reduces the number of labels in the label stack (private forwarding adjacency labels can represent multiple hops in the path). An example is shown in Figure 7.

Note:

At this time, NorthStar does not support binding SID label allocation or collision detection. Junos OS has built-in collision detection, so that if the binding SID label specified is outside the allowed range of 1000000 to 1048575, Junos OS does not allow the configuration to commit. The Controller Status in the Tunnel tab of the network information table shows FAILED(NS_ERR_INVALID_CONFIG).

Note:

Figure 7: Reduced Label Stack Example

In this figure, you can see the logical path (traced in amber) of the SR LSP as it goes from vmx101 to vmx105, to vmx107 (by way of a private forwarding adjacency link, and finally to vmx103). You can also see (traced in pink) the path of the private forwarding adjacency link of the binding SID SR LSP. The Record Route column in the network information tunnel shows a label stack with three labels. The second label of the three is the private forwarding adjacency link. Without that adjacency link, the label stack would have required six labels to define the same path.

Note:

Path highlighting for a provisioned SR LSP in a network that has two adjacency SIDs per interface is not supported.

To provision a pair of binding SID SR LSPs:

1. Navigate to the Tunnel tab and click Add.

2. From the Provisioning Method drop-down menu, select NETCONF.

3. Configure the Name, Node A, and node Z fields.

4. From the Provisioning Type drop-down menu, select SR.

5. On the Advanced tab, in the Binding SID field, enter the binding SID label value of your choice from the static label range of 1000000 to 1048575.

   The binding SID label value then becomes the label that represents the path defined by the hops which you specify on the Path tab when you select preferred or required from the Selection drop-down menu.

6. On the Provision LSP window Advanced tab, populate the Binding SID field with a numerical This value then becomes the label that represents the path defined by the hops you specify on the Path tab (the hops that make up the private forwarding adjacency link).

   Note:

   At this time, NorthStar does not support binding SID label allocation or collision detection. Junos OS has built-in collision detection, so that if the binding SID label specified is outside the allowed range of 1000000 to 1048575, Junos OS does not allow the configuration to commit. The Controller Status in the Tunnel tab of the network information table shows FAILED(NS_ERR_INVALID_CONFIG).

7. On the Design tab, select the routing method.

8. On the Path tab, select the number of hops in the path. The hops specified makes up the private forwarding adjacency link.

9. Provision a second binding SID SR LSP in the opposite direction, using the same LSP name as the first LSP in the pair. The binding SID label value can be the same as or different from the first LSP in the pair.

10. Click Submit.

When the binding SID SR LSP pair is provisioned, the private forwarding adjacency link is automatically created, and the link can then be selected as a destination when you designate hops for a non-binding SID SR LSP. Use show commands on the router to confirm that the LSP pair is pushed to the router's configuration.

Maximum SID Depth (MSD)

To avoid encountering such hardware limitations related to the maximum number of labels supported by the device hardware, you can select routeByDevice (Design Tab) as the routing method when you add the segment routing tunnel with node SIDs or by using binding SIDs. When you select the routeByDevice method, NorthStar doesn't compute all the individual hops for the end-to-end path but only computes the first hop, and leaves the subsequent path computation to the routers. This option allows the routers to control part of the routing, so fewer labels need to be explicitly specified.

Note:

• routeByDevice is to be used when you want to create an SR LSP with Node SID.

• When provision an SR LSP, a symptom of encountering the MSD limitation when you are not using routeByDevice 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. No tunnel is created to forward the traffic. Thus, the traffic is forwarded as per the shortest path in the routing table for non-engineered traffic. To resolve this issue, you must request parameters (such as different hops) for the tunnel so that NorthStar Controller computes a path that does not violate the MSD of routers in the path. Alternatively, configure some tunnels with binding SIDs to create forwarding adjacencies so that NorthStar Controller can specify a binding SID in the SID list.

Provisioning of an SR LSP can be based on explicit hop information or can be dynamically routed based on the network conditions. 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. The hop information that you specify in the Path tab when you add an SR LSP influences the routing,

PCEP RoutebyDevice Example

In Figure 8, the routing paths highlighted in yellow are the equal cost paths for the t2 LSP.

For t2 in this example:

• Node A (ingress node) is vmx101 and Node Z (egress node) is vmx104.

• The provisioning type is SR, designated in the Properties tab of the Provision LSP window.

• The routing method is routeByDevice, designated in the Design tab of the Provision LSP window.

  Note:

  The highlighting of the equal cost paths can only be viewed in the topology if the routing is being done by the PCC.

If you need to specify a mandatory transit router in the path, use routeByDevice routing method to reduce the label stack depth. To specify a mandatory transit router using Node SID, select the routing method as routeByDevice (Design tab), and specify the loopback of the mandatory transit router as loose hop (Path tab).

The Role of NETCONF Device Collection

NorthStar Controller learns about SR LSPs provisioned using NETCONF either by using PCEP or by device collection. When learned using by device collection, the information is pulled only when collection tasks are run (not in real time).

Note:

When you create your NETCONF device collection tasks, be sure you select the Configuration check box to collect configuration data. This is necessary for NorthStar to collect and parse the statements in the router configuration file, including those related to SR LSPs. For more information on scheduling device collection tasks, see Scheduling Device Collection for Analytics.

NorthStar Controller performs automatic NETCONF collection every time an SR LSP is provisioned using NETCONF in the NorthStar GUI.

Rerouting and Reprovisioning (PCEP-Provisioned SR LSPs)

For the first hop of PCEP-provisioned SR LSPs, the router is able to only report on the operational status (Op Status in the network information table). After the first hop, the NorthStar Controller monitors the SID labels, and reports on the operational status. If the labels change or disappear from the network, NorthStar Controller tries to reroute and re-provision the LSPs that are in a non-operational state.

If NorthStar Controller is not able to find an alternative routing path that complies with the constraints, the LSP is deleted from the network to minimize traffic loss from non-viable SR LSPs. However, LSPs that are deleted from the network are not deleted from the data model, and persist in the data storage mechanism. For deleted SR LSPs, the Op Status is listed as Unknown, 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. When NorthStar Controller learns that the original constraints are not being met, it first tries to reroute using the secondary path. If the rerouting is successful, the LSP remains Up and is not deleted.

Note:

Although NorthStar Controller permits adding a secondary path to an SR LSP, the secondary path is not provisioned as a secondary path to the PCC because the SR LSP protocol does not support secondary paths.

Allow Any SID at First Hop

By default, NorthStar Controller forces the first hop to be an adjacency SID, regardless of the LSP configuration. You can alter this behavior by modifying an ingress node to support any SID as the first hop. This is supported on PCC devices running Junos OS Release 18.3 or later, and requires that the Junos OS command set protocols source-packet-routing inherit-label-nexthops is configured.

To allow any SID at the first hop:

1. In the network information table, click the node you want to modify, then click Modify in the bottom tool bar.

   The Modify Node pane appears.

2. On the Properties tab, select Allow any SID at first hop.

   By default, the Allow any SID at first hop parameter is disabled (cleared). If enabled, NorthStar Controller does not set an adjacency for newly signaled SR-LSPs (new LSPs or LSPs whose routing is changing).

3. Click Submit.

Delegating SR LSPs

From NorthStar Controller release 6.0.0 onwards, you can delegate SR LSPs to NorthStar Controller from the Configure LSP Delegation page (Applications > Configure LSP Delegation).. See Configure LSP Delegation for more information.

Colored SRTE Policies Using PCEP

Prior to NorthStar 6.2.0, you could apply the Color Community BGP attribute to SR LSPs created using NETCONF.

Note:

You need Junos OS Release 20.4 or later running on a device to apply the Color Community BGP attribute to LSPs provisioned using PCEP.

Starting in NorthStar 6.2.0, this feature is also supported for LSPs provisioned using PCEP.

To apply the color attribute, navigate to the Network Management > Provisioninig > Provision LSP > Advanced tab in the web GUI and specify the color assignment in the Color Community field. This field is only available when the Provisioning Type is set to SR in the Properties tab.

Once a colored SR LSP is successfully provisioned, the corresponding configuration on the device indicates the color community. As shown in the following example, LSP-1 has a color community (<c>) of “123’.

For background information about LSP coloring, see the Junos OS topic: Basic LSP Configuration.

On-Demand Next-Hop, Intra-Domain (Experimental Feature)

Note:

This feature is for lab and demonstration purposes, only. We do not recommend using this feature for production networks.

The On-Demand Next-Hop (ODN) in Junos OS provides the ability to dynamically create segment routing–traffic engineering (SR–TE) LSPs when routes resolve over BGP next hops. The SR–TE LSPs can then be delegated and managed by NorthStar Controller. To use this feature, the device must be configured with a version of Junos 20.4 that supports SR ODN template (example JUNOS 20.4I-20200910).

You must configure the Juniper device for the Junos OS to create the tunnels. The following example shows the prerequisite configuration:

In the routing-options dynamic-tunnels configuration section, specify a template and the endpoint of the dynamic tunnels (the destination network). The destination network could be one device or multiple devices (indicated by a subnet). The template (odnmytemplate in the example) is specified under the protocols source-packet-routing source-routing-path-template. The device configuration also points to a compute profile which can include additional parameters.

The configuration on the device establishes:

• The source routing path template

• The destination network

• The compute profile

See the Juniper CLI Explorer for general guidelines on the syntax and usage of these specific commands.

Once the dynamic LSPs are created by the router, run the show dynamic-tunnels database command to view the new tunnel (see the example below). The dynamic tunnel also appears in the Tunnel tab in the network information table.

To delegate an ODN LSP to NorthStar, configure the following statements on the Junos OS device:

Note:

In the commands above, odnmytmeplate is the name of the template that is configured.