CA Spectrum SDM/SDC managed devices are not polled anymore
search cancel

CA Spectrum SDM/SDC managed devices are not polled anymore

book

Article ID: 51866

calendar_today

Updated On:

Products

Spectrum Network Observability

Issue/Introduction

Devices polled and managed via SPECTRUM SDM / SDC show an intermittent condition while the SDM/SDC communication hangs

The Secure Domain Manager model and also the SDConnector models are not showing Events, with an exception generated while all directly managed SPECTRUM devices are polled successfully.

Creating a sniffer trace for the SDC instance does not show any ICMP and/or SNMP traffic to poll the network devices.

Enabling trace/debug in the $SPECROOT/SDM/sdm.config by adding the option "-loglevel debug" results in messages similar to the following in the sdmLog.log:

Wed Sep 23 10:38:45 2025 : WARNING: SdmEtpkiConnectEndpoint run() ssock_handshake error. IP=<IP Address>, Port=6844, Thread=99
Wed Sep 23 10:38:50 2025 : WARNING: SdmEtpkiConnectEndpoint run() ssock_handshake error. IP=<IP Address>, Port=6844, Thread=99
Wed Sep 23 10:38:55 2025 : WARNING: SdmEtpkiConnectEndpoint run() ssock_handshake error. IP=<IP Address>, Port=6844, Thread=99
Wed Sep 23 10:39:00 2025 : WARNING: SdmEtpkiConnectEndpoint run() ssock_handshake error. IP=<IP Address>, Port=6844, Thread=99
...
Wed Oct  7 15:37:39 2025 : WARNING: Endpoint <IP Address> is shutting down after keepalive timeout
Wed Oct  7 15:37:39 2025 : WARNING: SdmEtpkiEndpoint::shutdownSocket() starting. IP=<IP Address>, Thread=211
Wed Oct  7 15:37:40 2025 : WARNING:  socket closed. IP=<IP Address>, Thread=211
Wed Oct  7 15:37:40 2025 : WARNING:  socket is invalid. IP=<IP Address>, Thread=211

Also, checking the SDM/SDC valid configuration will, when the SDM is started and the SDC is available, show a successfully established TCP session to port 6844 for the SDM/SDC service port. However, observing a successful TCP session establishment is NOT proof of full operational TCP communication.

Resolution

There are a couple of items that could cause this:

1. Versioning - make sure SDConnector is the same version as the SpectroSERVER.  Navigate to $SDConnector/bin directory:

./SdmConnectorService.exe --version
Example output might look like this from a 25.4.2 system:

[root@<hostName> bin]# ./SdmConnectorService.exe --version
SPECTRUM V25.4.2.000,  BuildVersion: 25.4.2.000

2. Certificate issues - see https://knowledge.broadcom.com/external/article/431115/tls-versions-and-ciphers-for-sdc-to-sdm.html 

3.  Fragmentation - run "netstat -s" to review network parameters

MTU - A network lower layer configuration issue for fragmentation errors caused by MTU size set to high values.

In this case, lowering MTU to 1400 byte fixes the SDM/SDC hang condition.

So reduce the IP MTU size configuration for the SpectroSERVER and the SDC machines by reconfiguring to 1400 bytes. The default for Ethernet is 1500 bytes which is maybe causing trouble in case of using VPN/IPsec tunnels with additional encapsulation.

Additional Information

If the customer does not care about using security with the SDM to SDC connection, you can add -nosecure to the configuration files of both SDM and SDC.  Import the configuration file again in SDM and restart the SDC process.

You can verify the connection from the SS/SDM and/or SDC by using telnet and netstat.  For example, from the SS/SDM, telnet to the SDC:

telnet <IPofSDC> <SDCport>

If you receive a blank line, the connection is established.

Then run netstat on the SDC:

netstat -anop | grep <SDCport>

Verify the IP address that the connection is coming in on and compare it to the sdc.config.