Forum Discussion

Russ_Pasley's avatar
Russ_Pasley
Icon for Nimbostratus rankNimbostratus
Aug 11, 2015

Maintenance page redirection based on URI match?

Hi,

New to iRules and new to LTM 11.5. We've recently upgraded from 11.3 to 11.5. Traffic redirection to a maintenance page based on a URI match (i.e. https://services.customer.com/service/svcpage*) that used to be accomplished with HTTP traffic classes are now replaced with an iRule using iFiles. Problem is that the rule appears to crash the entire service ( whenever we apply it to the virtual server ("connection was reset with the server" error).

Here's the basic iRule. The virtual server has other iRules that operate it when in normal production and this one is at the top of the order when applied for server maintenance:

when HTTP_REQUEST {
    if { [HTTP::uri] eq "/logo.gif" } {
        HTTP::respond 200 content [ifile get logo.gif]
    } elseif { [HTTP::host]  contains "services" and [HTTP::uri]  contains "svcpage*" } {
        HTTP::respond 200 content [ifile get Maintenance-page-web]      
    } else { discard }
}

The iFile changes sometimes so that clients can go elsewhere on the site via links set up on the page and we have to re-import the file, but we almost always replace what is there. Since the customer doesn't have a test environment that can reliably test this, we're left with troubleshooting under fire of a maintenance event with the customer shaking their collective heads every time. No logs show a problem and I still suspect this deceptively simple rule to be the culprit. Can anyone suggest what's going wrong or ways to debug?

6 Replies

  • Hi,

    If you have other irules, you must be sure only this one will be executed...

    at the end of this irule, add the command :

    event disable
    

    this will disable event HTTP_REQUEST Event for other following irules.

  • I set up a separate virtual server with its own static nat and apply the maintenance page irule/ifile there. i then use a fallback url in the http profile for the production virtual server.

     

    • Russ_Pasley's avatar
      Russ_Pasley
      Icon for Nimbostratus rankNimbostratus
      Great idea, Birddog. I'll certainly tell the guys that thought up this whole iRule thing in the first place. Thanks.
  • Hi

    Connection reset usually indicates problems with the iRule. Have you checked the ltm log (/var/log/ltm)?

    Contains does not support wildcards, perhaps that could be it?

    As for troubleshooting this I'd add the rule to the VIP in question but only execute it for a certain IP.

    Something like this:

    when HTTP_REQUEST {
    
        if { [IP::addr [IP::client_addr] equals 1.1.1.1] } {
            log local0. "Executing maintenance iRule"
            if { [HTTP::uri] eq "/logo.gif" } {
                log local0. "Request for logo.gif, serving it"
                HTTP::respond 200 content [ifile get logo.gif]
            } elseif { [HTTP::host]  contains "services" and [HTTP::uri]  contains "svcpage" } {
                log local0. "Request matching services or svcpage, serving it"
                HTTP::respond 200 content [ifile get Maintenance-page-web]      
            } else { discard }
        }
    }
    

    /Patrik

  • this irule execute HTTP::respond command.

    if one of following irule execute a command modifying the HTTP context like HTTP::header insert, it will raise a TCL error and generate a connection reset.

    that's why I proposed to disable HTTP_REQUEST event...

    the irule should be:

    when HTTP_REQUEST {
        if { [HTTP::uri] eq "/logo.gif" } {
            HTTP::respond 200 content [ifile get logo.gif]
        } elseif { [HTTP::host]  contains "services" and [HTTP::uri]  contains "svcpage" } {
            HTTP::respond 200 content [ifile get Maintenance-page-web]      
        } else { discard }
        event disable
    }
    when HTTP_RESPONSE {
    to enable HTTP_REQUEST Event for following requests
    event HTTP_REQUEST enable
    }
    

    I remove the wildcard in the second statement.

  • Thanks everyone for the suggestions. You've given me a lot of food for thought. We're working with the customer to test in production. I'll post anything that helped solve the issue.