# MQTT bridge between two broker **URL:** \ **Category:** 3rd Party Modules\ **Tags:** ignition81\ **Created:** [November 21, 2024, 11:47am UTC](https://forum.inductiveautomation.com/t/mqtt-bridge-between-two-broker/98927 "2024-11-21T11:47:23Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![yoones\_sanjabi1](https://avatars.discourse-cdn.com/v4/letter/y/e47c2d/32.png) [@yoones\_sanjabi1](https://forum.inductiveautomation.com/u/yoones_sanjabi1)\ **Post date:** [November 21, 2024, 11:47am UTC](https://forum.inductiveautomation.com/t/mqtt-bridge-between-two-broker/98927/1 "2024-11-21T11:47:23Z")
![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/a/d/ad1df6bfafb7c02285e137693b78903028f2c7cb.png) Hello, I am experiencing an issue while bridging two EMQX brokers (local to global). Both brokers are running EMQX. Publishing data works without any problems when done locally on either broker; for example: - Publishing to the local broker allows me to successfully subscribe and receive data locally. - Similarly, publishing directly to the global broker works as expected, and data is received without issues. However, the issue arises when I attempt to bridge the local broker to the global broker. In this case, no data is received on the global broker. Upon inspecting the logs, I noticed the following entries: _Received DDATA for NULL edge node that didn't send a birth:spBv1.0/Site1/DDATA/Line1/devices0_ _Requesting Rebirth from Line1/devices0, cause: Received a message for edge node that is offline_ Bridge local to global: SELECT \*FROM "spBv1.0/Site1/#" Could someone provide insights or troubleshooting steps to resolve this? ---
**Author:** ![justin.brzozoski](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/justin.brzozoski/32/13452_2.png) [@justin.brzozoski](https://forum.inductiveautomation.com/u/justin.brzozoski)\ **Post date:** [November 22, 2024, 4:20pm UTC](https://forum.inductiveautomation.com/t/mqtt-bridge-between-two-broker/98927/2 "2024-11-22T16:20:55Z")
Bridging in EMQX is setup by [adding topics in both directions](https://docs.emqx.com/en/emqx/latest/data-integration/data-bridge-mqtt.html). Your sample above only shows one direction. But if there's any overlap in the topic spaces (i.e. there could be a topic `spBv1.0/Site1/NDATA/foo` that goes both ways on the bridge) then you need to also turn on some anti-looping features. This issue on github has a rambling discussion: > **[What is the correct configuration for a 2-way bridge? · emqx/emqx ·...](https://github.com/emqx/emqx/discussions/4534)** > > I have failed to establish a 2-way bridge between two EMQx brokers that does not results in an infinite loop of publishes between the two brokers. The desired configuration is: a single broker both... Short version: - Use MQTTv3 or v4 for your bridge connections (at least until they add no-local support in v5) - Be sure to check the "Bridge" mode flag on those connections - Enable `ignore_loop_deliver` on both servers either globally or at least in the zones that the bridge connections are controlled under That error you're seeing is the sort of thing you get when MQTT Engine hears a edge node talking that it didn't previously know about, and it will try to send a NCMD to the edge node to request an NBIRTH back with more info about it. If you only have the bridge running in one direction, then the NCMD won't be able to get back across the bridge to the edge node. For debugging, I recommend just watching which message topics go by on BOTH brokers at once, and seeing if certain messages are not bridging properly. Don't try to decode the payloads since they're binary, just watching the topics is good enough. I usually just setup two consoles and use the command line mosquitto client like this: ```python mosquitto_sub -L "mqtts://broker.mydomain.com:8883/spBv1.0/Site1/#" -F "%I %t" ``` With each console watching one broker. ---
**Author:** ![yoones\_sanjabi1](https://avatars.discourse-cdn.com/v4/letter/y/e47c2d/32.png) [@yoones\_sanjabi1](https://forum.inductiveautomation.com/u/yoones_sanjabi1)\ **Post date:** [November 25, 2024, 11:39am UTC](https://forum.inductiveautomation.com/t/mqtt-bridge-between-two-broker/98927/3 "2024-11-25T11:39:07Z")
Thank you, Justin Brzozoski. I will try to read this and will be back if I get any progress. ---
**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\ **Post date:** [November 27, 2024, 8:03am UTC](https://forum.inductiveautomation.com/t/mqtt-bridge-between-two-broker/98927/4 "2024-11-27T08:03:33Z")
Would it be better to cluster the EMQx servers rather than trying to bridge them? That should allow them to act as 1 broker and connections to either would publish births to any server connected to either broker. ---
**Author:** ![justin.brzozoski](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/justin.brzozoski/32/13452_2.png) [@justin.brzozoski](https://forum.inductiveautomation.com/u/justin.brzozoski)\ **Post date:** [November 27, 2024, 2:58pm UTC](https://forum.inductiveautomation.com/t/mqtt-bridge-between-two-broker/98927/5 "2024-11-27T14:58:59Z")
If you're okay with both brokers having nearly matching configs in terms of permissions and full topic-space access to each other and bandwidth isn't an issue, then clustering is probably better. If you need the two brokers to differ in some way, or are trying to restrict topic access on one or the other, or just don't want to use up the bandwidth for all the traffic all the time, then bridging lets you pick-and-choose a subset of traffic and customize each broker more extensively. ---
**Author:** ![yoones\_sanjabi1](https://avatars.discourse-cdn.com/v4/letter/y/e47c2d/32.png) [@yoones\_sanjabi1](https://forum.inductiveautomation.com/u/yoones_sanjabi1)\ **Post date:** [November 27, 2024, 11:01pm UTC](https://forum.inductiveautomation.com/t/mqtt-bridge-between-two-broker/98927/6 "2024-11-27T23:01:48Z")
I don't think so we can cluster on premises and cloud as being very different env!!! Have you done that already? ---
**Author:** ![michael.flagler](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/michael.flagler/32/26272_2.png) [@michael.flagler](https://forum.inductiveautomation.com/u/michael.flagler)\ **Post date:** [November 27, 2024, 11:04pm UTC](https://forum.inductiveautomation.com/t/mqtt-bridge-between-two-broker/98927/7 "2024-11-27T23:04:15Z")
I haven't clustered between on-prem and cloud, but if I recall correctly in EMQx, the configuration to cluster 2 servers is pretty easy (point them to each other's IP with a shared encryption key if I recall). It does really depend though if they're configured differently from each other or if they share a configuration/users/etc.