Forum Discussion

Mike_Janson_623's avatar
Mike_Janson_623
Icon for Nimbostratus rankNimbostratus
Jun 02, 2008

ProxyPass 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?
application delivery
dev
devops
iRules

8 Replies

Sort By
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Jun 03, 2008
    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_623's avatar
    Mike_Janson_623
    Icon for Nimbostratus rankNimbostratus
    Jun 06, 2008
    Attaching the irule. As you can see, the first line of when HTTP_REQUEST { ... } is

     

     

    set bypass 1

     

     

     

  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Jun 06, 2008
    I 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_623's avatar
    Mike_Janson_623
    Icon for Nimbostratus rankNimbostratus
    Jun 06, 2008
    We 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_623's avatar
    Mike_Janson_623
    Icon for Nimbostratus rankNimbostratus
    Jun 06, 2008
    Thanks 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_623's avatar
    Mike_Janson_623
    Icon for Nimbostratus rankNimbostratus
    Jun 06, 2008
    When 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?

     

  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Jun 09, 2008
    I'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