Here on IBM IoT MessageSight, we’ve been trying out using F5 BIG-IP. You can configure BIG-IP using iRules, to route connections and load balance across a set of MessageSight servers. We created some sample iRules to configure F5 BIG-IP to extract an MQTT client ID from an MQTT CONNECT message, perform a server map lookup, and route the connection to the appropriate IBM¬ģ MessageSight server. This blog describes using the samples and shares some useful information so that you can:

  • ¬†¬†¬† Use an F5 BIG-IP iRule to extract an MQTT client ID from an MQTT CONNECT message.
  • ¬†¬†¬† Perform a server map lookup, and route the connection to the appropriate IBM MessageSight.
  • ¬†¬†¬† Update the server map via the iFile mechanism in BigIP and learn how the configuration is synchronized to a STANDBY BIG-IP server.
  • ¬†¬†¬† Terminate TLS connections on BIG-IP, and forward the device connection to one of multiple IBM MessageSight servers.
  • ¬† ¬† Configure a virtual server in BIG-IP which uses the sample iRule.

Why not try this out for yourself?

F5 BIG-IP

You can use F5 BIG-IP and iRules to control the route of incoming messages to servers in the private VLAN (server side).

image showing clientside and serverside contexts in an IBM MessageSight environment using F5 BIG-IP

You can configure BIG-IP using iRules, to route connections and load balance across a set of MessageSight servers in the private VLAN.  The set of servers can be standalone or pairs of MessageSight servers in an HA configuration.

The public VLAN is the network where client devices connect to BIG-IP, and the private VLAN is the network on which BIG-IP connects to IBM MessageSight servers.  Typically the devices will terminate TLS connections on BIG-IP and the communication between BIG-IP and MessageSight servers will be over non-TLS TCP connections.

iRules

You can write iRules by using the F5 iRule Editor, an integrated code editor, which performs basic syntax checking and provides bidirectional synchronization of iRule updates with BIG-IP.

We created two sample iRules for you to try out, one for devices which require TLS communications, and the other for devices which do not require TLS communications (i.e. plain TCP):

  • ¬†¬†¬†mqttTCP – for non-TLS device connections to BIG-IP
  • ¬†¬† mqttTLS¬† – for TLS device connections to BIG-IP

Both rules have virtually identical code, the primary difference being the client side iRule events which are specified, for example, CLIENTSSL_DATA as opposed to CLIENT_DATA. The sample mqttTCP contains 215 lines of Tool Command Language (Tcl) code. The bulk of the logic is in CLIENT_DATA where the MQTT CONNECT message is processed. Both iRules can parse the MQTT connect message and extract the client ID and clean session flag.

  • ¬†¬†¬† Minimum message length checked (or return and wait for more data on the client connection)
  • ¬†¬†¬† Parse MQTT fixed header and read variable length field, reject connection immediately if not MQTT CONNECT message
  • ¬†¬†¬† Client ID field extracted
  • ¬†¬†¬† Clean Session field extracted
  • ¬† ¬† Perform a lookup in the server map and match the MQTT client ID against a table of regular expressions. ¬†Route the device to MessageSight server corresponding the first matching regular expression.
  • ¬† ¬† If the first MessageSight server in the destination list is down, then try the next server in the list. ¬†If all servers in the list are down then close the device connection.

Using an iFile to load the server map from

The example uses an iFile which is read in the RULE_INIT iRule event to create an in-memory map of client IDs to destination server(s). You can use the iFile across an HA pair of BIG-IP servers to maintain consistency, without needing to manually synchronize between the BIG-IP servers. To change the client affinity you can then upload the new iFile and update the iRule to load the updated affinity map iFile on the active BIG-IP server.

As an alternative to an iFile, you can create an iRule to administer another iRule by using a RESTful interface. Take a look here to find out more, Restful Access to BIG-IP Subtables

Introduction to configuring F5 BIG-IP Virtual Edition

Here’s a link to a YouTube video about Configuring BIG-IP, https://www.youtube.com/watch?v=Li9WO2M2YLY

And a link to a YouTube video about Configuring High Availability in F5 BIG-IP LTM 11.x Config Sync Failover Trafficgroup, https://www.youtube.com/watch?v=tI2m2qYfLqY

