Provision LSPs

You can provision LSPs by using either PCEP or NETCONF. Whether provisioned using PCEP or NETCONF, LSPs can be learned via PCEP or by way of device collection. If learned by way of device collection, then the NorthStar Controller requires periodic device collection to learn about LSPs and other updates to the network. See Scheduling Device Collection for Analytics for more information. Once you create device collection tasks, the NorthStar Controller discovers LSPs provisioned via NETCONF. Unlike PCEP, the NorthStar Controller with NETCONF supports logical systems.

For more information about managing logical nodes, see Considerations When Using Logical Nodes later in this topic.

For information on system settings that can affect path computation, see Subscribers and System Settings.

Provisioning LSPs

To provision an LSP, select Network Management > Provisioning > Provision LSP.. The Provision LSP window is displayed as shown in Figure 1.

Note:

For IOS-XR devices, before provisioning LSPs via NETCONF, you must first run device collection. See Scheduling Device Collection for Analytics for instructions.
For Huawei devices:
- NorthStar controller only creates tunnels at the interfaces and does not map the traffic onto the tunnel.
- Only RSVP LSPs are supported. While creating a tunnel interface:
  - You must enter a unique tunnel-id for each tunnel in user properties.
  - The tunnel name should be in the format Tunnelx/y/z, where x is between 0 and 31, y is between 0 and 15, and z is between 0 and 65535. A PCEP provisioned tunnel can have any string as its name; there are no restrictions
- Segment routing is not supported.
- Diverse, multiple, and container LSPs are not supported.

Figure 1: Provision LSP

Note:

You can also reach the Provision LSP window from the Tunnel tab of the network information table by clicking Add at the bottom of the pane.

As shown in Figure 1, the Provision LSP window has several tabs:

Properties
Path
Advanced
Design
Scheduling
User Properties

From any tab, you can click Preview Path at the bottom of the window to see the path drawn on the topology map, and click Submit to complete the LSP provisioning. These buttons become available as soon as Name, Node A, and Node Z have been specified.

Table 1 describes the data entry fields in the Properties tab of the Provision LSP window.

