The MR namespace contains iRule commands that work with the message routing framework (MRF).
MRF routes messages between two endpoints via a message routing proxy (MR proxy) associated with each endpoint. Certain application layer protocols use the MRF to route protocol-specific messages. A received message is said to “ingress” from one protocol-specific endpoint to the MR proxy. A sent message is said to “egress” from the MR proxy to the protocol-specific endpoint.
MR iRule commands operate within a Tcl context associated with the connection flow between the endpoint and the MR proxy. The ingress and egress parts of a message’s journey therefore operate in separate Tcl contexts. The Tcl context contains the Tcl variables and execution state of the currently executing iRule event. Only one iRule event can execute at a time on a connection flow, therefore messages queue to execute their iRule events.
In many MR protocols, messages belong to independent transactions that are carried over the same network connection flow. It is highly desirable for messages sharing a connection flow to execute their iRules independently of other messages. This provides the following advantages and behavior changes:
- A message does not need to wait for an unrelated message to complete an event in order to execute its own event.
- Messages sharing a connection flow may exit the flow in a different order than they entered.
- Tcl variables cannot be overwritten between events by another message.
This capability may be enabled in the protocol-specific router profile via the irule-scope-message attribute, only for protocols that currently support it. For genericmessage, it may be enabled in the MR router profile. Before enabling irule-scope-message for a protocol, the user’s iRules should be examined and if necessary adjusted and tested, to ensure they do not rely on sharing a Tcl context between messages on a connection flow.
- MR::available_for_routing - gets/sets the available_for_routing mode for the current connection.
- MR::collect - collect the specified amount of MR message payload data.
- MR::connect_back_port - gets or sets connect_back_port for the current connection
- MR::connection_instance - returns the connection instance and the number of connections
- MR::connection_mode - returns the connection mode of the current connection
- MR::equivalent_transport - gets or sets the transport that is usable as an equivalent transport
- MR::flow_id - returns a unique identifier for the current connection
- MR::ignore_peer_port - sets or resets the ignore_peer_port mode of the current connection
- MR::instance - returns the name of the current mr_router instance
- MR::max_retries - returns the number of retries allows for this router instance
- MR::message - returns or sets details in the message routing table
- MR::payload - returns the data collected using the MR::collect command
- MR::peer - defines a peer to use for routing a message to
- MR::prime - establishes an outgoing connection to the specified host or hosts using the specified transport
- MR::protocol - returns ‘generic, ‘sip’ or ‘diameter’
- MR::release - releases the data collected via MR::collect iRule command.
- MR::restore - returns the stored variables to the current context tcl variable store
- MR::retry - sends the current message to the router for routing
- MR::return - returns the current message to the originating connection
- MR::store - stores a tcl variable with the mr_message object
- MR::stream - start egressing bytes previously collected and stored
- MR::transport - returns the name and type (virtual or config) of the transport used to configure the current connection
- MR_EGRESS - raised after the route has been selected and processed and the message is delivered to the mr_proxy
- MR_INGRESS - raised when a message is received by the message proxy and before a route lookup occurs
- MR_FAILED - raised when a message has been returned to the originating flow due to a routing failure
The BIG-IP API Reference documentation contains community-contributed content. F5 does not monitor or control community code contributions. We make no guarantees or warranties regarding the available code, and it may contain errors, defects, bugs, inaccuracies, or security vulnerabilities. Your access to and use of any code available in the BIG-IP API reference guides is solely at your own risk.