Troubleshooting “Control Channel To Transport Node Down" connection issues.

search cancel

Troubleshooting “Control Channel To Transport Node Down" connection issues.

book

Article ID: 410581

calendar_today

Updated On:

Products

VMware NSX VMware Cloud Foundation

Issue/Introduction

Troubleshooting Connection Failures between Transport Nodes (ESXi Hosts, Edge Nodes or VNA Nodes) and NSX Controllers.

Common Symptoms:

CCP session message disconnected state - can be seen this in multiple ways:

NSX UI Alarms: "Control Channel to Transport Node Down" or "Control Channel to Transport Node Down Long".
NSX UI: System > Fabric > Hosts > Transport Nodes shows "Degraded" or "Down" status.
vMotion failures with error: "lcp.ccpSession down". Further details can be found at https://knowledge.broadcom.com/external/article?articleNumber=394198
ESXi command shows: net-dvs -l | grep -i down.
Output: com.vmware.common.opaqueDvs.status.component.lcp.ccpSession = down
New configuration update from API or NSX UI cannot be realized on the Transport Nodes (ESXi Hosts, Edge Nodes or VNA Nodes).

1 Alarms reported by CCP for TN disconnection events (nsx-proxy service or nsx-nestdb service)

1.1 [Control Channel to Transport Node Down] CCP reports a short alarm for a TN disconnection event due to either the nsx-proxy or nsx-nestdb service being down

If the connection between CCP and TN, or the channel between CCP and nsx-nestdb, is down for 3 minutes, CCP will report a disconnection alarm as shown in the image below.

1.2. [Control Channel to Transport Node Down Long] CCP reports long-term alarm for TN disconnection due to nsx-proxy or nsx-nestdb service down

If the connection between CCP and TN, or the channel between CCP and nsx-nestdb, remains down for 15 minutes after the "Controller Channel to Transport Node Down" alarm is raised, a "Control Channel to Transport Node Down Long" alarm will be reported, as shown in the image below.

2. Alarms reported by TN for CCP disconnection event

2.1. [Control Channel to Manager Node Down] TN reports CCP service down short alarm disconnection event

If the connection between CCP and TN is down for 3 minutes, TN will report a disconnection alarm via the MPA channel, as shown in the image below.

2.2. [Control Channel to Manager Node Down Too Long] TN reports CCP service down long alarm disconnection event

If the connection between CCP and TN remains down for 15 minutes after the "Control Channel to Manager Node Down" alarm is raised, a "Control Channel to Manager Node Down Too Long" alarm will be reported via the MPA channel, as shown in the image below.

3. vMotion failure due to 'lcp.ccpSession down'

VM migration will fail with the reason "lcp.ccpSession down" if the connection between CCP and nsx-proxy is down on either the source or destination TN, as shown in the image below.

Environment

VMware NSX-T 3.2.x and later
VMware Cloud Foundation

Resolution

1. Review NSXCLI "get controllers" result on TN (ESXi Node, Edge Node or VNA Node).

1.1. "get controllers" status is "connected"

 Controller IP    Port     SSL         Status       Is Physical Master   Session State  Controller FQDN           Failure Reason         
  x.x.x.77     1235   enabled     connected             true               up               NA                       NA

1.2. "get controllers" failed to run

> get controllers 
% Failed to get controller list

Action: Please check the status of the nsx-proxy and nsx-nestdb services.

Resolution: Start these services, If they are not running.

#/etc/init.d/nsx-nestdb status
#/etc/init.d/nsx-proxy status

1.3. "get controllers" result is empty

> get controllers 
Mon Jan 19 2026 UTC 06:31:32.427
 Controller IP    Port     SSL         Status       Is Physical Master   Session State  Controller FQDN           Failure Reason

This indicates that the /etc/vmware/nsx/controller-info.xml file is empty.

Actions:

1. Check nsx-opsagent service is up and running on TN: /etc/init.d/nsx-opsagent status

2. Check nsx-proxy connectivity with manager. Execute the command below using NSXCLI on TN to verify that the "get managers" result is connected.

> get managers
Wed Jan 14 2026 UTC 13:26:05.437
- x.x.x.77      Connected (NSX-RPC) *