Table 1: Provision LSP Properties Fields
Field	Description
Provisioning Method	Use the drop-down menu to select PCEP or NETCONF. The default is NETCONF. See Templates for Netconf Provisioning for information about using customized provisioning templates to support non-Juniper devices. Note: For IOS-XR routers, NorthStar LSP NETCONF-based provisioning has the same capabilities as NorthStar PCEP-based provisioning. When provisioning LSPs via NETCONF, the PCS does not allocate bandwidth until it receives a response from either the configServer or PCEP. This is a different behavior from provisioning LSPs via PCEP where the PCS allocates bandwidth immediately. When provisioning LSPs via NETCONF one at a time, there is the potential for a provisioning order to be sent before the response to a previous provisioning order is received—which means the second order might not have correct bandwidth allocation information and NorthStar might not be able to provide ECMP. We recommend provisioning multiple LSPs via NETCONF in one operation (bulk provisioning) in order to avoid this issue.
Name	A user-defined name for the tunnel. Only alphanumeric characters, hyphens, and underscores are allowed. Other special characters and spaces are not allowed. Required for primary LSPs, but not available for secondary or standby LSPs. If you are creating multiple parallel LSPs that will share the same Design parameters, the Name you specify here is used as the base for the automatic naming of those LSPs. See the `Count` and `Delimiter` fields on the Advanced tab for more information.
Node A	Required. The name or IP address of the ingress node. Select from the drop-down list. You can start typing in the field to narrow the selection to nodes that begin with the text you typed.
Node Z	Required. The name or IP address of the egress node. Select from the drop-down list. You can start typing in the field to narrow the selection to nodes that begin with the text you typed.
IP Z	IP address of Node Z.
Provisioning Type	Use the drop-down menu to select RSVP or SR (segment routing).
Admin Status	The Path Computation Server (PCS) uses the administration status of the LSP to decide whether to route or provision, or both route and provision the LSP. Select one of the following options as the administration status: Up—If you select this option, the PCS routes and provisions the LSP. Planned—If you select this option, the PCS routes the LSP and reserves capacities for the LSP. However, the PCS doesn’t provision the LSP. Shutdown—If you select this option, the PCS neither routes nor provisions the LSP. The LSP is maintained in the datastore and is associated with a persist state so that the LSP can be brought back up at a later time, if required. When you modify the admin status of the LSP from the Modify LSP page or Modify LSP (N LSP) page, the following actions take place: If you modify the status from Up to Planned—The PCS deletes the LSP from the network but retains the current reservations for the LSP. In addition, the PCS demotes the setup and hold priorities for the LSP. This is done to ensure that in case of network failure, the planned LSP doesn’t take precedence over the LSPs with Admin Status Up, for routing. If you modify the status from Planned to Up—The PCS provisions the LSP per the already calculated path. If you modify the status from Up to Shutdown—The PCS removes the LSP (and its associated reservations) from the network. The LSP is maintained in the datastore and is associated with a Persist state so that the LSP can be brought back up when required. If you modify the status from Shutdown to Up—The PCS routes the LSP and generates a provisioning order for the LSP. If you modify the status from Planned to Shutdown—The PCS removes the LSP (and its associated reservations) from the network. The LSP is maintained in the datastore and is associated with a Persist state so that the LSP can be brought back up when required. If you modify the status from Shutdown to Planned—The PCS routes the LSP and reserves capacities for the LSP. However, the PCS doesn’t provision the LSP.
Path Type	Use the drop-down menu to select primary, secondary, or standby as the path type.
secondary (or standby) for	LSP name. Required and only available if the Path Type is set to secondary or standby. Identifies the LSP for which the current LSP is secondary (or standby). Note: The operational status of a secondary LSP is displayed as Unknown until the secondary LSP is provisioned.
Path Name	Name for the path. Required and only available for primary LSPs if the provisioning type is set to RSVP, and for all secondary and standby LSPs.
Planned Bandwidth	Required. Bandwidth immediately followed by units (no space in between). Valid units are: B or b (bps) M or m (Mbps) K or k (Kbps) G or g (Gbps) Examples: 50M, 1000b, 25g. If you enter a value without units, bps is applied.
Setup	Required. RSVP setup priority for the tunnel traffic. Priority levels range from 0 (highest priority) through 7 (lowest priority). The default is 7, which is the standard MPLS LSP definition in Junos OS.
Hold	Required. RSVP hold priority for the tunnel traffic. Priority levels range from 0 (highest priority) through 7 (lowest priority). The default is 7, which is the standard MPLS LSP definition in Junos OS.
Planned Metric	Static tunnel metric. Type a value or use the up and down arrows to increment or decrement by 10.
Comment	Free-form comment describing the LSP.

The Path tab includes the fields shown in Figure 2 and described in Table 2.

Figure 2: Provision LSP Window, Path Tab

Table 2: Provision LSP Window, Path Fields
Field	Description
Selection	Use the drop-down menu to select dynamic, required, or preferred. Select dynamic to allow NorthStar to compute a path without imposing any path restrictions. Select required to prevent NorthStar from using any other path for this LSP. If the required path is not viable and available, the LSP is down and NorthStar does not perform computation to look for an alternate path. Select preferred to instruct NorthStar to use this path over any other, as long as it is viable and available. If it is not viable and available, NorthStar computes an alternate path.
Hop 1	Only available if your initial selection is either required or preferred. Enter the first hop and specify whether it is strict or loose. To add an additional hop, click the + button. Note: When specifying a loose hop, you can choose from all links in the network. When specifying a loose hop for a required path, anycast group SIDs are also available for selection.

The Advanced tab includes the fields shown in Figure 3 and described in Table 3.

Figure 3: Provision LSP Window, Advanced Tab

