iRule - wrong variable definition ?

As status is already a variable used by F5, try changing the variable name for e.g. "status_vs"

That's very interesting. I'll give a try, and post the result in next couple days.

Many thanks!

You should also set a "default" for your switch which set your variable to "down" or something else other wise you will get TCL error when the remote IP doesn't match one of the networks you define in your switch.

when DNS_REQUEST {
    switch [IP::remote_addr] {   
        "10.10.1.32/27" -
        "10.10.1.64/27" -
        "10.10.1.160/27" -
        "10.10.1.192/27" {
            set status_vs [LB::status vs Client_Monitor_VIP]
        }
        default {
            set status_vs "down"
        }
    }
    if {$status_vs equals "up"} {
        host 1.1.1.1
    } else {
        host 2.2.2.2
    }   
}

Hi all,

@Brad: Thank you for the suggestion. At the moment the default is handled by associated pool. If the iRule is not matched, then it goes through the pool rules. I have tested this on a virtual F5s by specifying different IP addresses in the iRule, to the ones from the pool, and I get expected results.

What is very strange is the fact, that there is no difference (on the virtual F5) to behavior between the iRule with the "status" variable and "status_vs". No errors generated with both. However on the physical F5 it's failing. I haven't tested the status_vs on the physical GTMs yet. My virtual F5 has both LTM and GTM enabled in on one instance, while the physical appliances are separate. Is that what can affect the behavior? I am really confused by this. Probably the best way is to apply it on the physical and test it, but it's still interesting what's the difference.

what Brad means is if source is not in 10.10.1.32/27, 10.10.1.64/27, 10.10.1.160/27 or 10.10.1.192/27 subnet, status or status_vs variable will not be created and tcl will throw an error when checking it in if-condition ($status equals "up").

what Brad means is if source is not in 10.10.1.32/27, 10.10.1.64/27, 10.10.1.160/27 or 10.10.1.192/27 subnet, status or status_vs variable will not be created and tcl will throw an error when checking it in if-condition ($status equals "up").

IP::remote_addr will never match those IPs with mask attached, so you should remove the mask if you want that condition to match.

I agree with Brad you should either set a default value for the variable, or use info exists on the variable you've set. Here's a potential solution:

when DNS_REQUEST {
    switch [IP::remote_addr] {   
        "10.10.1.32" -
        "10.10.1.64" -
        "10.10.1.160" -
        "10.10.1.192" {
            set status [LB::status vs Client_Monitor_VIP]
        }
    }
    if {[info exists status]} {
      if {$status equals "up"} {
        host 1.1.1.1
      }
    } else {
        host 2.2.2.2
    }   
}

Hi Mariusz,

if your are using equal length masks (27 bits in this case) only, the following one hopefully solves it:

when DNS_REQUEST {
    switch [IP::addr [IP::client_addr] mask 255.255.255.224] { 
        "10.10.1.32" -
        "10.10.1.64" -
        "10.10.1.160" -
        "10.10.1.192" {
            set status [LB::status vs Client_Monitor_VIP]
        }
    }
    if {$status equals "up"} {
        host 1.1.1.1
    } else {
        host 2.2.2.2
    }   
}

Thanks, Stephan

i understand IP::addr does not return subnet mask.

e.g.

[root@ve11b:Active:In Sync] config  tail -f /var/log/ltm
Feb 20 22:22:05 ve11b info tmm1[14140]: Rule /Common/qux : [IP::addr 10.10.1.33 mask 255.255.255.224]=10.10.1.32

i understand IP::addr does not return subnet mask.

e.g.

[root@ve11b:Active:In Sync] config  tail -f /var/log/ltm
Feb 20 22:22:05 ve11b info tmm1[14140]: Rule /Common/qux : [IP::addr 10.10.1.33 mask 255.255.255.224]=10.10.1.32