For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

Randy_Johnson_1's avatar
Randy_Johnson_1
Icon for Nimbostratus rankNimbostratus
Mar 18, 2010

Simple iRule, confusing output ...

I'm using a fairly simple iRule to prove that my BigIP is not addiing excessive latency to a transactiona gainst our WebServices.

 

 

The rule looks like this:

 

 

when HTTP_REQUEST {

 

set http_request_time [clock clicks -milliseconds]

 

set request_log_line "\

 

[HTTP::request_num],\

 

[IP::remote_addr],\

 

[HTTP::method],\

 

[HTTP::uri]\,

 

[HTTP::host],\

 

[LB::server]\

 

"

 

}

 

when HTTP_RESPONSE {

 

set http_response_time [ clock clicks -milliseconds ]

 

log local0.info "$request_log_line,\

 

[HTTP::status],\

 

[expr $http_response_time - $http_request_time]"

 

}

 

 

While (for the most part...) ther logged output makes sense

 

 

Mar 18 11:40:15 tmm tmm[1586]: Rule RJTime_Test : 63, IP::remote_addr removed, POST, /ourapp.asmx, oursvchost.ourdomain.net, Service 10.1.1.114 80 , 200, 47

 

 

I also get lines like this...

 

 

Mar 18 11:40:15 tmm tmm[1586]: Rule RJTime_Test : 1, IP::remote_addr removed, POST, /ourapp.asmx, oursvchost.ourdomain.net, Service 0 , 200, 7

 

 

What I'm confused on is why the 'LB::server' field is showing up as '0' in some of my logs, yet shows up correctly in most of them ?

 

Could this be an indication of a request that was not load balanced at all, and just went to Limbo ?

 

 

Thanks !!

 

 

 

application delivery
dev
devops
iRules

3 Replies

  • Ian_Smith's avatar
    Ian_Smith
    Ret. Employee
    Mar 20, 2010
    If you look back through your logs, does the LB::server always equal zero when HTTP::request_num equals one?

     

     

    If so, that simply indicates that the LB decision hasn't been made yet, so the zero is a placeholder and it doesn't mean that the request is lost; it is present on all the subsequent requests because the TCP connection hasn't been shut down, so that client is connected to the pool member listed in LB::server and no LB decision is being made.

     

     

    To get the LB::server on the first pass, you would have to request it in the LB_SELECTED event

     

  • hoolio's avatar
    hoolio
    Icon for Cirrostratus rankCirrostratus
    Mar 22, 2010
    If you're trying to get the server IP:port with the existing events, add IP::server_addr and TCP::server_port in HTTP_RESPONSE: 

     
 ... 
 when HTTP_RESPONSE { 
    log local0.info "$request_log_line,\ 
       [IP::server_addr],\ 
       [TCP::server_port,\ 
       [HTTP::status],\ 
       [expr { [ clock clicks -milliseconds ] - $http_request_time}]" 
 }

    You can also remove the intermediate variable for response time and wrap the expr operands in curly braces to save some CPU cycles.

    Aaron