You can find out more at the F5 website here https://devcentral.f5.com/irules

Configuring a virtual server to use an iRule

From Local Traffic > Virtual Servers > Virtual Server List create a virtual server that devices will connect to.  When configuring the virtual server, from the Resources tab, select the sample iRule to associate with the virtual server.

image

Configuring SNAT

Source network address translation is required if BIG-IP is not the default route on the IBM¬ģ MessageSight servers.

image

Configuring the sample MQTT iRule

This sample iRule reads an iFile which contains a pre-defined client/server mapping, for device routing, that the administrator has already determined.

The format of the iFile is as follows:

    <regular expression> <comma separated list of IBMMessageSight server IP addresses> <dest port>

The following is an example iFile that works with client IDs generated by mqttbench:

ser111_c.* 192.0.2.0,192.0.2.12 16901
ser112_c.* 192.0.2.7,192.0.2.34 16901
ser410_c.* 192.0.2.8,192.0.2.35 16901
ser132_c.* 192.0.2.9,192.0.2.36 16901
ser212_c.* 192.0.2.10,192.0.2.37 16901

In this example, MQTT devices with client ID starting with ser111_c will first attempt to be routed to 192.0.2.0 on port 16901. If this server is down, then the iRule will attempt to forward the connection to 192.0.2.12 on port 16901. The server list can be arbitrary length. With this iRule design it is not necessary to create Pool or Node configuration objects in BIG-IP.

Importing an iRule for MQTT client affinity

The following screen shots show how you can import an iFile into the BIG-IP application:

image showing F5 screen for importing an iFile into a BIG-IP application

andimage showing F5 screen of an iFile being imported

  • ¬†¬†¬† The name of the iFile ‚ÄúserverMap‚ÄĚ is hard coded in the iRule and you can import/update the content associated with the iFile.
  • ¬†¬†¬† F5 BIG-IP command line syntax for modifying an iFile is as follows: tmsh modify sys file ifile [ifile-name] source-path http://192.70.0.1/myifile.txt
  • ¬†¬†¬† When the iFile is modified, the RULE_INIT line in the iRule should be re-invoked by using change/save to the iRule

Inet port exhaustion

Inet port exhaustion happens when BIG-IP runs out of source ports for a given IP on the private VLAN. BIG-IP has been configured to use SNAT to translate the source IP of the MQTT device to that of one of the BIG-IP ‚Äúself IPs‚ÄĚ on the private VLAN for connections to IBM¬ģ MessageSight servers.

Creating self IP addresses on the private VLAN

You might need to create many self IP addresses on the private VLAN of BIG-IP in order to perform the connection tests.
The format of the key, that must be unique, is <src ip>:<src port> <dst ip>:<dst port>  By adding more self IP addresses on BIG-IP you can increase the <src ip> range and establish more connections. You can use the following formula to determine the total number of connections possible:

  • ¬†¬†¬† Total Connections = X * ~64K * Y * Z. Where X = the number of src IP, in this case BIG-IP self IP addresses on the private VLAN. Y = the number of dst IP addresses, in this case IBM MessageSight¬†¬† server IP addresses. Z = the number of dst port, in this case IBM MessageSight endpoints per server IP address.
  • ¬†¬†¬† For example, Z=1 (16901, a single endpoint), Y=2 (two physical appliances with a single IP per appliance), and X=21

Note that self IP addresses are floating. BiG-IP does not replicate local only self IP addresses to other high availability members. You should use floating IP addresses to achieve replication to other high availability servers.

Idle Timeout parameter

By default, BIG-IP will send a TCP reset (RST) to any connection which has been silent for 300 seconds. BIG-IP ignores TCP keepalive probes. You should increase the Idle timeout value on the TCP profile associated with your virtual server to avoid terminating connections earlier than desired.

For example, if your virtual server is using the tcp-wan-optimized TCP profile, then the Idle Timeout setting can be configured from Local Traffic > Profiles > Protocol > TCP > tcp-wan-optimized. Sending an MQTT PING request on a connection is sufficient to prevent an Idle Timeout on that connection.

Note: The sample programs are provided “AS IS”, without warranty of any kind.

Join The Discussion

Your email address will not be published. Required fields are marked *