Due to heavy volume of communication.control_channel_to_transport_node_down_long alarms, the alarm service has temporarily stopped reporting alarms of this type. The NSX UI and GET /api/v1/alarms NSX API are not reporting new instances of these alarms; however, syslog entries and SNMP traps (if enabled) are still being emitted reporting the underlying event details. When the underlying issues causing the heavy volume of communication.control_channel_to_transport_node_down_long alarms are addressed, the alarm service will start reporting new communication.control_channel_to_transport_node_down_long alarms when new issues are detected again. 'control_channel_to_transport_node_down_long' alarms can be observed as 'open' alarms. VMware NSX 4.x
The 'heavy volume of communication.control_channel_to_transport_node_down_long' appears when large number of (usually over 100) 'control_channel_to_transport_node_down_long' are kept open and not resolved/ not suppressed for long period of time.
One possible reason of such 'control_channel_to_transport_node_down' alarms not being addressed and investigated is that these alarms are generated due to stale transport nodes. Perhaps the hosts are removed from the vCenter inventory or are powered down permanently without first being properly unprepared through the NSX Manager. The stale transport nodes will show up under Fabric > Hosts > 'Standalone' tab.
Control Channel To Transport Node Down Long Alarm
For heavy volume alarm for other types of issues, please refer to the following KB article: