Any iRule applied to a virtual will be initialized when the configuration is loaded, either automatically at boot, a GUI config change to that object, or an explicit save to the config via tmsh, regardless of state. Once the standby becomes active, the virtual will start processing traffic and any applied iRules will fire. There's a lot going on in RULE_INIT there and I'm curious (I don't know the answer) how this section of the code behaves on a load on a standby system:
# Hide the members command from the iRule parser (BZ381099 comment 7)
set static::members_cmd "members -list $static::snatpool_name"
# Clear any pre-existing array of the same name
unset -nocomplain static::snat_ips
# Initialize a counter for the number of SNAT pool members
set static::i 0
# Loop through the SNAT pool members and add them to an array for faster access
# If the SNAT pool is modified, the RULE_INIT code needs to be re-run to re-read the SNAT pool
# Make a simple change like adding a space to a comment to force a re-run of RULE_INIT.
foreach static::snat_ip [eval $static::members_cmd] {
set static::snat_ips($static::i) [lindex $static::snat_ip 0]
incr static::i
}
I'd try to log your array on RULE_INIT after it's built to see if it's empty. That might explain the issues if snats aren't being assigned properly because the modulo operation is resulting in very different assignments.
Cirrus