Table 3: Provision LSP Window, Advanced Tab Fields
Field	Description
Count	Enables creation of multiple parallel LSPs between two endpoints. These LSPs share the same design parameters as specified in the Provision LSP window Design tab. Use the up and down arrows to select the number of parallel LSPs to be created. Note: Creating parallel LSPs in this manner is different from using Provision Multiple LSPs where the Design parameters are configured separately for each LSP created.
Delimiter	Used in the automatic naming of parallel LSPs that share the same design parameters. NorthStar names the LSPs using the Name you enter in the Properties tab and appends the delimiter value plus a unique numerical value beginning with 1 (myLSP_1, myLSP_2, for example). This field is only available when the `Count` value is greater than 1.
Bandwidth Sizing	If set to `yes`, the LSP is included in periodic re-computation of planned bandwidth based on aggregated LSP traffic statistics. Note: This field is not available if Provisioning Method on the Properties tab is set to NETCONF or PCEP. See Bandwidth Management for more information.
Adjustment Threshold (%)	This setting controls the sensitivity of the automatic bandwidth adjustment. The new planned bandwidth is only considered if it differs from the existing bandwidth by the value of this setting or more. Only available (and then required) if Bandwidth Sizing is set to `yes`. The default value is 10%. Note: Bandwidth sizing is supported only for PCE-initiated and PCC-delegated LSPs. Although nothing will prevent you from applying this attribute to a PCC-controlled LSP, it would have no effect.
Minimum Bandwidth	Minimum planned bandwidth immediately followed by units (no space in between). Valid units are: B or b (bps) M or m (Mbps) K or k (Kbps) G or g (Gbps) Examples: 50M, 1000b, 25g. If you enter a value without units, bps is applied. This value is only available (and then required) if Bandwidth Sizing is set to `yes`. The default value is 0. Note: Bandwidth sizing is supported only for PCE-initiated and PCC-delegated LSPs. See Bandwidth Management for more information.
Maximum Bandwidth	Maximum planned bandwidth immediately followed by units (no space in between). Bandwidth sizing can be done up to this maximum. Valid units are: B or b (bps) M or m (Mbps) K or k (Kbps) G or g (Gbps) Examples: 50M, 1000b, 25g. If you enter a value without units, bps is applied. This value is only available if Bandwidth Sizing is set to `yes`. There is no default value. Note: Bandwidth sizing is supported only for PCE-initiated and PCC-delegated LSPs. Although nothing will prevent you from applying this attribute to a PCC-controlled LSP, it would have no effect. See Bandwidth Management for more information.
Min Variation Threshold	Modifies the sensitivity of the automatic bandwidth adjustment. This value is only available (and then required) if Bandwidth Sizing is set to `yes`. The default value is zero. See Bandwidth Management for more information.
Coloring Include All	Double click in this field to display the Modify Coloring Include All window. Select the appropriate check boxes. Click `OK` when finished.
Coloring Include Any	Double click in this field to display the Modify Coloring Include Any window. Select the appropriate check boxes. Click `OK` when finished.
Coloring Exclude	Double click in this field to display the Modify Coloring Exclude window. Select the appropriate check boxes. Click `OK` when finished.
Symmetric Pair Group	When there are two tunnels with the same end nodes but in opposite directions, the path routing uses the same set of links. For example, suppose Tunnel1 source to destination is NodeA to NodeZ, and Tunnel2 source to destination is NodeZ to NodeA. Selecting Tunnel1-Tunnel2 as a symmetric pair group places both tunnels along the same set of links. Tunnels in the same group are paired based on the source and destination node.
Create Symmetric Pair	Select the check box to create a symmetric pair.
Diversity Group	Name of a group of tunnels to which this tunnel belongs, and for which diverse paths is desired.
Diversity Level	Use the drop-down menu to select the level of diversity as default (no diversity), site, link, or SRLG. Site diversity is the strongest—it includes SRLG and link diversity. SRLG diversity includes link diversity. Link diversity is the weakest.
Route on Protected IP Link	Select the check box if you want the route to use protected IP links as much a possible.
Binding SID	Only available if the Provisioning Method is set to NETCONF and the Provisioning Type is set to SR. Numerical binding SID label value. See Segment Routing for more information.
Color Community	Color assignment for the SR LSP. Only available if the Provisioning Type is set to SR. You can set color for both NETCONF and PCEP LSPs.
Use Penultimate Hop as Signaling Address For All Traffic/For Color Community X	When selected, the PCS uses the penultimate hop as the signaling address for EPE. Only available if the Provisioning Type is set to SR. If no color community is specified, the setting applies to all traffic. If a color community is specified, the setting applies to traffic in that color community.

