Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation  Back up to About Overview 

New Features

This section lists new features in the NorthStar Controller Release 3.0.0.

High Availability Enhancements

Enhancements to NorthStar Controller's high availability (HA) implementation include:

  • LSP discrepancy report

    During an HA switchover, the PCS server performs LSP reconciliation. Prior to this release, there was no report or status available to users during switchover, so there was no indication as to what happened to the LSPs. The LSP reconciliation now produces the new LSP discrepancy report which identifies LSPs that the PCS server has discovered might require re-provisioning.

    Note: Only PCC-initiated and PCC-delegated LSPs are included in the report.

  • Simplification of PCEP configuration on the PCC

    Prior to this release, HA configuration on the PCC required that the PCEP session be configured with the physical IP addresses of all the nodes in the cluster. Now, the HA setup menu offers the option to use the cluster virtual IP (VIP) address instead. The default is physical_ip.

    Note: All of your PCC sessions must use either physical IP or VIP, and that must also be reflected in the PCEP configuration on the router.

  • Fast failure detection between JunosVM and PCC

    You can use Bidirectional Forward Detection (BFD) in deploying the NorthStar application to provide faster failure detection as compared to BGP or IGP keepalive and hold timers.

    To utilize this feature, configure bfd-liveness-detection minimum-interval milliseconds on the PCC , and mirror this configuration on the JunosVM. We recommend a value of 1000 ms or higher for each cluster node. Ultimately, the appropriate BFD value depends on your requirements and environment.

  • Support for NorthStar to execute custom scripts

    One application for NorthStar’s ability to execute custom scripts is the extension of NorthStar support for HA VIP into an L3 environment. If NorthStar determines that it is the active node, it executes the scripts that reside in the post_active directory. Similarly, if NorthStar is a backup node, it executes the scripts that reside in the post_backup directory. The locations of the directories are:

    • /opt/northstar/utils/custom_scripts/post_active

      After a failover, or when HA is restarted, NorthStar executes all scripts in this directory if it is the active node.

    • /opt/northstar/utils/custom_scripts/post_backup

      After a failover, or when HA is restarted, NorthStar executes all scripts in this directory if it is the backup node.

    • /opt/northstar/utils/examples

      This directory contains the following sample Python-based scripts:

      • start_advertise_vip_route.py
      • stop_advertise_vip_route.py

    The example script was developed using the Junos PyEZ Python library which simplifies script creation for use in a Junos environment. You must download and install the Junos PyEZ Python library before you can use it. For instructions on installing PyEZ for your own use, see Installing Junos PyEZ.

    For complete HA documentation, see the following topics in the NorthStar Controller User Guide:

Segment Routing

With this release, NorthStar Controller supports Source Packet Routing in Networking (SPRING), also known as segment routing. Segment routing is a control-plane architecture that enables an ingress router to steer a packet through a specific set of nodes and links in the network. Junos OS Release 17.2R1 is required to utilize NorthStar Controller SPRING features. For more information about segment routing, see Understanding Source Packet Routing in Networking (SPRING).

Some highlights of SPRING-related features available in the NorthStar Controller are:

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

    Note: 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.

  • SR-LSP tunnels can be created using both adjacency SID and node SID labels.

    An SR-LSP tunnel 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, 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. The Provision LSP window now has a Provisioning Type drop-down selection offering RSVP and SR options. Select SR. Complete the remaining fields as needed and click Submit to see the new path highlighted in the topology map.

  • SR-LSPs can be configured with a 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.

  • 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.
  • NorthStar diverse LSP and multiple LSP provisioning supports segment routing. Select SR from the Provisioning Type drop-down menu on the Provision Diverse LSP or Provision Multiple LSPs window.
  • For 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 (black holes) 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, the first thing it tries is to reroute using the secondary path.

  • Maintenance events are supported with SR LSPs.

Note: OSPF is not supported for SPRING.

For complete documentation on the NorthStar Controller’s support for segment routing, see Segment Routing in the NorthStar Controller User Guide.

NorthStar REST API Notifications

This feature allows third-party applications to receive NorthStar Controller event notifications. The notifications are pushed by way of the socket.io interface. NorthStar Controller event notifications include the following event types:

  • Node (nodeEvent)
  • Link (linkEvent)
  • LSP (lspEvent)
  • P2MP (p2mpEvent)
  • Facility (facilityEvent)
  • HA (haEvent)

For schemas and Python examples, see NorthStar REST API Notifications in the NorthStar Controller User Guide.

Multi-User Login

