Spectrum Network Configuration Manager general failure

Document ID : KB000125150
Last Modified Date : 23/01/2019
Show Technical Document Details
After migration to R10.2.3 having problems with Configuration Manager. It appears there is a general issue that CA Spectrum Network Configuration Manager service is not working fine even all services are started. When restarting all CA Spectrum services it appears the "NCM" service (managed by processd) is running fine with very same conditions of failure.
CA Spectrum Network Configuration Manager (NCM) service is a standalone service task (ncmservice - CORBA resource name "scmservice") running besides the SpectroSERVER. When running NCM task the SpectroSERVER will establish communication with the NCM-service and the NCM-service is then processing/acting this task.

Used tools here are:
 ./bin/cmdC        - to check for  processd managed services
 ./bin/VBNS/nsutil   - to check for CORBA resource registration names and context
 netstat -an | grep 52161   - to check for socket 52161 status 
 netstat -an[p|b]      - to check for application output to see proess/task name per socket
This applies to all supported CA Spectrum platforms and releases.

IP-stack/protocol reconfiguration solves this problem. In case IPv6 and IPv4 is enabled then ensure name-resolution for IPv6 is also fine (and may not point to "localhost" for hostname).

Additional Information:
The NCM-service is running as "ncmservice" task and is using CORBA communication for the paired SpectroSERVER<->ncmservice communication.
This is a TCP-session establishment from SpectroSERVER to the ncmservice task. "ncmservice" task will open socket 52161 in LISTEN.
Still - we do not see an established TCP-session for SpectroSERVER <-> ncmservice

[spectro@labspec02 VBNS]$ netstat -an | grep 52161
tcp    0   0 :::52161            :::*        LISTEN

[spectro@labspec02 VBNS]$ netstat -anp | grep 52161
tcp    0   0 :::52161            :::*        LISTEN      30532/ncmservice

Background here is the CORBA resource name registration and the naming-service - which expects to have all CORBA service registered under context of the "hostname".
This could be checked by tool ./bin/VBNS/nsutil

[spectro@labspec02 VBNS]$ ./nsutil list labspec02  (output here is correct/expected)
Bindings in labspec02
Object : SLMDomain
Object : LmtManagerDomain
Object : RTMDomain
Object : SpectrumICMP
Object : CsCLocServMapInt
Object : TelcoManagerDomain
Object : CsCEventDomain
Object : ScmService
Object : EventDispDomain
Object : CsCModelDomain
Object : SnmpServ
Object : ProcedureDomain
Object : OnlineMibImport
Object : CsCAlarmDomain

For this problem here the "ScmService" was not listed under context of hostname - but was listed under context of "localhost" - seeing:
[spectro@labspec02 VBNS]$ ./nsutil list localhost
Bindings in localhost
Object : ScmService

Interesting and confusing - the "ScmService" is the only CORBA resource allocation registered under "localhost" while all others are fine under context of "hostname".