NSX "Controller Channel To Transport Node Down" connection issues.

Products

• VMware NSX

Issue/Introduction

Intermittent transport node connectivity alarms occur across the ESXi cluster.

• The NSX Manager UI intermittently reports the alarm: "Control channel to transport node down" for ESXi Transport Nodes.

  

• The alarm typically clears automatically after a few minutes without manual intervention.

• In the ESXi host /var/log/nsx-syslog.log, the configuration agent (cfgAgent) reports health check timeouts for nsx-nestdb:

  26-07-##T##:45:56.1##Z Wa(180) cfgAgent[6###27]: NSX 6####27 - [nsx@##76 comp="nsx-controller" subcomp="cfgAgent" tid="###B9#00" level="warn"] DaemonHealthMonitor: nestdb echo timeout (60 sec)

• In the ESXi host's /var/log/nsx-syslog.log, the nestdb reports a disconnection from the local database:

  2026-07-##T##:47:27.959Z In(182) nsx-exporter[6###615]: NSX ###0615 - [nsx@##76 comp="nsx-esx" subcomp="nsx-fabric-exporter" s2comp="nestdb-client" tid="6####54" level="INFO"] NestDbClient is disconnected
2026-07-##T##:47:27.959Z In(182) nsx-exporter[64###15]: NSX ###615 - [nsx@##76 comp="nsx-esx" subcomp="nsx-fabric-exporter" s2comp="sndemux" tid="6####54" level="INFO"] Nestdb channel status turns to down


  2026-07-##T##:46:##Z In(182) nsx-sha: NSX 6491246 - [nsx@6876 comp="nsx-esx" subcomp="nsx-sha" username="root" level="INFO"] Dhreport - reporting, tn_agent_status:{"oid":{"left":"1######221014##01731","right":"952#######76###49244"},"status":[{"type":"TN_AGENT","tn_agent_status":{"threat_state":{},"agent_state":{"total_status":"DOWN","up_count":4,"down_count":1,"agent_status":[{"type":"NSX_NESTDB","status":"DOWN","resource_stats":{"memory_used":"155184","memory_total":"2097152"}},{"type":"NSX_OPSAGENT","status":"UP","connection_status":[{"name":"opsagent-proxy-connection","status":"UP"}],"resource_stats":{"memory_used":"355700","memory_total":"1331200"}},{"type":"NSX_CFGAGENT","status":"UP","connection_status":[{"name":"cfgagent-nestdb-connection","status":"DOWN"}],"resource_stats":{"memory_used":"167852","memory_total":"6144000"}},{"type":"NSX_EXPORTER","status":"UP","resource_stats":{"memory_used":"195100","memory_total":"1536000"}},{"type":"NSX_VDPI","status":"UP","resource_stats":{"memory_used":"679452","memory_total":"1048576"}}],"degraded_count":0}}}]}

• ESXi vmkernel.log shows storage performance deterioration: WARNING: ScsiDeviceIO: 1780: Device naa.#### performance has deteriorated. I/O latency increased from average value of #### microseconds to #### microseconds.

• ISCSI command failures with status H:0x0 D:0x28 P:0x0 (Task Set Full).

 

Environment

• VMware NSX 4.x
  
  
• VMware vSphere ESXi 7.x/8.

Cause

The ESXi host experiences array-side resource exhaustion, manifesting as a TASK_SET_FULL condition (SCSI status D:0x28). Because the local NSX configuration database (nsx-nestdb) requires continuous disk access, severe storage latency causes the database service to hang. When nsx-nestdb is unresponsive, the host cannot send management heartbeats to the NSX Manager, triggering the connectivity alarm.

Resolution

This is an environmental storage performance issue, to resolve the connectivity alarms, the underlying storage performance must be addressed:

1. Identify affected datastores by correlating NAA IDs in vmkernel.log warnings.

2. Monitor storage performance using esxtop. Press u for the disk device view and check DAVG/cmd. Values consistently above 10-20ms indicate external storage or fabric issues.

3. Engage the storage hardware vendor to analyze array-side performance metrics during the incident window.

Additional Information

If further assistance is required, see Creating and managing Broadcom support cases. To speak with a representative, see Creating and managing Broadcom cases