Forum Discussion
NimbostratusiRule - wrong variable definition ?
Hi all,
I have the following iRule, which in terms of syntax is fine:
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 [LB::status vs Client_Monitor_VIP]
}
}
if {$status equals "up"} {
host 1.1.1.1
} else {
host 2.2.2.2
}
}
....but it generated the following error message:
TCL error: Rule /Common/iRule_ab.example.ncom - can't read "status": no such variable while executing "if {$status equals "up"} { host 1.1.1.1 } else { host 2.2.2.2 }"Any idea what's wrong with the variable definition? I have tested this without the "status" variable, and TCL was able to "read" the Client_Monitor_VIP status, so it seems to be setup correctly.
Regards
Mariusz
17 Replies
Mariusz_BHello all,
Sorry for the delay with my feedback and thank you everyone for help. I managed to get some help from highly skilled iRule engineer, and below I am placing the final version. The biggest advantage of the iRule is that adding more clients, doesn't require any code modification. All I have to do is to modify 2 data groups; one called Clients_IPs (which is going to be universal, and which will be created for each wide IP.
when DNS_REQUEST { set mon "[class match -value [IP::remote_addr] equals Clients_IPs]" set ip "[class match -value [DNS::question name] equals www.test.com_IP]" if { ( $mon ne "" ) && ( $ip ne "" ) } { if {[LB::status vs $mon up]} { host [getfield $ip "," 1] } else { host [getfield $ip "," 2] } } }Regards
Mariusz
- nice! I try to keep logic in the iRule, data in data-groups personally, but during development for rapid prototyping I put the data in the iRule in if/else or switch conditions.For simple situations where the list won't grow beyond a few entries, if/else or switch is fine.
- Mariusz_BYes, you're right. Probably www.test.com_IP is not necessary. To simplify I can hardcode the IPs. I have to create separate iRule for each Wide IP anyway. This is good if you expect your IP to be change in the future. In this case you don't have to interfere with the iRule code. Cheers
