HP 3PAR Mass Storage Array Discovery sets incorrect values in the Fibre Channel Port CI's Worldwide Node Name (WWNN) field - Known Error

HP 3PAR Mass Storage Array Discovery sets incorrect values in the Fibre Channel Port CI's Worldwide Node Name (WWNN) field Description After discovering successfully HP 3PAR Mass Storage Array the Fibre channel port is given an incorrect worldwide node name

The number of Fibre Channel Ports associated with the array matches the host-facing ports on the 3PAR. It is correctly determining the worldwide Port name (WWPN) of the port in each case, but either assigns each port's Worldwide Node Name (WWNN) a default (00:00:00:00:00:00:00:00) or a completely incorrect value.

Steps to Reproduce

Setup discovery of HP 3PAR Mass Storage Array using: https://docs.servicenow.com/csh?topicname=t_ConfigDiscoForStandaloneStorage.html&version=latest

Actual behaviour:

In one test, the number of Fibre Channel Ports associated with the array (10) matches the host-facing ports on the 3PAR. It is correctly determining the "name" and "worldwide port name" of the port in each case, but either assigns each port a default "worldwide node name" (00:00:00:00:00:00:00:00) or a completely incorrect value.

For example, a Fibre Channel Port CI is created with values: Name= 0:2:3 WWNN=50:06:0b:00:00:c3:36:6e WWPN=20:23:00:02:ac:00:13:0d Controller=PVHAD44

The ecc payload contained those values:

{"n":"0:2:3","w":"20230002AC00130D","wn":"50060B0000C3366E","pt":"10","sp":"8589934592","c":{"n":"PVHAD44","d":"HSet:11","fp":["$^bnh"]}}, The CLI of the device shows the actual value of WWNN, which is 2f:f7:00:02:ac:00:13:0d:

N1_WMM0772V400N877 cli% showport showport 0:2:3 N:S:P Mode State ----Node_WWN---- -Port_WWN/HW_Addr- Type Protocol Label Partner FailoverState 0:2:3 target ready 2FF70002AC00130D 20230002AC00130D host FC - 1:2:3 none Running CIM debug page in the instance /cim_query2.do against the SMI storage listener and selecting FCports button you can see it returns the correct information. For port 0:2:3 the NodeWWN and it's associated value in decimal of: 3456231250505765645 which in hex is: 2FF7 0002 AC00 130D So the probe must be doing something differently.

Expected behaviour: The WWNN values returned from the CLI and CIM debug test should be used.

Workaround This problem is currently under review. You can contact ServiceNow Technical Support or subscribe to this Known Error article by clicking the Subscribe button at the top right of this form to be notified when more information will become available.