Added note about receptor not listening

downstream/assemblies/platform/assembly-network-ports-protocols.adoc

@@ -103,6 +103,30 @@ ALLOW connection from controller(s) to Receptor port |
 * Hybrid nodes act as a combination of control and execution nodes, and therefore Hybrid nodes share the connections of both. 
 
 * If `receptor_listener_port` is defined, the machine also requires an available open port on which to establish inbound TCP connections, for example, 27199.
+
+* It might be the case that some servers do not listen on receptor port (the default is 27199)
++
+Suppose you have a  Control plane with nodes A, B, C, D
++
+The RPM installer creates a strongly connected peering between the control plane nodes with a least privileged approach and opens the tcp listener only on those nodes where it is required. All the receptor connections are bidirectional, so once the connection is created, the receptor can communicate in both directions. 
++
+The following is an example peering set up for three controller nodes 
++
+Controller node A --> Controller node B
++
+Controller node A --> Controller node C
++
+Controller node B --> Controller node C
++
+You can force the listener by setting
++
+`receptor_listener=True`
++
+However, a connection Controller B --> A is likely to be rejected as that connection already exists.
++
+This means that nothing connects to Controller A as Controller A is creating the connections to the other nodes, and the following command does not return anything on Controller A:
++
+`[root@controller1 ~]# ss -ntlp | grep 27199 [root@controller1 ~]#`
 ==== 
 
 .{InsightsName}

downstream/modules/platform/proc-define-mesh-node-types.adoc

@@ -149,6 +149,33 @@ Run the following command to open port 27199 for receptor communication (Make su
 ----
 sudo firewall-cmd --permanent --zone=public --add-port=27199/tcp
 ----
++
+[NOTE]
+====
+It might be the case that some servers do not listen on receptor port (the default is 27199)
+
+Suppose you have a  Control plane with nodes A, B, C, D
+
+The RPM installer creates a strongly connected peering between the control plane nodes with a least privileged approach and opens the tcp listener only on those nodes where it is required. All the receptor connections are bidirectional, so once the connection is created, the receptor can communicate in both directions. 
+
+The following is an example peering set up for three controller nodes 
+
+Controller node A --> Controller node B
+
+Controller node A --> Controller node C
+
+Controller node B --> Controller node C
+
+You can force the listener by setting
+
+`receptor_listener=True`
+
+However, a connection Controller B --> A is likely to be rejected as that connection already exists.
+
+This means that nothing connects to Controller A as Controller A is creating the connections to the other nodes, and the following command does not return anything on Controller A:
+
+`[root@controller1 ~]# ss -ntlp | grep 27199 [root@controller1 ~]#`
+====
 
 . Run the following playbook on the machine where you want to update your automation mesh:
 +