3. Check the channel status between nsx-opsagent and nsx-proton services.

Resolution: Take appropriate steps based on the issues identified while performing the actions.

1.4. "get controllers" status is "disconnected"

On ESX, Log location <LOG_FILE> : /var/run/log/nsx-syslog.log

On Edge, Log location <LOG_FILE>: /var/log/syslog

On VNA, Log location <LOG_FILE>: /var/log/syslog

1.5. Connection Failure Reason Identification Guide

Table helps you to identify the failure reason by analyzing nsx-proxy logs on TN in following cases:

- "get controllers" output "Failure Reason" column is empty.

- "get controllers" output "Failure Reason" column shows "NA".

- "get controllers" output "Failure Reason" does not match the failure reason listed in the table.

Failure Reason	Identification
CERT_VALIDATION_FAILED	#grep -ia "self-signed certificates validation failed" <LOG_FILE> \| grep -ia ":1235" Example log: "Closing (remote self-signed certificates validation failed)"
CONNECTION_REFUSED	#grep -ia "Connection refused" <LOG_FILE> \| grep -ia ":1235" Example log: "Couldn't connect to 'ssl://x.x.x.77:1235' (error: 111-Connection refused)"
CONNECTION_TIMED_OUT	#grep -ia "Connection timed out" <LOG_FILE> \| grep -ia ":1235" Example log: "Couldn't connect to 'ssl://x.x.x.77:1235' (error: 110-Connection timed out)"
CONTROLLER_REJECTED_HOST_CERT	#egrep -ia "alert certificate" <LOG_FILE> \| grep -ia ":1235" Example log (NSX 4.1+): "error: 167773276-tlsv13 alert certificate required" Example log (Until 4.1): "error: 336151574-sslv3 alert certificate unknown"
CONTROLLER_UNREACHABLE	#grep -ia "No route to host" <LOG_FILE> \| grep -ia ":1235" Example log: "keeper state failed with error code 113-No route to host category system"
CRL_CERTIFICATE_REVOKED	#grep -ia "certificates revoked" <LOG_FILE> \| grep -ia ":1235" Example log: "Closing (remote certificates revoked)"
CRL_VALIDATION_FAILED	#grep -ia "CRL validation failed" <LOG_FILE> \| grep -ia ":1235" Example log: "being closed with close reason remote certificates CRL validation failed"
HOST_NOT_FOUND	#grep -ia "Host not found" <LOG_FILE> \| grep -ia ":1235" Example log: "Couldn't resolve 'ssl://abc.fqdn.com:1235' (error: 1-Host not found (authoritative))"
HOST_REJECTED_CONTROLLER_CERT	#grep -ia "Certificate validation failed" <LOG_FILE> #grep -ia "certificate verify failed"<LOG_FILE> \| grep -ia ":1235" Example log: "Certificate validation failed: 18-self-signed certificate" "error: 167772294-certificate verify failed (SSL routines)"
MAINTENANCE_MODE	#grep maintenanceMode /etc/vmware/nsx/controller-info.xml Example output: <maintenanceMode>true</maintenanceMode>
VERSION_MASTERSHIP_HANDSHAKE_FAILURE	Connection is establishing with CCP but the VersionMastershipHandshake is failing. Complete handshake complete logs: #grep -ia "nsx-proxy" <LOG_FILE> \| grep -ia "VersionMastershipHandshake" stub creation failure with Version Mastership Handshake service: #grep -ia "nsx-proxy" <LOG_FILE> \| grep -ia "VersionMastershipHandshake" \| egrep -ia "stub failed\|stub retries expired" Version Check logs and failures: #grep -ia "nsx-proxy" <LOG_FILE> \| egrep -ia "VersionObserver\|version rpc sending\|received VersionResponse\|received CallStatus" GetMaster call logs and failures: #grep -ia "nsx-proxy" <LOG_FILE> \| egrep -ia "MastershipObserver\|mastership rpc query\|received MasterResponse\|Master CCP is" DataSync logs and failures (V2 Only - NSX 9.0 and above): #grep -ia "nsx-proxy" <LOG_FILE> \| egrep -ia "datasync\|DataSyncObserver\|DataSyncResponse\|PREPARE_STUB\|START_ACK\|STOP_ACK\|ACK timedout"

1.6. Failure Reason Resolution Guide

This table helps you quickly identify the issue and what to do about it.

Failure Reason	Root Cause	Resolution
CERT_VALIDATION_FAILED	Controller certificate was created with wrong settings or configurations.	`Controller certificate generated with invalid parameters.` `Invalid EKU (Extended Key Usage).` `Not allowed curves.` `Invalid basic constraints.` `Review and regenerate Controller self signed certificate.` `Review controller certificate:` #openssl x509 -in <controller_cert> -text `Review EKU, curves, constraints.`
CONNECTION_REFUSED	NSX Controller service is not running on NSX Manager	`Please check following:` `1. On Manager, check CCP service: /etc/init.d/nsx-ccp status` `2. Verify port listening: netstat -an \| grep 1235 \| grep -ia LISTEN` `3. If nsx-ccp service down, restart: /etc/init.d/nsx-ccp restart` `After nsx-ccp service restart, run "get controllers" on TN and verify Status shows "connected".`
CONNECTION_TIMED_OUT	Cannot reach NSX Manager (due to firewall or network issue)	`Please check following:` `1. Check if Manager is reachable from TN.` `2. Verify firewall allows port 1235 between TN and NSX Manager.` `Troubleshooting Steps:` `1. From TN, ping controller IP: ping <controller-ip>` `2. Verify port 1235 connectivity: nc -zv <controller-ip> 1235.` `After fixing network issues, run "get controllers" and verify Status shows "connected".`
CONTROLLER_REJECTED_HOST_CERT	TN certificate validation failed on the Controller side. The TN certificate may be expired, not trusted, or invalid.	`Please check following:` `1. Review TN certificate.` #openssl x509 -in /etc/vmware/nsx/host-cert.pem -text `2. Verify certificate expiry and other details.` `3. Further review the nsx-ccp logs located at /var/log/cloudnet/nsx-ccp.log to identify the reason for the failure.` `#grep -ia "NsxTrustManager" /var/log/cloudnet/nsx-ccp.log` `If TN untrusted chain:` `#grep -ia "NsxTrustManager" /var/log/cloudnet/nsx-ccp.log \| grep -ia "Untrusted Chain\\|Client certificate not allow-listed:\\|Client certificate not white-listed:"` `If TN certificate expiry:` `#grep -ia "Certificate expired"` /var/log/cloudnet/nsx-ccp.log `If TN Certificate not valid yet:` `#grep -ia "Certificate not valid yet for" /var/log/cloudnet/nsx-ccp.log` `If TN Certificate Revoked or CRL related errors:` `#egrep -ia "(CRL check failed:\|Certificate revoked for)" /var/log/cloudnet/nsx-ccp.log` `4. Take appropriate action based on error:` `Either replace TN certificate` `Or Sync TN certificate using nsxcli push host-certificate command.` `After certificate fix, run "get controllers" and verify Status shows "connected"` `More details follow KB: https://knowledge.broadcom.com/external/article/345870/nsx-certificate-expired-alarm.html`
CONTROLLER_UNREACHABLE	Resolved FQDN IP address is not reachable.	`Please check following:` `Check if FQDN is correctly configured: grep -r "<fqdn" /etc/vmware/nsx/controller-info.xml` `Test DNS resolution: nslookup <controller-fqdn>` `Verify resolved ip addresses are reachable from TN: ping <resolved-controller-ip>` `After fix, run "get controllers" and verify Status shows "connected" within 1-2 minutes.`
CRL_CERTIFICATE_REVOKED	Controller certificate has been revoked (marked as untrusted).	`Please check following:` `1. Verify the reason behind the controller certificate being included in the revoked certificate list.` #/opt/vmware/nsx-nestdb/bin/nestdb-cli --json --cmd get vmware.nsx.nestdb.CrlCertificatesCacheMsg `2. Upload/Re-generate new controller certificate.` `more details follow kb: https://knowledge.broadcom.com/external/article/329221`
CRL_VALIDATION_FAILED	Certificate trust store service issue on NSX Manager.	`Please check following:` `1. Check proton and appl-proxy services status on NSX Manager.` #/etc/init.d/nsx-proton status #/etc/init.d/nsx-appl-proxy status `2. Check the manager’s connectivity on TN using NSXCLI "get managers" command.` `3. start the services, it is not running.` `more details follow kb: https://knowledge.broadcom.com/external/article/329221`
HOST_NOT_FOUND	Host cannot find NSX manager by name (DNS issue)	`Please check following:` `Check if FQDN is correctly configured: grep -ia "<fqdn" /etc/vmware/nsx/controller-info.xml` `Test DNS resolution: nslookup <controller-fqdn>` `If DNS issue, fix DNS servers or use IP address instead.` `After DNS fix, run "get controllers" and verify Status shows "connected" within 1-2 minutes.`
HOST_REJECTED_CONTROLLER_CERT	Controller certificate has expired, or not trusted by nsx-proxy on TN.	`Please check following:` `1. Review the nsx-proxy logs to identify the reason for the failure.` #grep -ia "Certificate validation failed" <LOG_FILE> \| grep -ia nsx-proxy If the error “self-signed certificate” occurs, it indicates that the controller certificate is untrusted. Verify that the controller certificate matches the certificate located in `/etc/vmware/nsx/controller-info.xml`. `If the error “certificate is not yet valid” occurs, it indicates that the controller certificate is not yet valid. Could be NTP sync issue.` `If the error “certificate has expired” occurs, it indicates that the controller certificate is expired. Replace controller certificate.` `If the error “certificate has expired” occurs, it indicates that the controller certificate is expired. Replace controller certificate.` Verify that the controller certificate matches the certificate located in `/etc/vmware/nsx/controller-info.xml`. `After certificate fix, run "get controllers" and verify Status shows "connected".` `More details follow KB: https://knowledge.broadcom.com/external/article/345870/nsx-certificate-expired-alarm.html`
MAINTENANCE_MODE	TN is in maintenance mode (expected during upgrades or patching)	`No action needed if intentional.` `To exit maintenance mode:` `In NSX UI: System > Fabric > Hosts > Select host > Actions > Exit Maintenance Mode` `After disabling maintenance mode, run "get controllers" and verify Status shows "connected".` `More details: https://techdocs.broadcom.com/us/en/vmware-cis/nsx/vmware-nsx/4-2/upgrade-guide/troubleshooting-upgrade-failures-nsxt/unable-to-upgrade-host-placed-in-nsx-maintenance-mode.html`
VERSION_MASTERSHIP_HANDSHAKE_FAILURE	In this case, the "get controller" status is set to "disconnected" with "Failure Reason" as "NA" due to a version mastership handshake failure with the Controller.	`1. Stub creation failure with the Version Mastership Handshake service.` `2. Version Check failures: This includes either call failures or version compatibility check failures with the Controller.` `3. GetMaster failures: This includes either call failures or received master Controller UUID that is not present in /etc/vmware/nsx/controller-info.xml.` `4. DataSync call failures: This includes either call failures or the DataSync prepare stub taking longer than expected.`

