Manual Chapter :
Message Retry
Applies To:
Show Versions
BIG-IP LTM
- 17.1.0, 17.0.0, 16.1.4, 16.1.3, 16.1.2, 16.1.1, 16.1.0, 16.0.1, 16.0.0, 15.1.10, 15.1.9, 15.1.8, 15.1.7, 15.1.6, 15.1.5, 15.1.4, 15.1.3, 15.1.2, 15.1.1, 15.1.0, 15.0.1, 15.0.0, 14.1.5, 14.1.4, 14.1.3, 14.1.2, 14.1.0, 14.0.1, 14.0.0, 13.1.5, 13.1.4, 13.1.3, 13.1.1, 13.1.0
Message Retry
When a message fails to route, it will be returned to the originating connflow and MR_FAILED
event will be raised. A 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.
Steps of routing:
- If the message’s nexthop attribute is set, the message will be forwarded to the TMM and flowid specified in the nexthop. To avoid this, the message’s nexthop should be cleared via ‘MR::message nexthop none’.
- If the message’s route attribute is set, the message will skip persistence lookup and route selection and proceed to peer selection (step 5) and lb_pick. Every time route lookup occurs, the message’s route attribute is set. To ensure persistence lookup occurs the route attribute should be cleared via ‘MR::message route none’.
- 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). To remove any previous persistence record stored under the message’s key use ‘SIP::persist reset’ or ‘DIAMETER::persist reset’ iRule command. NOTE: The DIAMETER command is not yet implemented.
- The protocol specific route table implementation will lookup the best route for the message based on a protocol specific attributes contained in the message. For SIP, it uses the request-uri, to-uri and from-uri of the message. It is also able to match against the virtual server of the originator of the connection. Once a route is found, the message’s route attribute is populated with the route.
- The route found contains a peer list. A peer is selected from the peer list using the peer selection mode.
- 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.
- 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