It is now possible for multiple full-access users to be logged into the NorthStar Controller simultaneously. This is achieved with an updated architecture that distributes the responsibilities of the NorthStar server. The benefits of this new architecture include:

  • Users experience significant performance improvement when logging into or navigating in the NorthStar Controller UI.
  • A single user can log into the NorthStar Controller multiple times from different devices, each login occupying one licensed user session slot.
  • A maximum of 64 view-only users and ten full-access users can simultaneously log in to the NorthStar Controller UI.
  • The Admin user can always log in to perform admin-only functions, even when all licensed user session slots are occupied.
  • The Admin user can selectively disconnect user sessions.

To disconnect a user session, the Admin user navigates to the User Options drop-down menu and selects Active Users to display the Active Users window. A new Force Log Out button is now included, available only to the Admin.

Health Monitoring

A new Health Monitor process has been added to the NorthStar Controller architecture to enhance the health monitoring functionality in the areas of process, server, connectivity, and license monitoring, and the monitoring of distributed analytics collectors in an HA environment.

  • NorthStar Controller licenses are inspected to determine validity. When a login is attempted on a license that is not valid, a license upload page is presented to the user.
  • The health monitor displays cluster, data collector, and connectivity information by navigating to Administration > System Health in the web UI. For HA cluster environments, you can now view the process status of all processes in all cluster members right in the web UI. Both BGP-LS and ISIS/OSPF peering statuses are also available.
  • Critical health monitoring information is pushed to a web UI banner that appears above the Juniper Networks logo.

    Note: The health monitor does not enable NorthStar Controller to take any corrective action regarding these notices; its responsibility is to monitor and report so the user can respond as appropriate.

Analytics

The Analytics functionality streams data from the network devices, via data collectors, to the NorthStar Controller where it is processed, stored, and made available for viewing in the web UI.

The Analytics features require that the NorthStar Controller periodically connect to the network in order to obtain the configuration of the network devices. It uses this information to correlate IP addresses, interfaces, and devices. The collection schedule is user-configured.

  • You can install data collectors either in the same machine as the NorthStar Controller application server (single-server deployment) or in other machines that are dedicated to log collection and storage (standalone deployment). In both cases, the supplied install scripts take care of installing the required packages and dependencies.
  • JTI sensors generate data from the PFE (LSP traffic data, logical and physical interface traffic data), and only send probes through the data-plane. So in addition to connecting the routing engine to the management network, a data port must be connected to the collector on one of your devices. The rest of the devices in the network can use that interface to reach the collector.
  • New views and work flows in the web UI support visualization of collected data so it can be interpreted.

    Data collectors must be installed and devices must be configured to push the data to the data collectors. The health monitoring feature also uses information from the data collectors.

    To view information about installed data collectors, navigate to Administration > System Health.

  • Prior to this release, it was not possible to see how much traffic was actually going through the network as a function of time; you could only see reserved bandwidth. Interface Utilization is now offered as an option in the left pane of the topology view under Options. When selected, the amount of traffic (RSVP and other traffic) that is going though the network at the time is displayed in the topology, and is updated once every minute.
  • You can opt to display interface delay measurements on the topology map.

    Interface delay information is only available if the devices have been prepared:

    • RPM probes have been configured.
    • The rpm-log.slax script has been loaded, to send the results of the probes to the data collectors.

      Note: The NorthStar Controller does not automate the installation of this script on the router. You must install the script manually.

  • The Performance View shows how utilization has changed over time. In the left pane of the topology view, select Performance from the drop-down menu.
  • Two new columns of data have been added to the Nodes View to reflect a snapshot of traffic in bps and pps over the last hour. This is for quick reference in case there are conditions that require attention. You can see this snapshot for both Interfaces and Tunnels.
  • Data collection allows the NorthStar Controller to gather information about the protocols that are configured on each interface. The Protocols column in the network information table under the Interface tab displays OSPF, LDP, RSVP, and MPLS when configured.
  • You can configure NorthStar Controller to automatically reroute LSPs based on interface traffic or link delay conditions. To access these configuration parameters, navigate to Administration > Analytics.

For full Analytics documentation, see the following topics in the NorthStar Controller User Guide:

Netconf Persistence

The Netconf Persistence feature allows you to create a collection task for netconf and display the results of the collection. In future releases, other task types (besides Netconf) will be supported. Netconf collection is used by the Analytics feature to obtain the network device configuration information needed to organize and display collected data in a meaningful way in the web UI.

Note: Completion of device profiles (Administration > Device Profile) is a prerequisite for successfully running collection tasks.

For complete documentation of this feature, see the following topics in the NorthStar Controller User Guide:

Modified: 2017-08-29