Failure Reason

Root Cause

Resolution

CERT_VALIDATION_FAILED

Controller certificate was created with wrong settings or configurations.

Controller certificate generated with invalid parameters.

Invalid EKU (Extended Key Usage).
Not allowed curves.
Invalid basic constraints.
Review and regenerate Controller self signed certificate.

Review controller certificate:

#openssl x509 -in <controller_cert> -text

Review EKU, curves, constraints.

CONNECTION_REFUSED

NSX Controller service is not running on NSX Manager

Please check following:

1. On Manager, check CCP service: /etc/init.d/nsx-ccp status

2. Verify port listening: netstat -an | grep 1235 | grep -ia LISTEN

3. If nsx-ccp service down, restart: /etc/init.d/nsx-ccp restart

After nsx-ccp service restart, run "get controllers" on TN and verify Status shows "connected".

CONNECTION_TIMED_OUT

Cannot reach NSX Manager (due to firewall or network issue)

Please check following:

1. Check if Manager is reachable from TN.

2. Verify firewall allows port 1235 between TN and NSX Manager.

Troubleshooting Steps:
1. From TN, ping controller IP: ping <controller-ip>
2. Verify port 1235 connectivity: nc -zv <controller-ip> 1235.

After fixing network issues, run "get controllers" and verify Status shows "connected".

