Forum Discussion

newf5learner's avatar
newf5learner
Icon for Nimbostratus rankNimbostratus
Aug 27, 2016

Virtual server - connection behavior changes based on the modifications

Hi,

I was going through this document https://support.f5.com/kb/en-us/solutions/public/13000/200/sol13253.html and trying to understand the connection status pertaining to each change we see for the respective modification on a VIP.

I have created a VIP 10.20.20.1 listening on port 80, source address as 0.0.0.0/0 with default http profile, a pool of two servers.

Test 1 : Change the source from 0.0.0.0/0 to specific IP 10.30.30.1/32 I got mixed results.. assumed that my existing sessions from 10.40.40.1 will not get affected, but then I saw that browser showing, page cannot be found. I tried the same 2nd, then connection remained unaffected. Can someone tell me whats the normal behaviour of the VIP in this scenario?

Test 2 : Added the persistence profile with timeout 180, decreased the persistence(src addr) timeout to 90sec New connections with 90sec timeout was reflecting for new connections and old connections with 180 secs remained until timeout for same source Ip 10.40.40.1 - Hope this is a usual behavior?

Test 3: There were existing connections, Added a irule. On the existing connection, I tried to access a file location, it took me to html page. Is this a usual behaviour on a existing connection? Yes it is as for as my understanding is..!

 

 when HTTP_REQUEST {
if { [HTTP::uri] starts_with "/" } {
HTTP::respond 200 content {


404


The SW Page is available on https..click here https://10.20.20.243

}
} else {
pool test_sw
}
}

 

Please let me know the standard behaviours of these changes as I'm still confused with the results I see for each test. May be I might be testing these on a wrong browser.! thanks.

application delivery
LTM
TMSH

2 Replies

Sort By
  • Vijay_E's avatar
    Vijay_E
    Icon for Cirrus rankCirrus
    Aug 27, 2016

    I am assuming that you are clearing up any persistence records and connections on the browser, waiting for a short period of time before initiating any new test.

     

    A browser opens up multiple connections as seen here.

     

    Although you believe it is an existing connection, the browser has its own behavior that is "optimized" to deliver objects based on performance variables like latency. In other words, I think the browser based test may not be a reasonable reflection of what you want to test. May be try other cli based options where you have greater control ?

     

  • Kai_Wilke's avatar
    Kai_Wilke
    Icon for MVP rankMVP
    Aug 28, 2016

    Hi Newf5learner,

    as Odaah has already pointed out, the problems you're facing will be most likely commming from an unappropiate test environment (aka. unpredictable Keep-Alives from your browser)...

    When I develop/troubleshoot iRules I'll alway use a HTTP debugging Forward Proxy (e.g. Fiddler, HTTPWatch) with settings to "Disable Keep Alive" for the connection between my client and the virtual server to get sure that any of my changes are getting active on the very next request.

    If you can't use such debugging tools, then I would recommend to insert a Connection: Close HTTP header within the HTTP_RESPONSE or HTTP_RESPONSE_RELEASE events. This will also stop Keep-Alive sessions...

     

    when HTTP_RESPONSE_RELEASE {
    HTTP::header replace "Connection" "Close"
}

     

    And if you're interested to even bypass the behavior of SOL13253 you could use a special crafted syntax to become able to apply iRule changed on active connections.

     

    when RULE_INIT {

    set static::dynamic_code {

        
         Changes to this code will have an instant effect on existing connections..
        

        log local0.debug "Try to change me!"

    }

}
when HTTP_REQUEST {

    if { $something } then {

        
         Changes to this code will affect only new connections as discribed in SOL13253.
        

        log local0.debug "Try to change me!"

    }

     The command below calls TCL code out of a global variable.
    eval $static::dynamic_code
     The command below calls TCL code out of a TCL procedure.
    eval [call dynamic_code]

}

proc dynamic_code {
    return {

        
         Changes to this code will have an instant effect on existing connections..
        

        log local0.debug "Try to change me!"

    }

}

     

    Note: A VE of LTM is as trustworthy as using a LTM applicance. 🙂

    Cheers, Kai