Hi Piotr,
If you need to split an existing iRule because of the 64k limit, then you have to consider not to break the syntax of each independent script. In addition you may include an additional condition, so that the second script would only be triggered if the first script wasn't successful. This would increase the performance very much.
iRule 1:
when CLIENT_ACCEPTED priority 400 {
switch -glob [IP::client_addr] {
"10.10.10.11" {node 10.55.55.55 10001}
"10.10.10.12" {node 10.55.55.55 10002}
....
"10.10.10.253" {node 10.55.55.55 10241}
"10.10.10.254" {node 10.55.55.55 10242}
}
}
iRule 2:
when CLIENT_ACCEPTED priority 401 {
if { [LB::server name] eq "" } {
switch -glob [IP::client_addr] {
"10.10.11.11" {node 10.55.55.55 11001}
"10.10.11.12" {node 10.55.55.55 11002}
....
"10.10.11.253" {node 10.55.55.55 11241}
"10.10.11.254" {node 10.55.55.55 11242}
}
}
}
Alternativly you could also migrate the
[switch]
selection into datagroups and select the pool member into a external datagroup query. It would solve your problem while also consuming less CPU ressources.
when CLIENT_ACCEPTED {
node [class lookup [IP::client_addr] MY_POOL_DATAGROUP]
}
The external datagroup would then look like that.
"10.10.10.11" := "10.55.55.55 10001",
"10.10.10.12" := "10.55.55.55 10002",
...
"10.10.10.253" := "10.55.55.55 10241",
"10.10.10.254" := "10.55.55.55 10242",
"10.10.11.11" := "10.55.55.55 11001",
"10.10.11.12" := "10.55.55.55 11001",
...
"10.10.11.253" := "10.55.55.55 11241",
"10.10.11.254" := "10.55.55.55 11242",
If both approaches are not still not suitable for you, then you have to experiment with iFiles to store +64k TCL scripts in static::variables during RULE_INIT and the execute the script using
[eval]
.
when RULE_INIT {
Combine up to 4Mbyte TCL scripts using iFile
set static::my_very_long_script [ifile filename_part1.txt]
append static::my_very_long_script [ifile filename_part2.txt]
}
when CLIENT_ACCEPTED {
Execute TCL scripts up to 50Mbyte
eval $static::my_very_long_script
}
Note: But be aware the [eval]
technique should be considered as "experimental", since I haven't seen the F5 employees using nor recommending nor disagreeeing this approach...
Cheers, Kai