CONTROLLER_REJECTED_HOST_CERT

TN certificate validation failed on the Controller side.

The TN certificate may be expired, not trusted, or invalid.

Please check following:

1. Review TN certificate.

#openssl x509 -in /etc/vmware/nsx/host-cert.pem -text

2. Verify certificate expiry and other details.

3. Further review the nsx-ccp logs located at /var/log/cloudnet/nsx-ccp.log to identify the reason for the failure.

#grep -ia "NsxTrustManager" /var/log/cloudnet/nsx-ccp.log

If TN untrusted chain:

#grep -ia "NsxTrustManager" /var/log/cloudnet/nsx-ccp.log | grep -ia "Untrusted Chain\|Client certificate not allow-listed:\|Client certificate not white-listed:"

If TN certificate expiry:

#grep -ia "Certificate expired" /var/log/cloudnet/nsx-ccp.log

If TN Certificate not valid yet:

#grep -ia "Certificate not valid yet for" /var/log/cloudnet/nsx-ccp.log

If TN Certificate Revoked or CRL related errors:

#egrep -ia "(CRL check failed:|Certificate revoked for)" /var/log/cloudnet/nsx-ccp.log

4. Take appropriate action based on error:

Either replace TN certificate
Or Sync TN certificate using nsxcli push host-certificate command.

After certificate fix, run "get controllers" and verify Status shows "connected"

More details follow KB: https://knowledge.broadcom.com/external/article/345870/nsx-certificate-expired-alarm.html

CONTROLLER_UNREACHABLE

Resolved FQDN IP address is not reachable.

Please check following:

Check if FQDN is correctly configured: grep -r "<fqdn" /etc/vmware/nsx/controller-info.xml
Test DNS resolution: nslookup <controller-fqdn>
Verify resolved ip addresses are reachable from TN: ping <resolved-controller-ip>

After fix, run "get controllers" and verify Status shows "connected" within 1-2 minutes.

CRL_CERTIFICATE_REVOKED

Controller certificate has been revoked (marked as untrusted).

Please check following:

1. Verify the reason behind the controller certificate being included in the revoked certificate list.

#/opt/vmware/nsx-nestdb/bin/nestdb-cli --json --cmd get vmware.nsx.nestdb.CrlCertificatesCacheMsg

2. Upload/Re-generate new controller certificate.

more details follow kb: https://knowledge.broadcom.com/external/article/329221

CRL_VALIDATION_FAILED

Certificate trust store service issue on NSX Manager.

Please check following:

1. Check proton and appl-proxy services status on NSX Manager.

#/etc/init.d/nsx-proton status

#/etc/init.d/nsx-appl-proxy status

2. Check the manager’s connectivity on TN using NSXCLI "get managers" command.

3. start the services, it is not running.

more details follow kb: https://knowledge.broadcom.com/external/article/329221

HOST_NOT_FOUND

Host cannot find NSX manager by name (DNS issue)

Please check following:

Check if FQDN is correctly configured: grep -ia "<fqdn" /etc/vmware/nsx/controller-info.xml
Test DNS resolution: nslookup <controller-fqdn>
If DNS issue, fix DNS servers or use IP address instead.

After DNS fix, run "get controllers" and verify Status shows "connected" within 1-2 minutes.

HOST_REJECTED_CONTROLLER_CERT

Controller certificate has expired, or not trusted by nsx-proxy on TN.

Please check following:

1. Review the nsx-proxy logs to identify the reason for the failure.

#grep -ia "Certificate validation failed" <LOG_FILE> | grep -ia nsx-proxy

If the error “self-signed certificate” occurs, it indicates that the controller certificate is untrusted. Verify that the controller certificate matches the certificate located in `/etc/vmware/nsx/controller-info.xml`.

If the error “certificate is not yet valid” occurs, it indicates that the controller certificate is not yet valid. Could be NTP sync issue.

If the error “certificate has expired” occurs, it indicates that the controller certificate is expired. Replace controller certificate.

Verify that the controller certificate matches the certificate located in `/etc/vmware/nsx/controller-info.xml`.

After certificate fix, run "get controllers" and verify Status shows "connected".

