Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


LSP Routing Behavior


You can configure NorthStar Controller to automatically reroute LSPs based on interface traffic conditions. The parameters that trigger rerouting can be configured on a global level (applied to all links in the network, in both directions), and you can override global thresholds with link-specific thresholds.

Analytics Parameters Affecting LSP Routing Behavior

Table 1 summarizes the Analytics parameters that affect LSP routing behavior.

Table 1: Analytics Parameters Affecting LSP Routing Behavior



How to Access

Reroute Interval

User-defined, global parameter applied to both Layer 3 link utilization and LSP delay violations. It is the minimum interval after which the controller reacts to any traffic/delay violations. The minimum value is 1 minute and there is no maximum. The smaller the value, the higher the number of rerouting processes, and consequently, the greater the impact on the network. It is a mandatory parameter to trigger a Layer 3 link utilization violation or LSP delay violation rerouting process.

Administration > Analytics

Link Utilization Threshold (%)

User-defined, global parameter applied to all links for Layer 3 link utilization violation scenarios. When this threshold is exceeded, the controller starts moving LSPs away from the congested links. It is a mandatory parameter to enable this controller behavior when Layer 3 link utilization violations occur. Once the link utilization crosses the defined threshold and no previous rerouting processes have occurred within the defined Reroute Interval, the rerouting process is triggered.

Administration > Analytics

Packet Loss Threshold (%)

When packet loss on a link exceeds this threshold, the link is considered unstable and rerouting of traffic to avoid the link is triggered. To achieve this, NorthStar creates a maintenance event for each link, temporarily making the link unavailable for traffic. The event name reflects that it was triggered by packet loss. The event start time is immediate (the link displays a red M indicating it is in maintenance mode) and the end time is set for one hour later. Because this type of maintenance event requires manual completion, the end time is not significant.

See Maintenance Events for information on viewing and managing maintenance events, including how to manually complete a triggered event once the link has been restored to stability.

Administration > Analytics

Link Utilization Threshold, Packet Loss Threshold

User-defined, per-link parameters. Link Utilization Threshold and Packet Loss Threshold work like the global parameters except they are applied to individual links as configured.

Modify an existing link from the network information table (Link tab) by selecting the row and clicking Modify at the bottom of the window.

Max Delay

User-defined, local parameter applied to each LSP. It is a mandatory parameter to trigger any LSP delay violation rerouting process.

Applications > Provision LSP (Design Tab), or modify an existing tunnel from the network information table by selecting the tunnel row and clicking Modify at the bottom of the window.

The REST API can also be used.

For LSP rerouting based on link utilization (bandwidth), you can specify a reroute interval (in minutes) and a link utilization threshold (%). The reroute interval is used to pace back-to-back rerouting events. LSPs are rerouted when both of the following conditions are true:

  • A link utilization threshold has been crossed.

    To avoid unnecessary network churn, NorthStar only considers rerouting an LSP with traffic or a bandwidth reservation when the link utilization threshold has been crossed.

  • No previous utilization-triggered reroute has occurred within the configured reroute interval (in this sense, this timer specifies the minimum time interval between successive reroute actions).

When a threshold has been crossed, LSPs with a lower priority setting and higher traffic are the first to be rerouted, before LSPs with a higher priority setting and lower traffic. If LSP traffic data is available, NorthStar uses it over bandwidth reservation for determining whether an LSP should be re-routed. If LSP traffic data is not available, NorthStar considers LSP bandwidth reservation to make the determination.


For purposes of determining whether an LSP should be rerouted or not, LSP traffic of 0 is considered as LSP traffic available–the LSP has traffic data, but the traffic data is 0. In that case, LSP bandwidth reservation is not used for evaluation.

When utilization for a link crosses a configured threshold, it appears in the Timeline as an event, as does any subsequent rerouting.

For packet loss-based and delay-based rerouting, configuration of real-time performance monitoring (RPM) in Junos and installation of the rpm-log.slax script on the router are prerequisites. See Configuring Routers to Send JTI Telemetry Data and RPM Statistics to the Data Collectors in the NorthStar Controller Getting Started Guide. Once this is done, Junos OS can monitor the links for packet loss and link latency and capture the results as syslog events.

Figure 1 shows the Provision LSP Design tab. The thresholds in this window use the delay information to derive the metrics of the LSPs, which are, in turn, used by the devices when choosing which LSPs to use to forward traffic to a given destination.

Figure 1: Provision LSP, Design Tab Showing Delay Thresholds
LSP, Design Tab Showing Delay Thresholds

Max Delay is used by the NorthStar Path Computation Server (PCS) to constrain the routing path of an LSP. If this constraint is not met, the LSP is not routed by PCS. Max Delay is also used by the NorthStar Telemetry module to trigger LSP rerouting.

High Delay Threshold is used to penalize the LSP so it is not used by the data plane as long as there are other parallel LSPs with lower metrics. The availability of the LSP is not restored once the delay is lower than the High Delay Threshold, until the LSP delay reaches Low Delay Threshold. This prevents excess impact on the network. When the LSP delay drops below the Low Delay Threshold, its metric is set to Low Delay.

Setting Global Parameters

To set the global configuration parameters, navigate to Administration > Analytics. The LSP Routing Behavior window is displayed as shown in Figure 2.

Figure 2: LSP Routing Behavior
LSP Routing Behavior

For LSP rerouting to work, you must select Reroute: Enabled in this window, which causes the additional fields to be displayed. Click Save to configure the global settings.

Setting Link-Specific Thresholds

The link utilization threshold and packet loss threshold can be set at the link level. Link-level configuration of these thresholds overrides the global settings.

Link level thresholds are set in the Link tab of the network information table. Select a link and click Modify at the bottom of the table. The Modify Link window is displayed as shown in Figure 3.

In the Analytics tab, you can set these thresholds on a per-direction basis (A-to-Z, Z-to-A) for that specific link.


Interface A and Interface Z fields must be populated in a link for the Analytics tab to be available in the Modify Link window. This information comes from Netconf collection, so you can either wait for the next scheduled Netconf collection task to run, or you can create a collection task that runs immediately.

Viewing Threshold-Related Information

You can view interface traffic, interface delay, and packet loss in chart form by right-clicking a link in the network information table as shown in Figure 4.

In the topology map, you can choose to display interface utilization, measured delay, or packet loss labels for the links. Click the Settings icon on the right side of the topology view to open the Topology Settings window where you can control link labels and other display options.