Forum Discussion

Altostratus

Nov 20, 2008

A Problem with Datagroup Usage

I am having problems with an iRule that uses datagroups. For some reason it just doesn't seem to work at all. Would you fellas mind taking a look at it and maybe point out any grammatical or logic errors it may have? I have ran it through the iRule Editor and the syntax checks out, but I feel like I am missing something basic that the editor just doesn't pick up...

when HTTP_REQUEST {

set header_uri [string tolower [HTTP::uri]]

if {[matchclass $header_uri starts_with $::www8_uri]} {

pool WWW8_Pool

} elseif {[matchclass $header_uri starts_with $::oam_uri]} {

HTTP::redirect "https://blank.blank.com/oam/main/oamMain.jsp"

} elseif {[matchclass $header_uri starts_with $::hello_uri]} {

pool Hello_Pool

} elseif {[matchclass $header_uri starts_with $::maui_uri]} {

pool Maui_Pool

} elseif {[matchclass $header_uri starts_with $::publicSite_app_uri]} {

pool PublicSite_App_Pool

} elseif {[matchclass $header_uri starts_with $::calli_web_uri]} {

pool Calli_Web_Pool

} elseif {[matchclass $header_uri starts_with $::true_web_uri]} {

pool True_Web_Pool

} elseif {[matchclass $header_uri starts_with $::documentum_uri]} {

pool Documentum_Pool

} else {

pool WWW2_Pool

}

12 Replies

hoolio
Cirrostratus
Nov 20, 2008
The syntax looks fine. Can you add logging to see what's happening? Are all requests hitting the default else? If so, can you post an anonymized sample of the datagroup that your test requests should match?

Thanks,

Aaron
naladar_65658
Altostratus
Nov 20, 2008
Unfortunately I cannot add it back into production with logging turned on for at least another week as that is when our next service window is. This rule is replacing an older iRule that does not use datagroups.

The traffic did seem to work correctly going to the default else now that you mention it.

I wish I had another way to test it but until we get our QA f5 up and going there's not any real good way to do that unfortunately.

One of the Datagroups is "Documentum_uri" and it contains the entry:

/dco/
hoolio
Cirrostratus
Nov 20, 2008
Maybe you can create a test VIP on the live BIG-IPs? If you're on 9.4 or higher, you could even create a test VIP on a non-routable IP and test from the command line of the BIG-IP itself using curl:

curl VIP_ADDRESS/dco/index.html

or for https:

curl -k https://VIP_ADDRESS/dco/index.html

Anyhow, I'd guess the problem might be that the URIs in the datagroups are in mixed case, but you're setting the URI to lowercase before checking it against the datagroups.

Aaron
naladar_65658
Altostratus
Nov 20, 2008
I checked all of the datagroups that I am trying to hit and they are all in lower case. I wonder if maybe I need to use equals or contains rather than the starts_with... or maybe use brackets to enclose the $header_uri variable in each statement?

when HTTP_REQUEST {

set header_uri [string tolower [HTTP::uri]]

if {[matchclass [$header_uri] starts_with $::www8_uri]} {

pool WWW8_Pool

hoolio

Cirrostratus

Nov 20, 2008

If the URI's start with the datagroup members, then 'matchclass $header_uri starts_with $::dg_name' is the right format. Using []'s would try to execute the value of the URI, so that wouldn't work.

You can add logging to help determine what's happening:

 
 when HTTP_REQUEST { 
  
    log local0. "[IP::client_addr]:[TCP::client_port]: New HTTP request to [HTTP::uri]" 
  
    set header_uri [string tolower [HTTP::uri]] 
    log local0. "[IP::client_addr]:[TCP::client_port]: \$header_uri: $header_uri" 
  
    if {[matchclass $header_uri starts_with $::www8_uri]} { 
  
       log local0. "[IP::client_addr]:[TCP::client_port]: Matched www8_uri dg" 
       pool WWW8_Pool 
  
    } elseif {[matchclass $header_uri starts_with $::oam_uri]} { 
  
       log local0. "[IP::client_addr]:[TCP::client_port]: Matched oam_uri dg" 
       HTTP::redirect "https://blank.blank.com/oam/main/oamMain.jsp" 
    ... 
  
    } else { 
       log local0. "[IP::client_addr]:[TCP::client_port]: No match" 
       log local0. "[IP::client_addr]:[TCP::client_port]: dg's: \$::www8_uri: $::www8_uri, \$::oam_uri: $::oam_uri, etc" 
       pool WWW2_Pool 
    }  
 }

Aaron

Joe_Pruitt
Nov 20, 2008
HTTP::uri always starts with a slash. Even for an empty URI (ie. http://www.foo.com), the URI will be "/".

The only thing I could see is that requests like this

http://www.foo.com/dco

will not match because the uri "/dco" doesn't start with "/dco/" <- Notice the trailing slash. This may be what you intended but thought I'd point it out.

-Joe
hoolio
Cirrostratus
Nov 20, 2008
HTTP::uri returns the full URI. For a URL like:

http://www.example.com:80/path/to/index.jsp?param1=value1&param2=value2

[HTTP::host] = www.example.com:80

[HTTP::uri] = /path/to/index.jsp?param1=value1&param2=value2

[HTTP::path] = /path/to/index.jsp

[HTTP::query] = param1=value1&param2=value2

So as long as the requested URI contains the leading and trailing forward slashes (like /dco/test.jsp) it should match the datagroup element, /dco/ using starts_with. If the datagroup had a trailing slash, but the requested URI didn't, then matchclass would return false.

Here is a quick example:

when HTTP_REQUEST { log local0. "[IP::client_addr]:[TCP::client_port]: New HTTP request to [HTTP::uri]" set header_uri [string tolower [HTTP::uri]] log local0. "[IP::client_addr]:[TCP::client_port]: \$header_uri: $header_uri" if {[matchclass $header_uri starts_with $::www8_uri]} { log local0. "[IP::client_addr]:[TCP::client_port]: Matched www8_uri dg" pool WWW8_Pool } elseif {[matchclass $header_uri starts_with $::oam_uri]} { log local0. "[IP::client_addr]:[TCP::client_port]: Matched oam_uri dg" HTTP::redirect "https://blank.blank.com/oam/main/oamMain.jsp" } else { log local0. "[IP::client_addr]:[TCP::client_port]: No match" log local0. "[IP::client_addr]:[TCP::client_port]: dg's: \$::www8_uri: $::www8_uri, \$::oam_uri: $::oam_uri" pool WWW2_Pool } }

And the log output for a request to /dco (shouldn't match the datagroup) and one to /dco/ (should match):

: 10.40.6.136:1394: New HTTP request to /dco

: 10.40.6.136:1394: $header_uri: /dco

: 10.40.6.136:1394: No match

: 10.40.6.136:1394: dg's: $::www8_uri: /dco/ /www1 /www2, $::oam_uri: /oam1/ /oam2 /oam3

: 10.40.6.136:1396: New HTTP request to /dco/

: 10.40.6.136:1396: $header_uri: /dco/

: 10.40.6.136:1396: Matched www8_uri dg

Aaron
naladar_65658
Altostratus
Nov 20, 2008
Thank you for the excellent example and for all the help fellas. I will turn on logging and run a few tests using the info that you provided and then I will post the results.

I did go back into all of the Data Groups and added entries without the trailing slash. Thank you for pointing that out.
naladar_65658
Altostratus
Nov 21, 2008
First off, my apologizies on posting this in the wrong forum! DOH! I should have posted this under iRules, not iControl.

I turned on logging and ran a lot of traffic through the iRule. I went through every datagroup starting from the top and everything appears to be working fine according to the logging. It shows every time that a datagroup string was matched and the datagroup it matched etc.... even the default showed to be working fine.

The only thing that I modified besides adding the logging was I did find some extra whitespace characters that I removed from the ends of a few lines. One was a tab and a few were just a single space on the end of the line. Is it possible those broke the iRule in my previous attempt?
Joe_Pruitt
Nov 21, 2008
Not likely but there are some issues with ending spaces if you carry your start curly brace over to a new line but you didn't do that in your original post.

Once you get things working, I'd recommend you remove the logging so you don't fill up your disk B-).

-Joe