Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

Known Behavior

 

The following behaviors are known to occur in NorthStar Controller Release 4.3.0:

  • Behaviors Related to P2MP Functionality:

    • You cannot have PCEP-provisioned and NETCONF-provisioned P2MP groups with the same name:

      • If you do, the NETCONF-provisioned group takes precedence and the PCEP-provisioned group fails.

      • The Tunnel tab of the network information table displays additional entries, for sub-LSPs of the P2MP group that fails. The Controller Status column for these entries indicates “Can’t modify PCC-controlled lsp”, and the Op Status column indicates “Unknown”. In a future NorthStar release, these extra entries will not be created. Instead, the user will be blocked from creating PCEP-provisioned and NETCONF-provisioned P2MP groups with the same name.

    • NorthStar automatically reroutes PCEP P2MP groups around a network element failure. After the failed element comes back up, the group might not be automatically restored to the original path, even if the user chooses to optimize LSP paths. In a future NorthStar release, the concept of what constitutes an optimal P2MP group will be addressed.

  • Behaviors and limitations related to PCEP-provisioned P2MP Groups:

    • See the description of this feature in New Features for a list of functionality supported in this release. No other functionality is supported at this time.

    • This feature requires that you use Junos OS Release 18.3R2 private build, in which the following Junos OS PRs have been fixed:

      • Junos OS PR 1412649

        The fix for this PR enables you to define a separate template for P2MP (separate from the one used for P2P), one that does not allow “adaptive” to be configured. To define the new template, configure the following statements on the head end PE of the PCE-initiated P2MP LSP:

      • Junos OS PR 1412490

        The fix for this PR ensures that deletion of P2MP PCEP branches is properly reported.

      • Junos OS PR 1358245 (not specific to P2MP).

        The fix for this PR ensures that segment routing (SR) path names are properly reported in Junos OS Release 18.3R2.

    • When viewing P2MP groups in the network information table, be aware that the refresh button at the bottom of the table periodically turns orange to prompt you for a refresh. When you click the refresh button, the web UI client retrieves the latest P2MP sub-LSP status from the NorthStar server.

  • Re-provision LSPs issue for NETCONF P2MP:

    • For a NETCONF-provisioned P2MP tree, reprovisioning individual sub-LSPs to go around a failed link can fail under the following conditions:

      • The user reprovisions sub-LSPs separately.

      • The user has a mixture of sub-LSPs with a user-specified strict path and paths computed by NorthStar.

    • The workflow is to reprovision all sub-LSPs of a tree together; NorthStar computes sub-LSPs of a tree as a whole, not individually.

  • Behaviors and limitations related to NETCONF Provisioning of LSPs and Binding SID Support:

    • Automatic rerouting of NETCONF-provisioned LSPs (including NETCONF-provisioned SR LSPs) due to a failure in the network is not supported.

    • The Preview Path button in the Provision LSP window may return a “Cannot find a path!” error message when in fact a path was found and the SR LSP was successfully provisioned. The error message occurs for certain scenarios such as when an SR LSP makes use of a binding SID SR LSP (privateForwardingAdjacency).

  • During PCE initiated LSP, some Cisco routers configured with IOS-XR version can return an error code for an unknown reason. Currently NorthStar Application only reports “NS_ERR_GENERIC” when this issue happens. It is planned to improve this behavior and report the exact error code (e.g. PCEP Error Type = 24 error value = 2 ) in future releases.

  • In rare case, you might get an empty result in the network information table, Service tab for both summary and detailed information, for example, after a system upgrade. If this happens, you can resolve it by restarting the web process:

  • Netflow Collector: It can happen that during a NorthStar upgrade from NorthStar 4.x to NorthStar 4.3, netflowd cannot be started. If netflowd fails to start, run the following command on the system hosting the netflowd collector:

    After running the command, restart the Netflow process: