Manual Chapter : Request Routing Debugging

Applies To:

Show Versions 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
Manual Chapter

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]" } }