Openflowplugin has an application (lldp speaker) that sends LLDP packet out of the controller to the switch and once it receive it back from other switch, it determine that there is a link between two switches.

In this scenario, there is a possibility that any other controller can connect to the switch and spoof the LLDP packets and controller can learn wrong link. This is a security vulnerability, which was fixed in the last release.

To fix this security vulnerability we added few checks when controller receives packet from switch to make sure that this packet was sent by the same controller. To make sure of that controller internally generate hash using the string value return by RuntimeMXBean.
ManagementFactory.getRuntimeMXBean().getName() (this basically returns the string – pid@hostname e.g 123@of-node-1)
https://github.com/opendaylight/openflowplugin/blob/master/applications/topology-lldp-discovery/src/main/java/org/opendaylight/openflowplugin/applications/topology/lldp/utils/LLDPDiscoveryUtils.java#L130

So this works perfectly fine in the single node cluster.

Now in the 3 node cluster environment, there is a possibility that two switches (Switch 1 & Switch 2) will be owned by two different node in the cluster. So if controller 1 sends LLDP packet to switch1 and it goes to Switch 2, switch 2 will send that packet to controller 2 (master of switch 2). Both controller will internally call
RuntimeMXBean().getName() and each cluster node will get different string name (given that controllers are running on different VM and VMs has different host name and the pid of the java process is different for each cluster node) and the check will fail, and both the controller will assume that it's a security attack, because that LLDP packet was not sent by it.

To fix this there are two options (1) Provide a key string through configuration file or config subsystem that each controller will use internally to generate the hash value and this will make sure that each controller will generate the same hash.
(2) Clustering can provide a cluster wide unique ID (cluster id) that application can use to generate this hash value and use it for authenticity across different cluster node.
Option (2) is more secure option because it generates the unique id at run time and it's more difficult to spoof it compare to (1). But (1) is as good as the current fix we have.