MQTT bridge between two broker

3rd Party Modules
1

image
image438×431 12 KB

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?

2

Bridging in EMQX is setup by adding topics in both directions. 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:

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:

mosquitto_sub -L "mqtts://broker.mydomain.com:8883/spBv1.0/Site1/#" -F "%I %t"

With each console watching one broker.

2 Likes
3

Thank you, Justin Brzozoski.
I will try to read this and will be back if I get any progress.

4

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.

1 Like
5

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.

1 Like
6

I don't think so we can cluster on premises and cloud as being very different env!!! Have you done that already?

7

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.

1 Like