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 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. Starting in Junos OS Release 19.4R1, you can configure Juniper Networks devices to advertise selective traffic-engineering attributes without enabling RSVP for segment routing and interior gateway protocol (IGP) deployments. Use the Junos command protocols ospf traffic-engineering advertisement always to configure this, so the TED can be populated properly without the need to enable RSVP.

Note:

Junos OS Release 19.2R1-S1 also supports this configuration.

You can display adjacency SID labels on the map. On the right side of the topology window is a menu bar offering various topology settings. Click the Tools (gear-shaped) icon to bring up the Topology Settings window and select Links. Click the check box for Show Label and select SID A::Z from the corresponding drop-down menu. 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 see an attribute folder for both endA and endZ called SR. 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 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 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.

Note:

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

SR LSPs

SR LSPs can be created using both adjacency SID and node SID labels. An SR LSP 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:

1. 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, Properties tab.

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 router 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 do appear in the router configuration file. While SR LSPs can be provisioned via NETCONF, they can be learned via either PCEP or NETCONF. 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.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. Complete the Name, Node A, and Node Z fields.

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

5. For NETCONF SR LSP provisioning (not applicable to PCEP), you can also 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 drop-down menu, typically either routeByDevice (router computes some of the path) or default (NorthStar computes the path).

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. The provisioning request then enters the Work Order Management process.

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

   • For NETCONF provisioned SR LSPs, once the work order is activated, the corresponding configuration statements appear in the router configuration file.

Viewing the Path

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 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 between vmx105 and vmx106 is used in both directions.

Binding SID

When you provision a pair of binding SID SR LSPs (one going from A to Z and one for the return path from Z to A), a private forwarding adjacency is automatically generated. 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, 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, creating 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 deselect the check box for privateForwardingAdjacency under Link Types as shown in Figure 6. When selected, the adjacencies display as dotted lines on the topology map as shown in Figure 7.

You can tunnel a non-binding SID SR LSP over a binding SID SR LSP, thereby reducing 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 8.

Note:

Tunneling a binding SID SR LSP over another binding SID SR LSP is not supported.

In this display, 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 an SR LSP in a network that has two adjacency SIDs per interface is not supported.

To provision a pair of binding SID SR LSPs, use the procedure for NETCONF SR LSP provisioning, plus:

1. On the Provision LSP window Advanced tab, populate the Binding SID field with a numerical binding SID label value of your choice from the static label range of 1000000 to 1048575. 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 nor collision detection. Note that Junos OS has built-in collision detection, so that if the binding SID label specified is outside the allowed range of 1000000 to 1048575, the router does not allow the configuration to commit. Correspondingly, the Controller Status in the Tunnel tab of the network information table shows the usual indication of FAILED(NS_ERR_INVALID_CONFIG).

2. On the Design tab, select the routing method, default for example.

3. On the Path tab, select the hops in the path.

4. 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 also be the same as in the first LSP in the pair, but it is not required that it be the same.

When the binding SID SR LSP pair is provisioned, the private forwarding adjacency link is automatically created, and 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 has been pushed to the router configuration.

Maximum SID Depth (MSD)

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 routeByDevice as shown in Figure 9. This option allows the router 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.

Note:

When provisioning via PCEP, 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.

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.

PCEP RoutebyDevice Example

In Figure 10, 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 routeByDevice, designated in the Design 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 routeByDevice method. 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).

A possible downside to using routeByDevice 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 have been violated.

The Role of NETCONF Device Collection

SR LSPs provisioned using NETCONF can be learned either by PCEP or by device collection. When learned by device collection, the information is pulled in a non-real-time fashion only when collection tasks are run.

Note:

When you create your NETCONF device collection tasks, be sure you select the 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. See Figure 11.

Figure 11: Select the Check Box to Collect Configuration

Automatic NETCONF collection is also performed every time an SR LSP is provisioned using NETCONF in the NorthStar UI.

Rerouting and Reprovisioning (PCEP-Provisioned SR LSPs)

For PCEP-provisioned 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 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.

Note:

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.

Allow Any SID at First Hop

By default, NorthStar 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 the Junos configuration of set protocols source-packet-routing inherit-label-nexthops.

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

Figure 12 shows the Properties tab of the Modify Node window.

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

Delegating SR LSPs

As of NorthStar Release 6.0.0, you can delegate SR LSPs to NorthStar using the Configure LSP Delegation tool available under Applications in the UI. SR LSPs are included in the list of LSPs eligible for delegation in that tool. 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. 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 UI 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.

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.

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 information about the assignment of color community in the context of NorthStar EPE, see NorthStar Egress Peer Engineering.

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

On-Demand Next-hop, Intra-Domain (Experimental)

The On-Demand Next-hop (ODN) feature gives Junos OS the ability to dynamically create SRTE LSPs when routes resolve over BGP next hops. The SRTE LSPs can then be delegated and managed by NorthStar. To use this feature, you must be running a recent version of Junos 20.4 that supports SR ODN (e.g. JUNOS 20.4I-20200910).

Note:

This feature is being provided for lab and demonstration purposes, but is not recommended for production networks at this time.

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 the 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.

To summarize, the configuration on the device establishes:

• The source routing path template

• The destination network

• The compute profile

See your Junos OS documentation 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). Correspondingly, the dynamic tunnel will be displayed on the NorthStar Tunnel tab.

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

Note:

In the statement above, odnmytmeplate is the name of a particular template.