iRule to Hunt on SIP 503 Response

While we could probably do something with an iRule, why not just create a SIP health monitor that considers the pool member down if it returns a 503 and set your Pool's "Action on Service Down" to reselect? Or were you looking for something else?

 

 

I can see some options from SIP::response to look for the code but am not entirely sure how to trigger LB::reselect from there...

Apparently, the SIP monitor keepalive uses the OPTIONS method, which doesn't always return a 503 in the same cases where a call from an external caller would. If that could be customized we would be in business.

How about an Inband monitor?

I think an inband monitor will only detect connection failures (or with an HTTP profile no response failures):

 

 

 

Manual Chapter: Health and Performance Monitors

 

 

http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm_configuration_guide_10_1/ltm_appendixa_monitor_types.html?sr=138265381192393

 

 

With an Inband type of monitor, the BIG-IP system performs passive monitoring as part of client requests. Replacing the need to write an iRule to perform passive monitoring, an Inband monitor works with either a Standard or a Performance (Layer 4) type of virtual server.

 

When you configure an Inband type of monitor, the monitor, when acting as a client, attempts to connect to a pool member and behaves as follows:

 

 

If the pool member does not respond to a connection request after a user-specified number of tries within a user-specified time period, the monitor marks the pool member as down.

 

 

After the monitor has marked the pool member as down, and after a user-specified amount of time has passed, the monitor tries again to connect to the pool member (if so configured).

 

 

...

 

 

Standard with no HTTP profile

 

 

If you configure an Inband monitor and associate it with a Standard type of virtual server that does not reference an HTTP type of profile, a passive failure occurs when a connection is established with the pool member, or the pool member is responding to requests (or both), and the maximum retransmit times specified in the TCP profile are exceeded.

 

 

After a pool member has been marked down by the Inband monitor for the number of seconds specified in the Retry Time setting (if the value is non-zero), the pool member becomes eligible to receive a request. If the client is able to successfully establish a connection with the pool member, the pool member is marked up when the connection is completed.

 

 

 

How about using Chris' idea of checking the response status in SIP_RESPONSE, calling LB::down and then having the pool action on service down set to reselect?

 

 

Else, you could try using a external monitor to send the exact SIP request you'd need to to trigger a failure like the client would receive. This wouldn't reselect on a client request getting a 503, but would take the pool member out of load balancing if the member was giving 503's for all clients.

 

 

Here's a template you could try for an external monitor:

 

http://devcentral.f5.com/wiki/default.aspx/AdvDesignConfig/TemplateForExternalLtmMonitors.html

 

 

Aaron

I'm just starting to work on a project to accomplish this same thing.

 

In our scenario, the 403 or 404 error doesn't mean that the server is down, it just means that the server does not own that session.

 

 

Imagine I have 10 sip servers behind a vip. I start a session and set up a chat session with chat id 1234. Our software assigns that chat session to server 4. BIG-IP didn't see this request, it was done on that backend.

 

 

I tell someone to come chat with me at the vip IP and chat id 1234.

 

The BIG-IP then sends this request for chat session 1234 to server 1, server 1 doesn't have it so it responds with 404.

 

I need to get the BIG-IP to see the 404, then send the sip request to server 2, then 3, etc.. on down the line until it gets a valid response and pass that response on to the client.

 

 

Essentially, SIP::retry.

 

This earlier message had the same problem with no resolution:

 

http://devcentral.f5.com/Community/GroupDetails/tabid/1082223/asg/50/aft/1171557/showtab/groupforums/Default.aspx

 

SIP::retry sounds like a good RFE :)

 

 

There was another post recently requesting similar functionality:

 

http://devcentral.f5.com/Community/GroupDetails/tabid/1082223/aff/5/afv/topic/aft/1179282/afc/1251370/Default.aspx

 

 

Maybe you guys could open a case with Support on this.

 

 

Aaron