abort for requests in F5

Question

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?

simon_blakely · Answer

K15415:&nbsp;&nbsp;Error Message: 01220009:6: Pending rule event HTTP_REQUEST aborted on flow &nbsp;Are you doing something like a TCP::collect or HTTP::collect in your irule?

akshay_sk · Answer

&nbsp; 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 · Answer

Ah - OK.&nbsp;&gt;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?&nbsp;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.&nbsp;Note that this is informative, and that the client has aborted the request.So yes - the request was aborted, but not by the BigIP.

akshay_sk · Answer

&nbsp; 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?

simon_blakely · Answer

&gt; 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?&nbsp;iRule use can always impact performance. You should be monitoring iRule CPU use to determine if it is negatively impacting performance.&nbsp;&gt; Also, will I see the same message in case where the iRule is in pending state and the request gets timed out?&nbsp;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.

Forum Discussion

<HTTP_REQUEST > abort for requests in F5

5 Replies

Recent Discussions

Office Online Server with SharePoint 2016

health monitor source IP address

How to target only webview rendering with CSS?

ltm policy asm_auto_l7_policy

MAC address not showing up in LLDP packet

Related Content

Distributed caching of authentication requests with NGINX Ingress Controller

Logging DNS Requests

F5 AWAF - bypass request based on the pressence of a request header - value

Using Client Subnet in DNS Requests

Large payload post requests aren't responding