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 6.2.6:

  • Nodes, links, and SRLGs that are moved to maintenance might be lost during a TopoServer restart event such as HA switchover, sync network model, or reset network model.

  • PCEP P2MP: 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:

    • This feature requires that you use Junos OS Release 18.3R2 or later, 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.

  • NETCONF P2MP (Reprovisioning LSPs):

    • 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.

  • Automatic rerouting: Automatic rerouting of NETCONF-provisioned LSPs (including NETCONF-provisioned SR LSPs) is supported as follows:

    • If an LSP is provisioned through NETCONF in the router and not delegated to NorthStar by PCEP, the LSP is controlled by the Junos OS configuration; that is, if link protection is enabled for the LSP (dynamic LSP) in Junos OS, the LSP is rerouted when the link over which the LSP is traversing fails. Junos OS does not reroute the LSP if link protection is not configured for the LSP (static LSP) in Junos OS. NorthStar does not control routing of an LSP when the LSP is not delegated to it.

    • If a dynamic LSP is provisioned through NETCONF in Junos OS and later delegated to NorthStar through PCEP, NorthStar controls the LSP instead of Junos OS; that is NorthStar will reroute the LSP, whenever the link over which the LSP traverses fails. If a static LSP is delegated, NorthStar will not reroute it.

  • PCE-initiated LSP: 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 (for example, PCEP Error Type = 24 error value = 2) in future releases.

  • Netflow Collector: Sometimes, during a NorthStar upgrade, 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:

  • ODN LSP DelegationTo delegate an on-demand next hop (ODN) LSP to NorthStar, you must add the lsp-external-controller pccd statement to the router configuration. To delete the ODN LSP from the router, you must explicitly delete the LSP by using the router CLI.

  • SR-TE LSP: In Junos OS releases older than 19.1.R1.1, the operational state of an SR-TE LSP is down if the SR-TR LSP is provisioned through NETCONF and has:

    • routeByDevice as the routing method, and

    • Allow any SID at first hopenabled on the ingress node