Forum Discussion

clazba's avatar
clazba
Icon for Nimbostratus rankNimbostratus
Jan 30, 2011

table command, how to log a timeout

Hi,

 

 

I would like to be able to log when a connection has timed out and thus dropped off the table in a rate limiting irule.

 

 

As far as I can tell there is no specific event triggered when a subtable entry has timed out (i.e. removed from the subtable because the timeout value has expired).

 

 

Consequently, I cant see a way of doing this without looping through the subtable and checking the timeout value of each key with 'table timeout - remaining'.

 

 

I see this as an 'ugly' way of doing it and very CPU expensive when the subtable contains thousands of entries.

 

 

 

Is there a better way of doing this ??

 

 

 

Thanks,

 

 

Claud

 

 

 

6 Replies

  • Hey Claud,

     

     

    I don't think there is a way to trigger an event when a table entry expires. Table entries aren't associated with connections by default, so I can see why no event would be triggered for a specific connection.

     

     

    However, it might be useful to be able to tie a table entry to a connection with some kind of ID and then interact with the connection when the entry expires. Maybe Spark has more insight into this?

     

     

    Anyhow, given Support an RFE and use case would probably help.

     

     

    Aaron
  • clazba's avatar
    clazba
    Icon for Nimbostratus rankNimbostratus
    Hey Aaron,

     

     

    Thanks for confirming that. I will raise that with Support. How does TMOS keep track of connections internally? I imagine each connection would be 'tagged' with a unique ID, if that ID could be obtained via means of a variable then - in theory - the connection associated with the ID could be controlled.

     

     

    I would be interested in learning more about this, can anyone shed some light?

     

     

    Claud
  • spark_86682's avatar
    spark_86682
    Historic F5 Account
    Aaron is right; there's no way to get a block of code to run when a table entry expires. Originally, we had planned for an iRule event that would fire whenever any entry expired, but there were some daunting technical problems with that. The eventual solution will very likely look closer to (one of the forms of) the after command, in that for a given entry you'll be able to specify a block of code that will get executed when the entry goes away. That said, please do raise the issue with support, give them your specific use case, and ask for it to be added to ID 348949.

     

     

    Although table entries aren't associated with specific connections, we do have iRule events that are also not associated with a connection (RULE_INIT being the most obvious, but ACCESS_SESSION_CLOSED is another example).

     

     

    Getting a "handle" to a connection is definitely something we're also considering, along with a few other commands to do "interesting" things with them. If you have specific use cases for that, please file a separate RFE for those (we *love* use cases, because we might be able to come up with an easy and efficient way to solve the problem, and then we can use the use cases to validate the solutions we do come up with).
  • clazba's avatar
    clazba
    Icon for Nimbostratus rankNimbostratus
    Thanks for expanding on this Spark and thanks for the ID, that's most useful.

     

     

    At the moment all I would like to do is flag a table entry that has gone 'stale'. As I am adding entries to a subtable to keep track of incoming connections and removing entries from the subtable every time a connection is closed it would be good to flag when a slot has timed out as that would indicate that the connection wasnt closed as intended.

     

     

    I also really like the idea of getting an 'handle' on the connections based on table entries, that would come handy in APM for DTLS traffic - I'll try and put together some use cases specific to that.

     

     

    Claud
  • spark_86682's avatar
    spark_86682
    Historic F5 Account
    Well, if all you want to do is eventually notice that an entry expired, especially if expiration is a rare event, then I think you can just use two counters: one for when you add an entry, and one for when you explicitly delete one. The difference between them minus the current number of entries is how many entries expired on their own.
  • clazba's avatar
    clazba
    Icon for Nimbostratus rankNimbostratus
    Thanks, I had thought of that but that would just tell us how many entries have expired and not which ones specifically. It would be useful to know which entry has timed out on its own (or it's about to time out) so to return its value (TCP socket for example) for forensic purpose.

     

     

    Hence my original post: "Consequently, I cant see a way of doing this without looping through the subtable and checking the timeout value of each key with 'table timeout - remaining'"