Forum Discussion

Akshay_SK's avatar
Akshay_SK
Icon for Nimbostratus rankNimbostratus
Feb 21, 2020

<HTTP_REQUEST > abort for requests in F5

After going through the syslogs of my F5, I came across the following log :

 

Feb 21 00:33:12 10.10.207.185 slot1/BIG123BGF501 info tmm[13456]: 23432434:6: Pending rule /Common/MY_PATTERNS_CHECK <HTTP_REQUEST > aborted for 32.64.6.11:40575 -> 16.16.123.13:443

 

Some searching through DevCentral posts revealed that this might be due to the TMM (Traffic management memory) getting exhausted. As per my understanding and according to the log, the request received could not be scanned by the <HTTP_REQUEST> event in iRule and hence scanning of the request by the iRule was aborted. But does it also mean that the actual request from 32.64.6.11:40575 -> 16.16.123.13:443 was also dropped/aborted?

Also I have avoided the use of static variables which inappropriately used are known to cause CMP problems. How can I validate which code in my iRule can cause CMP problems?

 

 

BIG-IP
iRules
security
    • Akshay_SK's avatar
      Akshay_SK
      Icon for Nimbostratus rankNimbostratus
      Feb 26, 2020

        No I am not doing any of those. But to let you know, I am using switch -glob for pattern matching and using HSL for sending a log string to my syslog servers. I am also using certain table lookup and table add commands with hold time for temporary storage. Can any of these cause the mentioned issue?

      • Simon_Blakely's avatar
        Simon_Blakely
        Icon for Employee rankEmployee
        Feb 26, 2020

        Ah - OK.

         

        >I am also using certain table lookup and table add commands with hold time for temporary storage. Can any of these cause the mentioned issue?

         

        To make table access CMP compliant, the irule execution is dropped into the pending state during table access/update, because this operation may access other tmm instances.

        So if the client aborts the connection with a reset while the irule is in HTTP_REQUEST and is updating the session table, you will get the message that you have been seeing.

         

        Note that this is informative, and that the client has aborted the request.

        So yes - the request was aborted, but not by the BigIP.