The Design tab includes the fields shown in Figure 4 and described in Table 4.

Figure 4: Provision LSP Window, Design Tab

Table 4: Provision LSP Window, Design Fields
Field	Description
Routing Method	Use the drop-down menu to select a routing method. Available options include default (NorthStar computes the path), adminWeight, delay, constant, distance, ISIS, OSPF, and routeByDevice (router computes part of the path).
Max Delay	Type a value or use the up and down arrows to increment or decrement by 100.
Max Hop	Type a value or use the up and down arrows to increment or decrement by 1.
Max Cost	Type a value or use the up and down arrows to increment or decrement by 100.
High Delay Threshold	Type a value or use the up and down arrows to increment or decrement by 100.
Low Delay Threshold	Type a value or use the up and down arrows to increment or decrement by 100.
High Delay Metric	Type a value or use the up and down arrows to increment or decrement by 100.
Low Delay Metric	Type a value or use the up and down arrows to increment or decrement by 100.

When provisioning via PCEP, the NorthStar Controller’s default behavior is to compute the path to be used when provisioning the LSP. Alternatively, you can select the routeByDevice routing method in the Design tab, in which the router controls part of the routing. This alternate routing method is only meaningful for three types of LSP:

RSVP TE PCC-controlled LSP

Note:
For provisioning via NETCONF, routeByDevice is the default routing method.
Segment routing PCEP-based LSP
Segment routing NETCONF-based LSP

To select routeByDevice as the routing method:

On the Design tab, select routeByDevice from the Routing Method drop-down menu.
On the Path tab, select dynamic from the Selection drop-down menu.

The LSP is then set up to be provisioned with the specified attributes, and no explicit path.

The Scheduling tab relates to bandwidth calendaring. By default, tunnel creation is not scheduled, which means that tunnels are provisioned immediately upon submission. Click the Scheduling tab in the Provision LSP window to access the fields for setting up the date/time interval. Figure 5 shows the Scheduling tab of the Provision LSP window.

Figure 5: Provision LSP Window, Scheduling Tab

Select Once to select start and end parameters for a single event. Select Daily to select start and end parameters for a recurring daily event. Click the calendar icon beside the fields to select the start and end dates, and beginning and ending times.

Note:

The time zone is the server time zone.

In the User Properties tab shown in Figure 6, you can add provisioning properties not directly supported by the NorthStar UI. For example, you cannot specify a hop-limit in the Properties tab when you provision an LSP. However, you can add hop-limit as a user property in the User Properties tab.

Figure 6: Provision LSP Window, User Properties Tab

The following steps describe how to utilize User Properties for LSP provisioning:

Access the NETCONF template file that is used for adding new LSPs (lsp-add-junos.hjson), located in the /opt/northstar/netconfd/templates/ directory.

At the edit > protocols > mpls > label-switched-path hierarchy level, add the statements needed to provision with the property you are adding. For example, to provision with a hop-limit of 7, you would add the lines below in bold:

The result of adding these statements is that if hop-limit, with the value defined in the user properties, is present, then the provisioning statement is executed. You could also edit the template used for modifying LSPs (lsp-modify-junos.hjson).

Restart netconfd so the changes can take effect:

Add the user property and corresponding value in the User Properties tab of the Provision LSP window (see Figure 6).

Verify the router configuration:

Click Submit when you have finished populating fields in all of the tabs of the Provision LSP window. The LSP is entered into the work order management process.

To modify an existing LSP, select the tunnel on the Tunnels tab in the network information table and click Modify at the bottom of the table. The Modify LSP window is displayed, which is very similar to the Provision LSP window.

