The following behaviors are known to occur in NorthStar Controller Release 4.2.0:
NorthStar REST API does not return in the REST response the selected routing method:
Currently, if a REST API body has routingMethod=Default, the corresponding REST response does not include the routingMethod keyword.
NorthStar still computes the ERO properly.
In a future NorthStar release, the REST response will properly indicate the selected routingMethod.
Re-provision LSPs issue:
For a Netconf-provisioned P2MP tree, re-provisioning individual sub-LSPs to go around a failed link can fail under the following conditions:
The user re-provisions 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 re-provision 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.
Behaviors related to Netflow Collector:
It can happen that during a NorthStar upgrade from NorthStar 4.0 or 4.1 to NorthStar 4.2, netflowd cannot be started. If netflowd fails to start, run the following command on the system hosting the netflowd collector:
sudo -u pcs /opt/northstar/thirdparty/python/bin/pip -q install --upgrade --no-deps --force-reinstall /opt/pcs/lib/python/*.whl
The ElasticSearch REST API assumes that LSPs on different routers have different names.
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:
supervisorctl restart infra:web