Forum Discussion

mahnsc's avatar
mahnsc
Icon for Nimbostratus rankNimbostratus
Oct 29, 2009

HTTP URI-based traffic router intermittently failing

I've got a strange problem that I've been stuggling with for the past two days and was hoping someone has experienced it in the past or could suggest a potential area for me to focus on.

 

 

I have a pool of web servers dedicated to web service traffic. I have an irule that looks like the following:

 

 

when HTTP_REQUEST {

 

set ws_pool my_webservice_pool

 

switch -glob [HTTP::uri] {

 

"/web/service/*" {

 

pool $ws_pool

 

}

 

default {

 

HTTP::redirect https://content.website.com/

 

}

 

}

 

}

 

 

(Notes: my_webservice_pool is the sanitized name of my actual pool. switch -glob is being used because there are 8 different web service URI's I'm matching on, all getting routed to the same pool but I wanted to keep this post as short as possible)

 

 

Basically, the way this works is if the web service URI is found, send the request to the web service pool. If not, redirect to the content site.

 

 

The rule seems to work fine. However, intermittently (maybe only 10% to 20% of the time and time of day does not matter), instead of the traffic getting sent to the web service pool, the BigIP issues a connection reset instead. tcpdumps do not show a response from the web server. No error. Just a connection reset.

 

 

During the course of my debugging, I've removed all other irules from the SSL VIP for this site thinking that maybe another rule that rejected connections if a certain URI or HTTP Method was requested was stepping on this rule but it didn't make a difference.

 

 

Can anyone suggest any additional logging parameters I can add to the rule so I can try to figure out why this may be happening?

 

 

The one customer I've been working with has only sent about 10 requests over the course of a three hour period and only 1 of these requests failed in that timeframe. If they resubmit the failed request, it succeeds, so there isn't anything noticeably wrong with the web service request. The web site is fairly high volume supporting about 50,000 daily visitors.
  • I don't believe your irule has anything to do with the resets. Considering you have 50K per day vistors, my suggestion is opening a case with F5 and letting them check out the entire unit because connection resets could be attributed to either hardware or software.

     

     

    I hope this helps

     

    CB

     

  • mahnsc's avatar
    mahnsc
    Icon for Nimbostratus rankNimbostratus
    You're right. Some basic logging shows the F5 sending the packet off to the apache servers. So, it's either an apache issue or an app server issue. Thanks for responding!
  • mahnsc's avatar
    mahnsc
    Icon for Nimbostratus rankNimbostratus
    Wanted to update the forum that this turned out to be a oneconnect-related issue. I inserted a ONECONNECT::resuse disable before the pool statement in the rule and everything started working for these web service calls.