iRule Context

Because we are doing "delay binding" (storing packets to analyze the Request, before choosing the destination node to LoadBalance to), the server may not be selected when you try to log the server IP.

 

 

If you want your iRule to work, it is better to do that in a different way.

 

 

HTTP_REQUEST will fire for each request.

 

IP::server_addr will exist only when the server TCP connection is established.

 

 

Use the event:

 

SERVER_CONNECTED, to store a local variable for the TCP connection.

 

 

when SERVER_CONNECTED{

 

set SRV_ADDR [IP::server_addr]

 

}

 

 

in the HTTP_REQUEST event, look if the local variable for the TCP connection bound to the HTTP request is popuplated.

 

 

when HTTP_REQUEST{

 

if {[info exists SRV_ADDR]}

 

{

 

log local0. " Been Here URI = [HTTP::uri] [IP::client_addr] $SRV_ADDR"

 

}

 

else

 

{

 

log local0. " Been Here URI = [HTTP::uri] [IP::client_addr] - First Request int this TCP connection - Server not yet selected"

 

}

 

}

 

 

Regards

 

 

/Phil

Phil's right about the delayed binding. If you add an HTTP profile to the virtual server, the BIG-IP will parse the HTTP headers before establishing a server side connection. I don't think the server side context will ever be established in the HTTP_REQUEST event, so there probably isn't much use in checking to see if the server address exists in HTTP_REQUEST. For some details on event context, you can check this post (Click here).

Were you logging the virtual server IP in HTTP_REQUEST? That would always be available in the client side context using IP::local_addr.

If you want to log which server the connection was made with, you can just log the details in the SERVER_CONNECTED event. You'll need to save the HTTP::uri in the HTTP_REQUEST event as it's not available anymore in the SERVER_CONNECTED event. Here's an example based off of this codeshare entry (Click here:

  
  when HTTP_REQUEST {  
     set http_request_time [clock clicks -milliseconds]  
     set request_line "   
        [IP::remote_addr],\  
        [HTTP::method],\  
        [HTTP::version],\  
        [HTTP::host],\  
        \"[HTTP::uri]\",\  
        \"[HTTP::header value Referer]\",  
        \"[HTTP::header User-Agent]\",\  
     ]  
  }  
  when HTTP_RESPONSE {  
    set http_response_time [ clock clicks -milliseconds ]  
    log local0. "$request_log_line,\  
        [HTTP::status],\  
        [HTTP::payload length],\  
        [expr $http_response_time - $http_request_time]"  
  }  
  

Aaron

Hi aaron,

 

i don't think that was the request from iupton ;-)

 

 

Using "clock" command in different events can cause a lot of CPU usage ;-)

I appreciate both responses, as this gives the original poster, iupton, options to solve his problem and additional knowledge base for future projects.

 

 

The clock command pre-9.2 had performance issues, but I haven't seen/heard any issues with its use even in very busy environments since. Anyone else?

I'll have to go check, but I'm pretty sure they made some drastic improvements to that, semi-recently.

 

 

Colin