Forum Discussion
Mike_Janson_623
Nimbostratus
NimbostratusProxyPass intermittent errors
We've recently started using ProxyPass on BIG-IP 9.3.1 Build 46.7, generally with favorable results. Thanks for making this available to the customer base!
BUT, we are seeing some intermittent strange behavior. Something in the last HTTP_RESPONSE block seems to cause errors from time to time which in turn cause client disconnects:
May 29 16:24:55 tmm tmm[899]: 01220001:3: TCL error: Rule ProxyPass
- can't read "bypass": no such variable while
executing "if {1 != $bypass} { If you want the iRule to
try to translate URLs within the HTML page then uncomment these two lines and associa..."
This is a bit mind boggling to us because we don't see why this wouldn't be consistently reproducible, or even caught when saving the rule for that matter as it's reporting an issue with the irule syntax.
Any ideas?
8 Replies
hoolioCirrostratus
Hi,
The bypass variable isn't getting set (or is getting unset) for some connections. I'm not sure why the error would be happening intermittently.
You can work around this by checking if the variable is defined before trying to check the value using 'info exists bypass':
if {[info exists bypass] && 1 != $bypass}{
The second comparison will only be done if the first is true, so you can avoid the TCL run time error like this.
Could you post your version of the rule so we can try to see why bypass wouldn't always have a value?
Aaron
Mike_Janson_623Attaching the irule. As you can see, the first line of when HTTP_REQUEST { ... } is
set bypass 1- hoolioI can't see how the bypass variable couldn't be read given just that rule. The variable is being set on every HTTP request and isn't being unset anywhere. Do you have another rule on the same VIP which uses a variable named $bypass and unsets it (grasping at straws...)?
You could add a check to see if the variable isn't set. It wouldn't solve the problem but could allow you to handle the error and possibly log some debug info.if {[info exists bypass]}{ if {1 != $bypass} { ... } else { Log some debug here on the connection details to try to figure out why $bypass isn't set? }
Aaron - Mike_Janson_623We can confirm that there are no other references to a variable with that name in our config:
[root@bigip-90-2a:Active] config grep bypass bigip.conf
set bypass 1
set bypass 0
if {1 != $bypass} {
[root@bigip-90-2a:Active] config
I'm beginning to suspect there problem may lie somewhere else... are there any known issues with the firmware version we're currently running (BIG-IP 9.3.1 Build 46.7)? - Mike_Janson_623Thanks for the suggestion--we'll try that, although as this does not seem to be consistently reproducible we have no way of verifying; we can only hope that by changing things in our test environment, and not witnessing the error over a week or more, it will also clean things up in production.
But this does seem like more of a workaround, than a fix; in the interest of explaining why this is happening, does firmware/Tcl seem like the most likely culprit or is there something else we may want to consider? - Mike_Janson_623When we try moving it here:
when CLIENT_ACCEPT {
set bypass 1
}
We get an error:
01070151:3: Rule [ProxyPass_irule] error:
line 12: [unknown event (CLIENT_ACCEPT)] [when CLIENT_ACCEPT {
set bypass 1
}]
Is that because we're running 9.3? - hoolioI'm sure that F5 support wouldn't like it as this is an issue with a custom iRule, but I'd be interested in what they find if you opened a case on this. As aherman suggests, I don't think there should ever be an HTTP_RESPONSE event triggered if there wasn't an HTTP_REQUEST event first. Perhaps they'd be able to confirm or correct this assumption.
Aaron 
Andy_Herrman_22Out of curiosity, do you have OneConnect enabled?
