iRule errors out on Insert operation

can you post the irule?

is there HTTP::redirect or HTTP::respond in the irule?

I apologize I don't want to post the iRule for compliance reasons.

And yes, the same VIP has also a HTTP::redirect irule applied. No HTTP::Respond.

Would the logic of the iRule attempt to insert the header and perform a redirect at the same time?

I am sorry I should have been clear.

The other iRule has the following in it. So it's the respond not the redirect:

when HTTP_REQUEST {
                                HTTP::respond 301 Location "http://www.company-name.com[HTTP::uri]"
                }

The md5var was to tie the request and response together.

I think we can all appreciate your desire for compliance, but the information provided (or rather not provided) is making it difficult to troubleshoot the issue. Would it be at all possible to generalize/sanitize your iRules and post them here?

Here you go. The iRule that has problems:

when CLIENT_ACCEPTED {

    set applayer_hsl [HSL::open -proto UDP -pool hslog_pool]     
    set ClientPort [TCP::local_port]         

}

when HTTP_REQUEST {

    set http_request_time [clock clicks -milliseconds]

    set req_time [clock format [clock seconds] -format "%D %H:%M:%S %z"]

     generation of UUID.
    set id "[IP::client_addr][TCP::client_port][IP::local_addr][TCP::local_port][expr { int(100000000 * rand()) }]" 
    binary scan [md5 $id] H* md5var
    log local0. "$md5var"

    insert the generated unique id as header  
    HTTP::header insert F5-Unique-Id $md5var

    set http_request "[HTTP::request]HttpKalive:[HTTP::is_keepalive]\r\nHttpVer:[HTTP::version]\r\nF5Addr:[IP::local_addr]\r\nClientIP:[IP::client_addr]\r\nTime:$req_time\r\nPort:$ClientPort\r\nTimeinMills:$http_request_time"
       append http_request "\r\nf5UniqueId:$md5var"

}


when LB_SELECTED {

    set lb_selected "Server:[LB::server addr]\r\nPool:[LB::server pool] "
    append the the worker selected to http_request
    append http_request "\r\n$lb_selected"

     log local0. "Selected [LB::server addr]"
}


when HTTP_RESPONSE {

    calculate the response time and append it
    append http_request "\r\nresponseTime: [expr {[clock clicks -milliseconds] - $http_request_time}]"

    set response "Set-Cookie:[HTTP::header values Set-Cookie]\r\nContent-Type:[HTTP::header Content-Type]\r\nContent-Encoding:[HTTP::header Content-Encoding]\r\nContent-Length:[HTTP::header Content-Length] "

    log local0.info "<190>\r\n$http_request\r\n$lb_selected\r\n--||--\r\n$response"

    HSL::send $applayer_hsl "<190>\r\n$http_request\r\n--||--\r\n$response\r\n"


}

The iRule that has the respond:

when HTTP_REQUEST {
 HTTP::respond 301 Location "http://www.company-name.com[HTTP::uri]"
}

i guess there is condition check to decide whether to redirect or not (HTTP::respond) but you sanitized it, isn't it?

so, can you try event priority and event disable something like this?

priority

event

e.g.

when HTTP_REQUEST priority 100 {
 HTTP::respond 301 Location "http://www.company-name.com[HTTP::uri]"
 event HTTP_REQUEST disable
}

In any case:

when HTTP_REQUEST {
    HTTP::respond 301 Location "http://www.company-name.com[HTTP::uri]"
}

would cause an infinite loop if the URL is pointing to itself. If it isn't pointing to itself, then priority would matter here. If this iRule fired first, then none of the other iRule logic should be applied. If it fired last, then you have a situation where you're doing a redirect (an egress function) and inserting a header (ingress function) at the same time. That would cause an error.

It is redirecting to other virtual IP. Not having an infinite loop problem.

Regarding the priorities, why would the same setup work in a different data center that has Big IP 11.4 in it without having to set the priorities?

Are the iRules listed in the same order in the VIP configurations? If I'm not mistaken, the ability to order the iRules in the GUI was introduced in v11. Prior to that you could add the iRules in any order, but couldn't guarantee they'd fire in that order. That's where the priority command would come into play.