If you try to discover a device but leave the NETCONF Username and Password fields in the Device Discovery dialog empty, the device remains undiscovered and you will no longer be able to discover that device again even if you use the proper NETCONF credentials.
Workaround: Log in to the master node and issue the following kubectl commands (PR1396383):
# kubectl delete -f /etc/kubernetes/apps/joc/joc-device-ds.yml daemonset "joc-device" deleted # kubectl create -f /etc/kubernetes/apps/joc/joc-device-ds.yml daemonset "joc-device" created
In large networks (for example, greater than 150 nodes), the volume of span loss and nodal loss PM metrics might be greater than what the proNX Optical Director can handle, leading to lost span loss and nodal loss PM metrics. PR1391972
When changing port parameters on a device, the changes take effect but are sometimes not displayed even after you navigate away and back to the port parameters page.
Workaround: Refresh the page using the browser refresh. PR1389156
In rare occasions, traffic might not recover after a device or link goes down and comes back up.
Workaround: Undiscover and rediscover the devices at both ends of the link. PR1386990
An OTI Communication Failure alarm might not clear even when the underlying condition causing the alarm no longer persists.
Workaround: Undiscover and then rediscover the device. The alarm clears if the alarm is no longer valid. The alarm persists if the alarm continues to be valid. PR1381807
The Historical Alarms list occasionally shows alarms with a severity of Clear instead of the correct severity. These are duplicate alarms and can be ignored. PR1378213
A Tx or Rx Nodal Loss or Span Loss Out of Range alarm might not clear even when the underlying condition causing the alarm no longer persists.
Workaround: Look at the Nodal Loss or Span Loss historical PMs on the port that raised the alarm. If the nodal loss or span loss is within acceptable range but the alarm is still present, undiscover and then rediscover the device. PR1351804