iRule - unexpected behavior

Forums Technical Forums
,
1

Hello Community,

I have recently experienced an unexpected behavior from an iRule, where the http responses were intermittent and failure detected on the last event in the iRule HTTP_RESPONSE_RELEASE.

We have noticed the odd behaviour started when the log destination pool members failed to respond to health-check monitor (server down).

Below is a snippt of the iRule event where the failure observed.

when HTTP_RESPONSE_RELEASE {
    # figure out the final duration and add it to the IPFIX log
    set stop [expr {[clock click -milliseconds] - $start}]
    IPFIX::msg set $rule1_msg1 flowDurationMilliseconds $stop
    
    # send the IPFIX log
    IPFIX::destination send $static::http_rule1_dest $rule1_msg1
  } 

 I’m questioning two things:

  1. Why the failure was intermittent and havent affeted all responses?
  2. Why the pool memebrs status affected the iRule when they went down?

I’d appreciate any explanation.

Regards,

Sarah.

2

how long is the timeout value of the ipfix pool’s health monitor?

you might also try tcl async::exec for the “IPFIX::destination send …” so http response forwarding to client doesnt need to wait for the completion of the ipfix transmission
https://wiki.tcl-lang.org/55225#pagetoc7f911216

3

Hi zamroni,

I was using the default udp health monitor (timeout 16).

if “IPFIX::destination send” waits for the completion of the ipfix transmission, why do you think the http responses were intermittent since the pool went down? i suspected it will affect all responses.

the ipfix pool was down for a while, which in result affected the application response stability, where the iRule was applied to.

and it only got fixed when I removed the health monitor from the pool.

4

HTTP_RESPONSE_RELEASE is triggered when f5 is about to release data to client.

which means f5 will execute the commands in your irules before sending response to client.

is the ipfix server health status flappy (intermittently ok / not ok) when the health monitor was applied?

5

The ipfix server totally knockout at that time, there was no flapping.

Here’s why i’m questioning the intermittent behaviour of the http responses on the clientside, could this possibly have to do with a specific type of responses or maybe a present of an http header made the irule act funky?

It is worth to mention two minutes after the ipfix server went down a TCL error logged mentioning the last line "IPFIX::destination send .. " , and it appeared that minute only.

whereas in the irule statistics, the failure stats was increasing for the HTTP_RESPONSE_RELEASE event.

6

Great explanation for me, thanks  @Sarah