how can i troubleshoot an irules logic

Hi Mulhollandm, The best way to handle is to put up the original iRule and the one with modification then we may find out why is it happening.

Hi Mulhollandm, The best way to handle is to put up the original iRule and the one with modification then we may find out why is it happening.

If I may add, if I can impart any particular wisdom about iRules, it would be that

log local0. is your friend

There are a bunch of ways to troubleshoot iRules, but the above should be a poster that you hang on your wall. Using the log command

https://devcentral.f5.com/wiki/iRules.log.ashx

You can insert information into your code to show you what things look like at different stages, and what paths an iRule takes. Example:

when HTTP_REQUEST {
    log local0. "Request URI is [HTTP::uri]"      
    switch [string tolower [HTTP::uri]] {        
       ...
    }
}

The above log statement will tell you what the user is requesting, which will make troubleshooting your switch statement easier. Anywhere you're not sure about what the iRule is doing, or what a variable might contain, drop in a log statement. Then from the command line, watch the iRule processing in real time:

tail -f /var/log/ltm

Just remember to remove/comment out your log statements before you put the iRule in production.

You should be using

IP::client_addr

Just FYI, you should try and avoid using hyphens '-' in object names (such as your Data Groups) as it can result in misinterpretation.

I would just add that a good rule of thumb, whenever accepting input from the client, is to normalize that input before trying to evaluate it. For string values, I'd use the [string tolower ] function and make sure the values in your data group are also lower case.

when HTTP_REQUEST {
    if { [class match [string tolower [HTTP::host]] contains PROXY_VM] } { 
        pool PROXY_VM
    } elseif { [class match [string tolower [HTTP::host]] contains GSI_LIST] } {
        pool GSI_PROXY 
    } elseif { [class match [IP::client_addr] equals INTERNAL_IPLIST] } {
        pool PROXY_VM 
    } else {
        pool PROXY_POOL
    }
}

kevin

once again thanks for your input

i'm still having the same problem but i believe its to do with how i've defined my problem

the ip addresses defined in INTERNAL_IPLIST are destination addresses not source addresses

the script works and sends traffic to PROXY_VM if i put my source address but then i lose internet access as traffic is sent the internal proxy

i've tried using remote_addr and server_addr but neither works and traffic to http://10.27.1.254 is still sent to the internet facing proxies (PROXY_POOL)

thanks again

Do the first two conditions work? If the requested host is in one of the data groups?

kevin

it works if i add it to the PROXY_VM list, this sends to the same proxy pool as the INTERNAL_IPLIST i hope to use

the only difference is that i had hoped to have one group for strings and another for ip ranges

the GSI_LIST sends to an extranet proxy pool that doesn't have routes to our internet network

i had read that using string groups for addresses can be cpu entensive

thanks again

Okay, maybe better to go back to framing the requirement with some pseudocode. Please tell me if this is correct:

if the requested URL is in the PROXY_VM data group
    use the PROXY_VM pool
else if the requested URL is in the GSI_LIST data group
    use the GSI_PROXY pool
else if the destination address is in the INTERNAL_IPLIST data group
    use the PROXY_VM pool
else 
    use the PROXY_POOL pool

kevin

i think i've resolved this but i'd be keen to hear your views

i ran the logging you suggested with both client_addr and remote_addr but it showed my ip address in both fields so i thought maybe the ltm isn't seeing the address (10.27.1.254) i was using in my address data group

log local0. "node ip [server_addr] client ip [IP::client_addr] LB ip [LB::server] HTTP HOST [HTTP::host ] HTTPURI [HTTP::uri]"

i'm using the virtual ip on the ltm as an explicit proxy so whenn the client requests a url the source ip is the client but the destination ip is the ltm not the ip address in the url

so i think the only way to pick up the address 10.27.1.254 in the url is by using a string data group with the http::host variable and then manipulate where to send it then

does this make sense?

thanks again for your help, its greatly appreciated