More details follow KB: https://knowledge.broadcom.com/external/article/345870/nsx-certificate-expired-alarm.html

MAINTENANCE_MODE

TN is in maintenance mode (expected during upgrades or patching)

No action needed if intentional.

To exit maintenance mode:

In NSX UI: System > Fabric > Hosts > Select host > Actions > Exit Maintenance Mode

After disabling maintenance mode, run "get controllers" and verify Status shows "connected".

More details: https://techdocs.broadcom.com/us/en/vmware-cis/nsx/vmware-nsx/4-2/upgrade-guide/troubleshooting-upgrade-failures-nsxt/unable-to-upgrade-host-placed-in-nsx-maintenance-mode.html

VERSION_MASTERSHIP_HANDSHAKE_FAILURE

In this case, the "get controller" status is set to "disconnected" with "Failure Reason" as "NA" due to a version mastership handshake failure with the Controller.

1. Stub creation failure with the Version Mastership Handshake service.
2. Version Check failures: This includes either call failures or version compatibility check failures with the Controller.
3. GetMaster failures: This includes either call failures or received master Controller UUID that is not present in /etc/vmware/nsx/controller-info.xml.
4. DataSync call failures: This includes either call failures or the DataSync prepare stub taking longer than expected.

1.7. List of services involved in maintaining controller connectivity healthy

Node Type	Service Name	Service Status Command	Service Start Command	Reason
TN	nsx-proxy	/etc/init.d/nsx-proxy status	/etc/init.d/nsx-proxy start	Needed for interaction/connection with UA CCP service.
TN	nsx-opsagent	/etc/init.d/nsx-opsagent status	/etc/init.d/nsx-opsagent start	Needed for controller info details which is used by nsx-proxy to connect to UA CCP service.
TN	nsx-nestdb	/etc/init.d/nsx-nestdb status	/etc/init.d/nsx-nestdb start	Needed for CCP to push policy configuration to the NestDB on TN.
UA	nsx-ccp	/etc/init.d/nsx-ccp status	/etc/init.d/nsx-ccp start	Needed for TN, for nsx-proxy to connect to CCP.
UA	nsx-appl-proxy	/etc/init.d/nsx-appl-proxy status	/etc/init.d/nsx-appl-proxy start	Needed for the controller related details which would be sent to TN.
UA	nsx-proton	/etc/init.d/nsx-proton status	/etc/init.d/nsx-proton start	Needed for certificate/controller details which would be sent to TN.

If any of the above listed service is down, then execute service start command as listed above and execute "get controllers" on the TN (ESXi Hosts, Edge Nodes or VNA Nodes) using NSXCLI to check the latest connectivity status.

Additional Information

Cause/resolution via runbook

Execute the nsx_proxy runbook on ESX, Edge or VNA transport node.

If there is any step which fails as part of runbook execution then please follow the remediation mentioned as part of each runbook step.

On 4.2.x and 9.0.x, nsx_proxy runbook is marked as internal. Run the below commands to execute nsx_proxy runbook from nsxcli. (no runbook available for earlier releases)

set service nsx-ods running-level internal
start invocation runbook nsx_proxy

On 9.1.x and above, nsx_proxy runbook is marked as external. Run the below command to execute the nsx_proxy runbook from nsxcli.

start invocation runbook nsx_proxy

Detailed runbook steps

1. Nsx-proxy service status
Conclusion : Service nsx-proxy is down
Recommendation : Please restart nsx-proxy by invoking `/etc/init.d/nsx-proxy restart`.
Artifact Bundle : <none>
Steps

Step Number : 1
Step Action : Fetch nsx-proxy service status.
Step Result : Service nsx-proxy is down

2. Nsx-opsagent service status
Conclusion : Service nsx-opsagent is down
Recommendation : Please restart nsx-opsagent by invoking `/etc/init.d/nsx-opsagent restart`.
Artifact Bundle : <none>
Steps

Step Number : 2
Step Action : Fetch nsx-opsagent service status.
Step Result : Service nsx-opsagent is down

3. Nsx-nestDb service status
Conclusion : Service nsx-nestdb is down
Recommendation : Please restart nsx-nestdb by invoking `/etc/init.d/nsx-nestdb restart`.
Artifact Bundle : <none>
Steps

