A Simple One-way Generic MRF Implementation to load balance syslog message
The BIG-IP Generic Message Protocol implements a protocol filter compatible with MRF (Message Routing Framework).MRF is designed to implement the most complex use cases, but it can be daunting if you need to create a simple configuration. This article provides a simple baseline to understand the relationships of the MRF components and how they can be combined for a simple one way implementation . A production implementation will in most case be more complex. The following virtual, profiles and iRules load balances a one way stream of new line delimited messages (in this case syslog) to a pool of message consumers. The messages will be parsed and distributed with a simple MLB protocol. Return traffic will not be returned to the client with this configuration. To implement this we will need these configuration objects: Virtual Server - Accepts incoming traffic and configure the Generic Protocol Generic Protocol - Defines message parsing. Generic Router - Configures message routing and point to the Generic Route Generic Route- Points to a Generic Peer Generic Peer - Defines an LTM pool members and points to the Generic Transport Config Generic Transport Config - Defines the server side protocol and server side irule iRule - Defines the message peers (Connections in the message streams) In this case we have a single client that is sending messages to a virtual server that will then be distributed to 3 pool members. Each message will be sent to one pool member only.This can only be configured from the CLI and the official F5 recommendation is to not make any changes in the web GUI to the virtual server. This was tested with BIG-IP 12.1.3.5 and 14.1.2.6. Here is the virtual with a tcp profile andrequiredprotocol and routing profiles along withan iRule to setup the connection peer on the client side. ltm virtual /Common/mrftest_simple { destination /Common/10.10.20.201:515 ip-protocol tcp mask 255.255.255.255 profiles { /Common/simple_syslog_protocol { } /Common/simple_syslog_router { } /Common/tcp { } } rules { /Common/mrf_simple } source 0.0.0.0/0 source-address-translation { type automap } translate-address enabled translate-port enabled } The first profile is the protocol. The only difference betweenthe default protocol (genericmsg) is the field no-response must be configured to yes if this is a one way stream. Otherwise the server side will allocate buffers for return traffic that will cause severe free memory depletion. ltm message-routing generic protocol simple_syslog_protocol { app-service none defaults-from genericmsg description none disable-parser no max-egress-buffer 32768 max-message-size 32768 message-terminator %0a no-response yes } The Generic Router profilepoints to a generic route ltm message-routing generic router simple_syslog_router { app-service none defaults-from messagerouter description none ignore-client-port no max-pending-bytes 23768 max-pending-messages 64 mirror disabled mirrored-message-sweeper-interval 1000 routes { simple_syslog_route } traffic-group traffic-group-1 use-local-connection yes } The Generic Route pointsto theGeneric Peer: ltm message-routing generic route simple_syslog_route { peers { simple_syslog_peer } } The Generic Peer configures the server pool and points to the Generic Transport Config. Note the pool is configured here instead of the more common configuration in the virtual server. ltm message-routing generic peer simple_syslog_peer { pool mrfpool transport-config simple_syslog_tcp_tc } The Generic Transport Config also has the Generic Protocol configured along with the iRule to setup the server side peers. ltm message-routing generic transport-config simple_syslog_tcp_tc { ip-protocol tcp profiles { simple_syslog_protocol { } tcp { } } rules { mrf_simple } } An iRule must be configured on both the Virtual Server and Generic Transport Config. This iRule must be linked as a profile in both the virtual server and generic transport configuration. ltm rule /Common/mrf_simple { when CLIENT_ACCEPTED { GENERICMESSAGE::peer name "[IP::local_addr]:[TCP::local_port]_[IP::remote_addr]:[TCP::remote_port]" } when SERVER_CONNECTED { GENERICMESSAGE::peer name "[IP::local_addr]:[TCP::local_port]_[IP::remote_addr]:[TCP::remote_port]" } } This example is from a user case where a single syslog client was load balanced to multiple syslog server pool members. Messages are parsed with the newline (0x0a) character as configured in the generic protocol, but this can easily be adapted to other message types.
Reselecting route peer in MRF
Does anyone know how to get the router in MRF to reselect a new peer? I have MRF working for a custom protocol, and can either have it round robin the mesasges between peers, or always send messages to a particular peer (until it fails). However, what I'd like to get to is at some point be able to tell the router to reselect the peer to use. The only time I seem to be able to get it to do a reselect properly is when a peer is taken down and the MR_FAILED event is triggered wherein I call MR::message nexthop none MR::retry I suspect I need to delete the route entry that is currently configured, however doing anything with GENERICMESSAGE::route delete doesn't seem to make much difference (within MR_INGRESS) Wondering if anyone has done something similar with using MRF and can point me in the right direction?Creating a disconnect message to send through MRF
I'm working through a MRF setup and one of the cases I'm trying to implement is sending a disconnect message down to the pool members when a connection disconnects from the vhost. There are similar connect and data messages which are sent to pool members when a client connects or sends data to the vhost - this is working fine. When trying to send the message through MRF, during CLIENT_CLOSED, seems to drop the message with the following logged in ltm; Pending rule (null) aborted for 1.2.3.6:54127 -> 1.2.6.5:33200 The message is created in the CLIENT_CLOSED event as; GENERICMESSAGE::message create "DISCONNECTED:$my_host" my_dest As a workaround to it not finishing processing the irule for the message, I tried using a sideband connection and send in the message that way to a separate vhost (for different irule setup, linked to the same MRF router). This mostly works, except it has some strange side effects at the moment. Anyone know how to get a message to pass through from a CLIENT_CLOSED event? or have the sideband connection work without affecting other connections?
Load balancing SMPP authentication with MRF and no iRules. Can it be done?
Hi DevCentral, I will be honest, I do not completely understand how SMPP works, and the full requirements, but of all the configurations required this is the one that's throwing me for a loop. The scenario is as follows; When an external client initiates a connection to the VS, they are required to authenticate to two servers located in two differing subnets. The LTMs must traverse other gateways to reach these subnets. The requirements are to allow the connecting client to authenticate to both servers and any subsequent messages are load balanced to either of the servers, and if possible persist to only one based on the client/source. If the server fails, the pool will reselect and direct the connection to the available member. If the authenticated session fails, or the client closes the connection, they will re-authenticate to both servers and then load balancing can take place as before. I have looked at an iRule example by Dev member NAT, and trying to understand it at the moment. Some of it I get but the majority still escapes me, and I'm currently watching a TCL crash course to try and understand further. Referencing this post, from Dev user Sam, showing the SMPP message flow, which seems similar to Diameter, and from this I have been looking at MRF to possibly circumvent the iRules, limiting the complexity for future modifications. I have not begun configuring the SMPP services as yet, focusing on other configurations required prior to undertaking this one which seems mentally as a challenge. The HA pair LTMs are currently running version 12.0.0 1.0.0.628. My questions are; Is it possible to undertake this task without using iRules? and if so, any suggestions/tips for the configuration? Based on the message flow, is MRF viable for this solution? If iRules are required for the requirements, can the iRule example (from above) be used to satisfy this requirement? I would appreciate any assistance regarding the above, and also, feel free to ask for any information which can hopefully aid in a resolution. Best regards, T33