For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

Mike_Gorski_625's avatar
Mike_Gorski_625
Icon for Nimbostratus rankNimbostratus
May 03, 2018

Issues with Table Lookup command

Hello,

 

I'm looking on some information about the expected output and data-type for "table lookup" especially in corner cases (entry does not exist, etc).

 

In the Wiki it does not specify the output - but it does show example code as:

 

if { [table lookup -subtable "blacklist" $srcip] != "" } {...}

Which seems to indicate a string output is expected. We have seen some strange behavior with code like:

 

if {[table lookup -notouch $l7table] eq "" } {
table set $l7table 1 3
} else {
table incr -notouch $l7table
}

In some cases we have seen that table entry gets created with a timeout other than the expected 3 seconds, which leads me to believe it is possible that the entry is nonexistent but returning something other than NULL. In this case the "table incr" command would create a net-new entry with value of 1 and timeout of 180 (default).

 

So my question - what are the various return values for "table lookup"? Is it possible the VERY FIRST TIME a table lookup is performed (having never even created the table entry) it returns a different value than NULL? It would certainly explain the behavior.

 

application delivery
iRules
LTM

3 Replies

  • Mike_Gorski_625's avatar
    Mike_Gorski_625
    Icon for Nimbostratus rankNimbostratus
    May 03, 2018

    Now that I dig deeper I am seeing documented examples of iRule code using "table lookup" with numeric and string comparisons interchangeably

     

    if { [table lookup -notouch $mykey] equals "" } {
table set $mykey "1" $timeout $timeout
}

    Note, the above example uses "equals" (a string comparison) and subsequent table set command uses "1" (a string value).

     

    if { [table lookup -notouch $mykey] == "" } {
table set $mykey 1 $timeout $timeout
}

    Above, uses numeric comparison (==) and subsequent set command uses numeric 1 (not string).

     

    So I think the assumption is that any needed type-casting will be handled gracefully. It still doesn't explain the error condition we ran into.

     

  • youssef1's avatar
    youssef1
    Icon for Cumulonimbus rankCumulonimbus
    May 03, 2018

    Hello Mike.

     

    When you use "table lookup" allow to Looks up a value associated with the specified key. So if the value is not set you will necessarily have a null value.

     

    I regularly use this type of implementation and I do not have a problem...

     

    In my case I use the "eq" to check if the value don't exist...

     

    you still encounter problems? if so can you tell me more

     

    regards

     

  • Lee_Sutcliffe's avatar
    Lee_Sutcliffe
    Icon for Nacreous rankNacreous
    May 03, 2018

    You can verify if the table lookup is returning anything by adding a simple logging line:

     

    if {[table lookup -notouch $l7table] eq "" } {
    table set $l7table 1 3
} else {
    log local0. "Table lookup:[table lookup -notouch $l7table]"
    table incr -notouch $l7table
}

    With regards to your comment about which type of equals to use, TCL doesn't distinguish between variable types, everything is a string. How you use an operator is key. For example 'eq' will always compare two strings whereas '==' is polymorphic, it will decide which type is appropriate and convert the variable if required. This can have a performance impact so best practice is to have a good idea about the data you are interrogating and write code appropriately. You can read more about this here:

     

    Polymorphism - Making TCL operators work for you.

     

    But in a nutshell, using eq or == should have the same result, one may be more expensive than the other depending on the type of variable be interrogated.

     

    Lee