Forum Discussion

Ganesh_Ramamoor's avatar
Ganesh_Ramamoor
Icon for Nimbostratus rankNimbostratus
May 02, 2006

Packets not sent to server

I have a very simple iRule:

 

when HTTP_REQUEST {

 

if { [HTTP::uri] contains "X1" } {

 

pool x1

 

}

 

elseif { [HTTP::uri] contains "x2" } {

 

pool x2

 

}

 

elseif { [HTTP::uri] contains "x3" } {

 

pool x3

 

}

 

elseif { [HTTP::uri] contains "x4" } {

 

pool x4

 

}

 

}

 

This was working fine for a long time, but suddenly today it stopped working for just one client. It was working for this client for a while before it stopped working. tcpdump showed the packet (HTTP GET) reaches the appswitch but the packet never got sent out to the server. The TCP connection was always there to the client and to the server and when I finally stopped the server, the appswitch sent a FIN to the client.

 

 

Not sure if this problem is iRule related, but I just wanted know if under any circumstances the iRule won't be applied ...

 

 

Thanks in advance.

 

4 Replies

  •  

    Ok, turns out that if the server doesn't respond for a HTTP GET message, then the F5 doesn't send the subsequent GET messages. In general, unless a response for a GET is received from the server, the next GET from the client on the same TCP connection is queued up. I don't use a one-connect profile but use an HTTP profile. This seems to be the behavior whether the 'pipelining' option in the HTTP profile is enabled or not. BTW, if I have a TCP-rule without an HTTP profile, the GET messages are sent right away even if the server doesn't respond to the first GET.

     

    So, if I want to use HTTP profile can I force the appswitch to send the GET messages on the same TCP connection without them getting queued up using the iRule?

     

     

    Thanks
  •  

    Does anyone have any inputs on this?

     

     

    Any help on this would be appreciated.

     

     

    Thanks

     

  • I seem to have a similar issue where we use the HTTP::uri starts_with rather than contains. My problem is once packet gets load balanced to one set of pool it seems to get "stuck" there and irule will not process any future requests. So subsequent requests kept on going to the stuck pool rather than being evaluated by irule again. I suspect something with keepalive on the webserver since if I disable keepalive it seems to process through irule again. I'd suggest checking your keepalive setting and see if its enabled. I have a ticket open w/F5 to see if they can shine some light on this issue.
  • I would suggest capturing tcpdump traces of a failure and a success and then opening a case with support as this doesn't seem to be a clear iRule issue.

     

     

    Aaron