If you modify an existing LSP via NETCONF, NorthStar Controller only generates the configuration statements necessary to make the change, as opposed to re-generating all the statements in the full LSP configuration as is required for PCEP.

Note:

After provisioning LSPs, if there is a PCEP flap, the UI display for RSVP utilization and RSVP live utilization might be out of sync. You can display those utilization metrics by navigating to Performance in the left pane of the UI. This is a UI display issue only. The next live update from the network or the next manual sync using Sync Network Model (Administration > System Settings > Advanced Settings) corrects the UI display. In the System Settings window, you toggle between General and Advanced Settings using the button in the upper right corner of the window.

Note:

If you are configuring high availability (HA), execute steps 1 through 3 on the active and standby servers.

Considerations When Using Logical Nodes

NorthStar fully supports creating and provisioning LSPs that incorporate logical nodes. In the Junos OS, PCEP is not supported for logical nodes, but NorthStar can still import logical node information using NETCONF-based device collection. When a device collection task is run, NorthStar uses the Junos OS show configuration command on each router to obtain both physical and logical node information. The logical device information must then be correlated with the physical before LSPs using logical devices can be provisioned.

Use the following procedure:

Navigate to Adminstration > Device Profile.
Click the Sync with Live Network button to create (or update) the physical and logical devices list. The NorthStar BGP-LS session toward the Junos VM automatically discovers both the physical and logical devices in the topology. However, there is no automatic correlation between the two.

In the Topology view, navigate to the Node tab of the network information table to confirm that the PCEP Status is UP for all the physical nodes as shown in Figure 7. Logical nodes are blank in the PCEP Status column because there is no PCEP for logical nodes.

Figure 7: PCEP Status Column Showing Physical and Logical Nodes
In the Device Profile window, enable NETCONF for the physical devices (if not already done).

Select one or more devices and click Modify to display the Modify Device window. On the Access tab, click the check box for Enable Netconf. Click Modify in the lower right corner of the window to complete the modification.
Test the NETCONF connectivity of the devices.

Select one or more devices in the device list and click Test Connectivity. In the Profile Connectivity window, click Start. The test is complete when the green (pass) or red (fail) status icons are displayed. Figure 8 shows an example.

Figure 8: Connectivity Test Results
In Topology view, check the Node tab of the network information table to ensure that the NETCONF status column now reports UP for physical devices.
Create and run a device collection task to obtain updated information.

Navigate to Administration > Task Scheduler and click Add to display the Create New Task window. If you use the Selective Devices option, select only the physical devices. For complete information about the Create new Task windows, see Scheduling Device Collection for Analytics.

When this device collection task is run, NorthStar uses the Junos OS show configuration command on each physical router to obtain both physical and logical node information, and reports it to NorthStar. This step allows NorthStar to correlate each logical node to its corresponding physical node, which you can confirm by examining the network information table, Node tab.

Note:
When you first install NorthStar, the device profile page is empty. Use the Sync with Live Network button to update and synchronize with the live network devices, and update the Node tab in the network information table. The device collection task correlates the logical system with its physical system and also updates LSP information for the logical system since the logical system does not have a PCEP session to report its LSP status.

It is helpful to add two optionally-displayed columns to the Node tab as shown in Figure 9:
- Physical Hostname
- Physical Host IP
Figure 9: Adding Optionally-Displayed Columns

For a logical node, the hostname and IP address in those columns tell you which physical node correlates to the logical node.
Provision LSPs.

Now that the logical nodes are in the NorthStar device list and they are correlated to the correct physical nodes, you can create LSPs that incorporate logical nodes. You do this using the same procedure as for LSPs using only physical nodes except that the provisioning method MUST be specified as Netconf as shown in Figure 10.

Figure 10: Provisioning an LSP That Uses Logical Nodes
Run your device collection task periodically to keep the logical node information updated. There are no real time updates for logical devices.

ON THIS PAGE

Provision LSPs

Provisioning LSPs

Considerations When Using Logical Nodes