Manual Chapter : FAQ

Applies To:

Show Versions Show Versions


  • 15.0.1, 15.0.0, 14.1.3, 14.1.2, 14.1.0, 14.0.1, 14.0.0, 13.1.3, 13.1.1, 13.1.0
Manual Chapter



Generic Message requires an LTM license.

Transport Translation

Transport translation is not supported. In other words, a UDP client connection cannot be sent to a TCP peer and vice versa.

Message Retry

When a message fails to route, it will be returned to the originating connflow and MR_FAILED event will be raised. An iRule script will be able to examine the message and resubmit it for routing via the MR::retry command.

There are multiple steps to routing, to understand how MR::retry will work, you will need to understand the steps. To avoid some of these steps or force a different path you may need to modify some of the metadata contained with the message.

Routing steps:
  1. If persistence is enabled on the originating transport, the generated persistence key (via config or iRule) will be used to look for a persistence record. If a persistence record is found, the message will be forwarded to the host specified in the persistence record (step 7).
  2. The protocol specific route table implementation will lookup the best route for the message based on a protocol specific attributes contained in the message.
  3. The route found contains a peer list. A peer is selected from the peer list using the peer selection mode.
  4. The selected peer may contain a pool and a transport. If a pool exists, it will select the first active pool member that has not already be attempted for this message. If no pool exists, it will forward the message to the local IP and port of the incoming connection.
  5. Once a host has been selected, MRF will look to see if an available connection already exists to the host. If an available connection exists, the message will be egressed to the host via that connection. If an available connection does not exist, a new connection will be created and the message will be forwarded through the new connection

Connection Auto-Initialization

If a peer object has auto-initialization enabled, the BIG-IP® system will automatically create outbound connections to the active pool members in the specified pool using the configuration of the specified transport-config. For auto-initialization to attempt to create a connection, the peer must be included in a route that is attached to a router instance. For each router instance that the peer is contained in, a connection will be initiated. The auto-initialization logic will verify at a configurable interval if the a connection exists between the BIG-IP and the pool members of the pool. If a connection does not exist, it will attempt to reestablish one.

The first auto-intialization attempt will occur at least one auto-initialization-interval delay from when the object is loaded or changed in the TMM.

If the router instance is not included in any virtual servers, connection auto-initialization will not start. Once the router instance has been included in an enabled virtual server, auto-initialization will begin and will remain running for those peers used by routes attached to the router instance even if the router instance is removed from the virtual server.

If a peer with auto-initialization enabled, is used in multiple router instances, a separate connection will be established for each router instance.

The auto-initialization logic will only attempt to create connections to enabled pool members. If the pool member is marked down by an external monitor it will be ignored unless an inband monitor is also attached.

If mirroring is enabled on the router instance, the active device will initialize outgoing connections. The new outgoing connections will be mirrored to the standby device.

iRules on all transports

With MRF the outgoing connection may not use the same transport as the incoming connection. Incoming connections are defined via virtual servers. Outgoing connections are often defined with transport-configs. If the same iRule script is desired to run on all connections, the script should be defined for all transports.

For example tests assume a simple load balancing configuration with a virtual server (VS_IN) that is part of a router instance with a single default route. This default route contains a single peer that uses a transport-config (TC_OUT) to define the parameters of the outgoing connection. In this setup, a request message would be received on VS_IN. The request message would ingress on a hudchain configured via the settings of the virtual server. As the message was processed, the SIP_REQUEST and MR_INGRESS events would be raised on the iRule scripts attached to the virtual server. The request message would be forwarded to an outgoing connection configured via the setting of the transport-config. As the message egressed through the outgoing connection, the MR_EGRESS and SIP_REQUEST_SEND events would be raised on the iRule scripts attached to the transport-config. When the response message is received by the outgoing connection, the SIP_RESPONSE and MR_INGRESS events would be raised on the iRule script attached to the transport-config. The response will be forwarded to the connection that originated the request and the MR_EGRESS and SIP_RESPONSE_SEND events would be raised on the iRule script attached to the virtual server.

iRules on all transports

iRules on all transports

Sharing iRule variables between connections

MRF does not join the client side connection with the server side connection (except for SIP ALG). The traditional method of using the CLIENTSIDE or SERVERSIDE keywords to access variables will not work. Instead MRF provides a command to deliver tcl variables along side of the message to the outgoing connection. The MR::store command allows the script author to specify which tcl variables should be delivered to the outgoing connection. The MR::restore command unpacks the delivered variables on the outgoing connection and adds them to the connections context.

