Forum Discussion

Ross_Merkle_791's avatar
Ross_Merkle_791
Icon for Nimbostratus rankNimbostratus
Apr 27, 2012

Irule working on current connection.

When my company rolls out new code on webservers we want the ability to make sure everyone from the Internet is redirected to a maintenance site. During the maintenance period I want to our QA staff from both of our offices to be able to reach the site for testing.

 

when HTTP_REQUEST {

 

if {not ( [IP::addr "[IP::client_addr]/8" equals "10.0.0.0/8"]or[IP::addr "[IP::client_addr]/12" equals "172.16.0.0/12"]or[IP::addr "[IP::client_addr]/16" equals "192.168.0.0/16"]or[IP::addr "[IP::client_addr]/25" equals ".../25"]or[IP::addr "[IP::client_addr]/28" equals ".../28"]or[IP::addr "[IP::client_addr]/26" equals "..."] ) } {

 

HTTP::redirect "http://www.***.com/Maint_Pages/Maintenance.html"

 

}

 

}

 

The rule basically say’s that unless you are coming from an internal IP address or a public IP address from my company, you are sent to a maintenance page.

 

This used to work great until we started using services from Akamai. Akamai use connection sharing so they create a connection to our LTM and use that connection to service multiple requests. The net result is they may keep an active connection to the LTM for a long time. When I use the Irule to put the VIP into maintenance mode, anybody using Akamai does not see the Irule because Irules don’t work against current connections. I need ALL customers redirected.

 

I have played with idea of adding the following to the beginning of the Irule.

 

when RULE_INIT { LB::detach }

 

My concern after do some reading on the Internet is it sounds like RULE_INIT can be a scary command if used wrong. Also while I think this should work when I add the Irule to the VIP, I figure it won’t drop connections when I remove the iRule. (Get eveyone off of the maintence page)

 

Can the experts tell me if this will work and is it a good idea?

 

Also, if there a better way to lock out the internet but let internal users in, I am willing to look at any solution.

 

T hanks

 

Ross

 

 

 

 

 

 

 

 

 

 

5 Replies

  • When we are doing site maintenance at my company we actually have secondary VIPs for those performing the maintenance/testing. The new VIPs listen on the same IP but on a non-standard port (4011-4014 for http to legs 1 through 4 and 5011-5014 for https to legs 1 through 4). These new VIPs point to pools which still send traffic over 80/443 so everything works the same in the back end. This also enables us to circumvent the load balancing and test one leg at a time.

     

     

    Then, when you want to enter maintenance mode, rather than enabling an iRule which would perform a redirect, make the typical VIP point to a maintenance pool which always performs the redirect you desire via an iRule.

     

     

    when HTTP_REQUEST {

     

    HTTP::redirect "http://www.***.com/Maint_Pages/Maintenance.html"

     

    }

     

     

    When maintenance is complete, make the VIP again point to the "online" pool.

     

     

    At that point it is up to you whether or not you want to attempt to restrict access to the VIPs listening on the maintenance ports but the iRule you currently have would likely serve the purpose of doing so since Akamai should never be initiating connections to those VIPs.

     

     

    Hope this helps,

     

    Brian
  • What if instead of applying the iRule at the time of maintenance it was just always in place and then you trigger the maintenance request portion by disabling all the pool members? You could then proxy your internal requests to a separate pool to handle the testing.

    I haven't validated the syntax of this, however the iRule would look like this. If your default pool is named my_pool_name your internal pool would be named my_pool_name_internal.

    when HTTP_REQUEST { 

    If pool members are down

    if {[active_members [LB::server pool]] < 1}

    if {not ( [IP::addr "[IP::client_addr]/8" equals "10.0.0.0/8"]or[IP::addr "[IP::client_addr]/12" equals "172.16.0.0/12"]or[IP::addr "[IP::client_addr]/16" equals "192.168.0.0/16"]or[IP::addr "[IP::client_addr]/25" equals ".../25"]or[IP::addr "[IP::client_addr]/28" equals ".../28"]or[IP::addr "[IP::client_addr]/26" equals "..."] ) } {

    HTTP::redirect "http://www.***.com/Maint_Pages/Maintenance.html"

    } else {

    Send to internal pool

    pool "[LB::server pool]_internal"

    }

    }

    }

    The down side is the fact you know have to keep two pools updated when you add/remove members.

  • I agree with Bryce's suggestion. Additionally, you could clean up / optimize the iRule by using a datagroup with the defined networks and use matchclass.

    https://devcentral.f5.com/wiki/default.aspx/iRules/matchclass

    You could create a datagroup named internal_networks_datagroup with a list of subnets/networks and use something like the following:

    
    If pool members are down
    if {[active_members [LB::server pool]] < 1} {
        if { [class match [IP::client_addr] equals internal_networks_datagroup] } { 
            If client is internal send to internal pool
            pool "[LB::server pool]_internal"
         } else {
            Send external connections to maintenance page
            HTTP::redirect "http://www.***.com/Maint_Pages/Maintenance.html"  
         }
    }
    
  • First I would like to thank everyone for the prompt replies.

     

     

    I like the cleanup suggestion of the data class. When it was just the private ranges it was not too bad, but as the list has grown, the rule has become ugly.

     

     

    The solution, as defined, will require the creation of two pools for each VIP I want to use this solution with. I will have to run that past the team.

     

     

    Again, thanks for word of wisdom.

     

  • First I would like to thank everyone for the prompt replies.

     

     

    I like the cleanup suggestion of the data class. When it was just the private ranges it was not too bad, but as the list has grown, the rule has become ugly.

     

     

    The solution, as defined, will require the creation of two pools for each VIP I want to use this solution with. I will have to run that past the team.

     

     

    Again, thanks for word of wisdom.