Step Number : 3
Step Action : Fetch nsx-nestdb service status.
Step Result : Service nsx-nestdb is down

4. Maintenance mode
Conclusion : Maintenance mode is enabled on this transport node, existing connection between controller channel and transport node is closed.
Recommendation : To enable the connection between controller channel and transport node please disable the NSX maintenance mode from the manager UI console.
Artifact Bundle : <none>
Steps

Step Number : 4
Step Action : Check whether Maintenance mode is enabled on Transport Node.
Step Result : Maintenance mode is enabled on this transport node, existing connection between controller channel and transport node is closed.

5. Authenticity verification for appliance-info.xml content
Conclusion : Detected duplicate nodes in Appliance nodes configuration settings, node details: [IPv4Address('x.x.x.x')].
Recommendation : To get the thumbprint run this following command in NSXCLI on Unified Appliance node 'get certificate api thumbprint'.
Login into NSXCLI and run the command 'sync-aph-certificates <manager-hostname-or-ip-address[:port]> username <username> thumbprint <thumbprint> [password <password>]'.
Restart nsx-proxy service by invoking `/etc/init.d/nsx-proxy restart' on transport node.
Artifact Bundle : <none>
Steps

Step Number : 5
Step Action : Check whether Appliance nodes settings are empty or duplicate.
Step Result : Detected duplicate nodes in Appliance nodes configuration settings, node details: [IPv4Address('x.x.x.x')].

6. Authenticity verification for controller-info.xml content
Conclusion : Detected duplicate nodes in Controller channel configuration settings, node details: [IPv4Address('x.x.x.x')].
Recommendation : On Unified Appliance, login into NSXCLI and run 'set ccp-info' to publish the latest Controller channel configuration settings.
Please restart nsx-proxy by invoking `/etc/init.d/nsx-proxy restart` to reconfigure the Controller channel configuration settings on this transport node.
Artifact Bundle : <none>
Steps

Step Number : 6
Step Action : Check whether Controller nodes settings are empty or duplicate.
Step Result : Detected duplicate nodes in Controller channel configuration settings, node details: [IPv4Address('x.x.x.x')].

7. Appliance proxy service on UA is down
Conclusion : Appliance channel ping test failed for nodes: [] and port test failed for nodes: [IPv4Address('x.x.x.x')].
Recommendation : For ping failure please fix the network issues as the mentioned Appliance channel nodes are not reachable.
For port failure please check cluster status by invoking '/api/v1/cluster/status' and firewall status.
For more details, please invoke CCP-TN runbook on Unfiied Appliance.
Artifact Bundle : <none>
Steps

Step Number : 7
Step Action : Perform ping and port status check for all Appliance channel nodes.
Step Result : Appliance channel ping test failed for nodes: [] and port test failed for nodes: [IPv4Address('x.x.x.x')].

8. Controller service on UA is down
Conclusion : Controller channel ping test failed for nodes: [] and port test failed for nodes: [IPv4Address('x.x.x.x')].
Recommendation : For ping failure please fix the network issues as the mentioned Controller channel nodes are not reachable.
For port failure please check cluster status by invoking '/api/v1/cluster/status' and firewall status.
For more details, please invoke CCP-TN runbook on Unfiied Appliance.
Artifact Bundle : <none>
Steps

Step Number : 8
Step Action : Perform ping and port status check for all Controller channel nodes.
Step Result : Controller channel ping test failed for nodes: [] and port test failed for nodes: [IPv4Address('x.x.x.x')].

9. Controller node rejected TN certificate
Conclusion : Controller channel has rejected transport node certificate for UUID: d866314b-####-####-####-8048fd906354.
Recommendation : To get the thumbprint run this following command in NSXCLI on Unified Appliance node 'get certificate api thumbprint'.
Login into NSXCLI and run the command on transport node by providing username, password and thumbprint. 'push host-certificate <hostname-or-ip-address[:port]> username <username> thumbprint <thumbprint>'.
Artifact Bundle : <none>
Steps

Step Number : 9
Step Action : Perform certification validation for all Controller channel nodes.
Step Result : Controller channel has rejected transport node certificate for UUID: d866314b-####-####-####-8048fd906354.

10. TN rejected controller node certificate
Conclusion : Transport node has rejected Controller channel certificate for node UUID: d866314b-####-####-####-8048fd906354.
Artifact Bundle : <none>
Steps

Step Number : 10
Step Action : Perform certification validation for all Controller channel nodes.
Step Result : Transport node has rejected Controller channel certificate for node UUID: d866314b-####-####-####-8048fd906354.

11. TN rejected Appliance node certificate
Conclusion : Transport node has rejected Appliance channel certificate for node UUID: d866314b-####-####-####-8048fd906354.
Artifact Bundle : <none>
Steps

Step Number : 9
Step Action : Perform certification validation for all Appliance channel nodes.
Step Result : Transport node has rejected Appliance channel certificate for node UUID: d866314b-####-####-####-8048fd906354.

12. CRL validation for controller node certificate revoked recommendation
- !Message
key: controller_channel_certificate_revoked
type:
- rcmd
message: |
Please replace the Controller channel node certificate using '/api/v1/trust-management/certificates/<cert-id>?action=apply_certificate'.\n\t\t
For certificate revocation validation failed, on Unified Appliance execute '/etc/init.d/proton restart' and login into NSXCLI and execute the command 'restart service applianceproxy'.

13. CRL validation for appliance node certificate revoked recommendation
- !Message
key: appliance_channel_certificate_revoked
type:
- rcmd
message: |
Please replace the Appliance channel node certificates using 'api/v1/trust-management/certificates/<certificate-id>?action=apply_certificate&service_type=APH_TN&node_id=<mp-id-corresponding-to-aph>'.\n\t\t
To get the thumbprint run this following command in NSXCLI on Unified Appliance node 'get certificate api thumbprint'.\n\t\t
On Transport node stop nsx-proxy and execute the NSXCLI command 'sync-aph-certificates <manager-hostname-or-ip-address[:port]> username <username> thumbprint <thumbprint> [password <password>]'.\n\t\t
On Transport node, restart nsx-proxy by invoking '/etc/init.d/nsx-proxy restart'.\n\t\t
For certificate revocation validation failed, on Unified Appliance login into NSXCLI and execute the command 'restart service applianceproxy' and '/etc/init.d/proton restart'.

14. Transport node certificate expired recommendation
- !Message
key: transport_node_certificate_expired_rcmd
type:
- rcmd
message: |
If the Transport Node<->Controller channel connection is up then execute /api/v1/trust-management/certificates/action/replace-host-certificate/<TN-UUID>.\n\t\t
Else, please delete '/etc/vmware/nsx/host-cert.pem', '/etc/vmware/nsx/host-privkey.pem'.\n\t\t
On Transport node, restart nsx-proxy by invoking '/etc/init.d/nsx-proxy restart' to generate new certificate file.\n\t\t
To get the thumbprint run this following command in NSXCLI on Unified Appliance node 'get certificate api thumbprint'.\n\t\t
Login into NSXCLI and run the command on transport node by providing username, password and thumbprint. 'push host-certificate <hostname-or-ip-address[:port]> username <username> thumbprint <thumbprint>'.

15. Controller node certificate expired recommendation
- !Message
key: controller_cert_expired_rcmd
type:
- rcmd
message: |
Please replace the Controller channel node certificate using '/api/v1/trust-management/certificates/<cert-id>?action=apply_certificate'.

16. Appliance node certificate expired recommendation
- !Message
key: appliance_cert_expired_rcmd
type:
- rcmd
message: |
Please replace the Appliance channel node certificates using 'api/v1/trust-management/certificates/<certificate-id>?action=apply_certificate&service_type=APH_TN&node_id=<mp-id-corresponding-to-aph>'.\n\t\t
On Transport node stop nsx-proxy by invoking '/etc/init.d/nsx-proxy stop' and execute the NSXCLI command 'sync-aph-certificates <manager-hostname-or-ip-address[:port]> username <username> thumbprint <thumbprint> [password <password>]'.\n\t\t
On Transport node, restart nsx-proxy by invoking '/etc/init.d/nsx-proxy restart'.

Feedback

thumb_up Yes

thumb_down No