cancel
Showing results for 
Search instead for 
Did you mean: 

<HTTP_REQUEST > abort for requests in F5

Akshay_SK
Nimbostratus
Nimbostratus

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?

 

 

5 REPLIES 5

Simon_Blakely
F5 Employee
F5 Employee

K15415:  Error Message: 01220009:6: Pending rule event HTTP_REQUEST aborted on flow

 

Are you doing something like a TCP::collect or HTTP::collect in your irule?

  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?

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.

  Ohh okay. Thanks for the explanation. I understand now. But does it also mean, that usage of table commands can impact the performance of your solutions as the iRule will go into pending state when solutions are under heavy traffic load? Also, will I see the same message in case where the iRule is in pending state and the request gets timed out?

> usage of table commands can impact the performance of your solutions as the iRule will go into pending state when solutions are under heavy traffic load?

 

iRule use can always impact performance. You should be monitoring iRule CPU use to determine if it is negatively impacting performance.

 

> Also, will I see the same message in case where the iRule is in pending state and the request gets timed out?

 

I'm not sure if the message is the same - it may well be. That is only likely to occur if there is an incomplete TCP::collect/HTTP::collect or a timer wait.