Forum Discussion

UniFirst1_22521's avatar
UniFirst1_22521
Icon for Nimbostratus rankNimbostratus
Feb 10, 2016

iRule to Log TCP Connections

I have a virtual Server (vs) connection that the application folks say is timing out after 10 minutes. Here is the high level flow. The host connects to the vs. The host then sends a "job request" to one of the pool members. The pool members spawns a "job" that is executed. Once the "executed job" completes, the pool member then sends a notification back to the host telling it the job finished successfully or unsuccessfully. If no response is sent back in 10 minutes the connection between the host and vs is terminating. The application folks say the application has no timeout values and will wait "forever" for a response so the issues has to be the vs terminating the session.

 

One thing that is hampering a resolution of this problem is that it is intermittent. It happens only if the "spawned" job takes longer than 10 minutes to run. Because of the nature of the job it cannot be run in a "test environment" so we could actually capture packets. There is also no way to determine how long the job will run at any given time.

 

I created an iRule that changes the "timeout vales" for these connections and logs them each time they change. As you can see the values are changing. Feb 9 05:20:27 f5net01 info tmm1[25216]: Rule /Common/SOA_Extend_Idle_Timer_Test : updated timeout: 1802 Feb 9 05:20:27 f5net01 info tmm1[25216]: Rule /Common/SOA_Extend_Idle_Timer_Test : original timeout: 600 Feb 9 05:20:27 f5net01 info tmm1[25216]: Rule /Common/SOA_Extend_Idle_Timer_Test : updated timeout: 10800 Feb 9 05:20:27 f5net01 info tmm1[25216]: Rule /Common/SOA_Extend_Idle_Timer_Test : original timeout: 600 Feb 9 05:15:09 f5net01 info tmm[25216]: Rule /Common/SOA_Extend_Idle_Timer_Test : updated timeout: 1802 Feb 9 05:15:09 f5net01 info tmm[25216]: Rule /Common/SOA_Extend_Idle_Timer_Test : original timeout: 600 Feb 9 05:15:09 f5net01 info tmm[25216]: Rule /Common/SOA_Extend_Idle_Timer_Test : updated timeout: 10800 Feb 9 05:15:09 f5net01 info tmm[25216]: Rule /Common/SOA_Extend_Idle_Timer_Test : original timeout: 600 Feb 9 05:15:09 f5net01 info tmm1[25216]: Rule /Common/SOA_Extend_Idle_Timer_Test : updated timeout: 1802 Feb 9 05:15:09 f5net01 info tmm1[25216]: Rule /Common/SOA_Extend_Idle_Timer_Test : original timeout: 600 Feb 9 05:15:09 f5net01 info tmm1[25216]: Rule /Common/SOA_Extend_Idle_Timer_Test : updated timeout: 10800 Feb 9 05:15:09 f5net01 info tmm1[25216]: Rule /Common/SOA_Extend_Idle_Timer_Test : original timeout: 600

 

Here is the current iRule. when HTTP_REQUEST { if { (( [IP::addr [IP::client_addr] equals 172.17.101.60] ) or ( [IP::addr [IP::client_addr] equals 172.17.101.149] )) and ( [HTTP::host] equals "soaprod.corp.unifirst.com" ) } then { log local0. "original timeout: [IP::idle_timeout]" IP::idle_timeout 10800 log local0. "updated timeout: [IP::idle_timeout]" set serverside_idle_timeout 1 } } when SERVER_CONNECTED { log local0. "original timeout: [IP::idle_timeout]" if { [info exists serverside_idle_timeout] } then { IP::idle_timeout 1802 log local0. "updated timeout: [IP::idle_timeout]" unset -nocomplain serverside_idle_timeout } }

 

I am thinking that if I could use an iRule to "capture" packets that meet the same criteria I could then see for sure why the connection is dropping and if the application or F5 is resetting it. Is that possible in an iRule? What are some other things (other than capturing packets) I could do to determine exactly why this connection is dropping after 10 minutes of "no activity"?

 

1 Reply

  • Hi UniFirst,

     

    unfortunately an iRule can't be used to see which side has terminated/closed the connection. iRules don't let you access raw TCP information such as RST or FIN flags... :-(

     

    So you have to use a network monitor to see the origin of your connection problem. If intermediate devices (e.g. certain firewalls with low connection timeouts / keep alives) are in place, then it could be required to capture on both sides of the connection...

     

    Cheers, Kai