Forum Discussion

Malcom_Sargla_6's avatar
Malcom_Sargla_6
Icon for Nimbostratus rankNimbostratus
Jun 29, 2006

BIGIP irule Case c279577

Dear Forum;

 

 

Can someone please assist with the following issue.

 

 

Title: iRules not operating correctly

 

Severity: General Assistance Condition: Open-Dispatch

 

Product: BIG-IP LTM Version: 9.1.1

 

Serial No.: bip062519s Ticket Number:

 

 

BigIP irules in place for redirects are not functioning as expected.

 

 

Rule 1 -

 

 

when HTTP_REQUEST {

 

if { [matchclass [HTTP::uri] starts_with $::PRV_URIs_no_persist] } {

 

persist none

 

pool PRV-Stage

 

}

 

}

 

 

Rule 2 -

 

 

when HTTP_REQUEST { redirect to "https://www2.provisioning.na.blackberry.com"

 

}

 

 

Even though sites matching the first rule is getting hits without errors, it

 

doesn't stop and moves on to the second rule, causing all sites to get

 

redirected.

 

 

 

*TROUBLESHOOTING STEPS TAKEN:

 

Tried reapplying irules and modification of existing by modifying if

 

statements.

 

These are the exact configs used in other production environments. Not sure

 

why it isn't working in this environment.

 

 

*DIAGNOSTIC DATA PROVIDED: [tcpdumps, qkview output, logs, ?]

 

 

qview output

 

 

 

*IMPACT TO YOUR BUSINESS: [High / Medium / Low, ?]

 

 

High

 

 

*NUMBER OF F5 UNITS AFFECTED: [HA Pair, Sync Group, Single System, ?]

 

 

HA Pair

 

8 Replies

  • Deb_Allen_18's avatar
    Deb_Allen_18
    Historic F5 Account
    To terminate rule processing for the HTTP_REQUEST event once the condition is satisfied and the pool is selected, you can simply add the command "return" after the pool selection within the condition in your first rule:
    when HTTP_REQUEST {
      if { [matchclass [HTTP::uri] starts_with $::PRV_URIs_no_persist] } {
        persist none
        pool PRV-Stage
        return
      }
    }

    HTH

    /deb
  • I wish I could say that worked but unfortunately it did not. Do you have anything else I could try. Thank you again in advance,

     

     

    Malcom.
  • Hi,

    Are you trying to send requests for a specific set of URI's to a pool and redirect all other requests to the https-based URL?

    If so, I think you would want to combine the two rules into one and use an else statement so that only one action is taken. Otherwise, both rules will be evaluated.

    I suppose you could use a global variable to track whether the condition in the first rule had been matched and then skip the evaluation of the second rule, but this seems less efficient than using a single rule.

    You could try something like this:

    
    when HTTP_REQUEST {
       if { [matchclass [string tolower [HTTP::uri]] starts_with $::PRV_URIs_no_persist] } {
          persist none
          pool PRV-Stage
       } else {
          HTTP::redirect "https://www2.provisioning.na.blackberry.com"
       }
    }

    Aaron
  • If you have to have two different HTTP_REQUEST events (Whether in the same iRule or different ones, you can disable further processing on that iRule with the event disable command (Click here).

    Keep in mind that this will disable the specified event for the entire connection so if you have HTTP Keep-Alives setup (multiple HTTP requests on the same connection), it will not process any instances of that event for the duration of the connection.

    when HTTP_REQUEST {
      if { [matchclass [HTTP::uri] starts_with $::PRV_URIs_no_persist] } {
        persist none
        pool PRV-Stage
        event disable
      }
    }
    when HTTP_REQUEST {
      redirect to "https://www2.provisioning.na.blackberry.com"
    }

    The only problem here is that you are not guaranteed which event will be called first since they both that the same priority. It is very likely that your redirect event could be fired before the matchclass check. I'd specifically set a priority to ensure the first one gets fired first.

     set the priority to 400
    when HTTP_REQUEST priority 400 {
      if { [matchclass [HTTP::uri] starts_with $::PRV_URIs_no_persist] } {
        persist none
        pool PRV-Stage
        event disable
      }
    }
     use the default priority of 500
    when HTTP_REQUEST priority 500 {
      redirect to "https://www2.provisioning.na.blackberry.com"
    }

    See this post regarding setting priorities for events:

    http://devcentral.f5.com/default.aspx?tabid=28&view=topic&forumid=5&postid=1798http://devcentral.f5.com/default.aspx?tabid=28&view=topic&forumid=5&postid=1798

    Click here

    Now, if you need to process multiple requests within the same connection then you are going to have to do some work with variables and store the state in the first and check it in the second.

     set the priority to 400
    when HTTP_REQUEST priority 400 {
      if { [matchclass [HTTP::uri] starts_with $::PRV_URIs_no_persist] } {
        persist none
        pool PRV-Stage
        set issue_redirect 0
      } else {
        set issue_redirect 1
      }
    }
     use the default priority of 500
    when HTTP_REQUEST priority 500 {
      if { $issue_redirect == 1 } {
        redirect to "https://www2.provisioning.na.blackberry.com"
      }
    }

    Hope one of these solutions works for you.

    -Joe
  • Thanks for the tips Joe.

     

     

    We implemented "event disable" and seems to have done the trick.

     

     

    I was wondering if you knew of any documentation that describes irule evaluation order in greater detail.

     

     

    I didn't think the priority would apply to our config, since we are using two different irules. Our understanding is that the irules will be evaluated in the order they were applied to the VS. It looks like the priority would only come into play when you had two or more "HTTP_REQUEST" statements in the same irule.

     

     

    Are those statements correct?

     

     

    Thanks again

     

     

    Chris
  • For some reason event disable doesn't work for me. I have an multiple iRules that do 301 redirects. But if the first one (priority 10) has executed then in that one I call "event disable" and it shouldn't process any further iRules with the HTTP_REQUEST event. But it does. What am I doing wrong???
  • Can you post your rule(s) which aren't working along with a debug log statements showing both rules being triggered?

     

     

    Thanks,

     

    Aaron