For example on the incoming connection:

  set originator_ip [IP::remote_add]
  set ingress_message_count [expr $message_count + 1]
  MR::store originator_ip ingress_message_count

On the outgoing connection:

when MR_EGRESS {
  log local0. "originator_ip $originator_ip ingress_message_count $ingress_message_count"

The effect of message pipelining on iRule variables

SIP can pipeline messages by allowing messages that require less processing to be forwarded without waiting for earlier messages that require more processing. For this reason, it is not recommended to store state in tcl variables to be used by subsequent iRule events. There is no guarantee that the next event raised after the protocol's message event will be the MR_INGRESS for the same message. For example, saving the SIP uri in a tcl variable during a SIP_REQUEST event to use for making a routing decision during MR_INGRESS is not recommended. The next MR_INGRESS event may not be for the same message as the last SIP_REQUEST event.

MRF SIP implementation allows accessing the SIP iRule commands during the MR events. This is the recommended method to make routing and delivery decisions based on attributes of a message.

For example:

  if {[URI::host [SIP::uri]] equal ""} {
    MR::message route config "/Common/othersp_tc" pool "/Common/othersp_pool"

SNAT settings of the outgoing transport used

MRF uses the SNAT setting of the outgoing connection to determine how the source address is translated. Most outgoing connections are configured via a transport-config and the SNAT setting of the transport config will be used to select the source address. The only time the SNAT settings defined in the virtual server are used is if the setting of the virtual is used to create the outgoing connection (this occurs if no transport-config is set in the peer object).

Connection Reuse

MRF maintains a table of all existing connections on each TMM of a router instance. When a message is routed to a host, MRF will scan this table for an existing connection to the host that is available for use. If an available existing connection is not found, a new connection will be created.

There are many reasons that an existing connection may not be available for delivery of the current message (see the sub-sections below for details).


Each connection is created using the parameters of a transport object (either a virtual server or a transport-config). The transport specifies the profiles, SNAT and iRule scripts of the connection. When a message is routed, MRF will scan the list of connections for a connection created with the same transport specified. Even if the two transports contain the same parameters, a connection created with a different transport will not be used.

A pool object only allows specification of a transport-config as the outgoing connection transport. If the peer object does not specify the transport config, the transport of the message's originating connection will be used. If the system wishes to potentially deliver a message through an existing connection created with by different virtual server on the same router, the MR::message route iRule command must be used. For example:

MR::message route virtual "/Common/internal_vs" host [IP::local_addr]:5060

Remote Port and ignore-clientside-port (or ignore-peer-port)

Many clients when creating connections use an ephemeral port for the local port. If a message is routed to that host, the port specified in the host's address will be different than the remote port of any existing connection with the host. Many MRF protocol implementation have an 'ignore_clientside_port' attribute in their router profile. Setting attribute to 'true' instructs MRF that any connection created by the host (client side) that matches the transport, remote IP and rtdom_id may be used.

Number-connections and instance number

The number-connections attribute of the peer object specifies which connection of a set of connections to a host will be used for delivering a message. It is used alongside the connection-mode instance to set the maximum number of connections between a router instance not the BIG-IP® system and a host.


Many MRF protocol router profiles contain a 'use-local-connection' attribute. If this attribute is set, if a outgoing connection exists on the current TMM, it will be used even if the instance number does not match. Using this optimization will effectively limit the number of outgoing connections to one per TMM.

Source port

MRF allows setting the source port used on outgoing connections through the source-port attribute of a transport-config object. Setting this attribute to a non-zero value causes the source port of the outgoing connection to be set to the provided value. If set to zero an ephemeral port value will be used.

Pinning the source port to a fixed value will limit the number of connections available to the host. There can only be one connection using the local and remote tuples (IP/port/rtdom_id) and IP protocol (TCP/UDP/SCTP). Attempts to create another connection using the same addresses and IP protocol will fail.

For this reason it is not recommended to use set the source port for outgoing connections except when using a connection-mode of 'per-peer' and a number-connections of '1'.

Likewise trying to use the same host from peers with different transport settings (transport-config and/or virtual) and setting the source port will produce failures (unless different SNAT pools are used).