LSP Routing Behavior
You can configure NorthStar Controller to automatically reroute LSPs based on interface traffic or link delay 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.
Parameter |
Description |
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, and 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. When an LSP is configured with a Max Delay, and there is also a global link delay threshold value, the controller checks the LSP upon LSP delay violations. |
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.
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.
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.
In the Analytics tab, you can set any or all of the three 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 3.
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.