Are messaging protocols such as MQTT, AMQP and FIX supported?
Short answer
Yes, with an L7 TCP vService. Connections are distributed at the connection level without the protocol being parsed; for this reason, no routing is done according to the client ID or the topic. MQTT (8883) and AMQPS (5671) connections opened directly with TLS can be terminated on TR7 with TCP + TLS. The connections of these protocols are long-lived: so that they are not dropped while idle, the Tunnel(Websocket) Timeout (default 120 seconds) in the Timeouts profile is increased, and if the number of concurrent connections can exceed 20,000, the Max. Total Connections value in the vService Limits profile is increased.
Problem: Why Do Messaging Connections Require Special Settings?
MQTT, AMQP and FIX clients connect to the server once and keep the connection open for hours, or even days; in between, only small liveness (keepalive / heartbeat) messages are sent. These connections are closed if no data flows for a certain period. In setups where thousands of devices connect, the number of concurrent connections can also exceed the default limit. In protocols such as FIX, the other party usually performs authorization based on the IP address and expects the session to continue on the same server.
Solution
Messaging Traffic with an L7 TCP vService
- How it works Each new connection is sent to a broker and stays there until it closes; new connections of the same client return to the same broker with Hash persistence.
- Where it is opened vService → Type: L7 TCP → Details → LB Algorithm → Persistence; Timeout; vService Limits
- Requirement The protocol running over TCP
- vService type L7 TCP
- Backend Service side If TLS is terminated on TR7, the broker listens on the unencrypted port (e.g. MQTT 1883, AMQP 5672). By default, the broker sees the connections as coming from TR7's IP; if the client IP is required, SNAT → Use Client IP is used on the Backend Service.
Step-by-Step Configuration
On the Load Balancer → Profiles → Health Checks screen, the Add button is clicked (how to add).
Name is entered and TCP is selected as the Check Type; if send/expect steps at the protocol level are required, steps are added to the TCP Scenario field. The check type comes as HTTP by default and cannot be changed after it is saved.
The Add button at the bottom of the form is clicked.
On the Load Balancer → Backend Services screen, the Add button is clicked (How is a Backend Service added; which information is required?).
Backend Service Name and Address (e.g. 192.0.2.90:1883) are entered; in the Health Check field, the profile created in steps 1–3 is selected.
The Add button at the bottom of the form is clicked. Steps 4–6 are repeated for each broker.
On the Load Balancer → Profiles → Timeouts screen, the Add button is clicked (how to add).
Name is entered and a value greater than the protocol's keepalive / heartbeat interval is written in seconds in the Tunnel(Websocket) Timeout field (at most 60,000).
The Add button at the bottom of the form is clicked.
If the number of concurrent connections can exceed 20,000, the Add button is clicked on the Load Balancer → Profiles → vService Limits screen (how to add).
Name is entered and Max. Total Connections (default 20,000) is raised above the expected number of devices.
The Add button at the bottom of the form is clicked.
The Load Balancer → Load Balancer vService List → Add steps are followed; Name is entered and L7 TCP is selected as the Type.
The port of the protocol is written. For MQTT 8883 or AMQPS 5671, where TLS will be terminated on TR7, TCP + TLS is selected as the Protocol and a certificate is selected in the Certificate field that appears; for connections that are unencrypted or whose TLS will stay on the broker, TCP is selected. If the certificate is not on TR7, it is first uploaded with Certificates & PKI → SSL/TLS Certificates → Add (How do I upload my certificate to TR7; which formats are supported?). If the IP is not in the list, it is first added with Network → Interfaces → Actions → Add IP (Why can't I type the Frontend IP manually; what should I do to use an IP that is not in the list (e.g. IPv6) on a vService?).
In the Default Backend Services table, the Backend Services added in steps 4–6 are selected.
The Details switch at the top right of the form is turned on; in the LB Algorithm box, Hash is selected as the Persistence and Client IP Address is selected in the Hash Key field.
In the Details panel, the Timeout box is checked and the profile created in steps 7–9 is selected, and if needed, the vService Limits box is checked and the profile created in steps 10–12 is selected.
The Save button is clicked. In a cluster setup, the change is also transferred to the peer device with the default auto-sync; if Manual Sync Mode is on, it is sent manually with Synchronize.
Verification
mosquitto_pub -h mqtt.example.com -p 8883 --cafile ca.pem -t test -m merhabaThe message reaches the subscribed clientThe connection counts and distribution are monitored on the vService Sessions and Live Stats screens of the vService.
The connections are spread across the brokers; the total is below the Max. total connections valueCommon Mistakes
- Leaving the timeout at the default. The Tunnel(Websocket) timeout is 120 seconds; the connections of devices with a longer keepalive interval are closed and the devices reconnect constantly.
- Overlooking the connection limit. The Max. Total Connections default is 20,000; when the limit is reached, new connections are not accepted and are kept waiting until room opens up.
- Expecting routing by topic. TR7 does not parse MQTT or AMQP messages; routing is at the connection level.
- Not preserving the IP in FIX. If the other party authorizes by IP and the FIX server must see the client IP, SNAT → Use Client IP is used on the Backend Service.
How it is done in the documentation
