Manual Chapter :
Request Routing Debugging
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
Request Routing Debugging
iRules can be used for route debugging. Remember that the iRule needs to be on each transport
in the system (virtual servers and transport-configs). MR_INGRESS event runs on the connection
that received the request message. MR_EGRESS event runs on the connection that the message is
being sent out. MR_FAILED event runs on the connection that received the request message when a
message failed to be routed.
SIP iRule commands can be run in the MR iRule events. MRF communicates with the SIP parser to
instruct it as to which message is currently used during the MR event.
To know if a message is a request or a response, the following conditional can be used:
If {[SIP::response code] eq “”} { # this is a request message
During MR_INGRESS, the message’s route can be examined as follows:
Log local0. “route [MR::message route]”
The transport type and name can be inspected (in v12.0 and later) via an iRule command as
follows:
Log local0. “transport [MR::transport]”
An example script for MR_INGRESS is as follows:
when MR_INGRESS { log local0. “transport: [MR::transport] flow_id: [MR::flow_id]” if {[SIP::reponse code] eq “”} { log local0. “request [SIP::method] persist key [SIP::persist] route [MR::message route]” } else { log local0. “response [SIP::response code] nexthop [MR::message nexthop] route [MR::message route]" } }
After routing has occurred, the messages route field will be populated with the value of the
selected route and either MR_EGRESS will be executed or MR_FAILED. If routing succeeded, the
route status will be set to “route found” and MR_EGRESS event will be raised on the outgoing
connection. If routing failed, the route status will be set and MR_FAILED event will be raised on
the incoming connection.
when MR_EGRESS { log local0. “transport: [MR::transport] flow_id: [MR::flow_id]” if {[SIP::reponse code] eq “”} { log local0. “request [SIP::method] persist key [SIP::persist] route [MR::message route]” } else { log local0. “response [SIP::response code] nexthop [MR::message nexthop] route [MR::message route]" } } when MR_FAILED { log local0. “transport: [MR::transport] flow_id: [MR::flow_id] route status [MR::message status]” if {[SIP::reponse code] eq “”} { log local0. “request [SIP::method] persist key [SIP::persist] route [MR::message route]” } else { log local0. “response [SIP::response code] nexthop [MR::message nexthop] route [MR::message route]" } }
