cancel
Showing results for 
Search instead for 
Did you mean: 

LTM irule with universal persistence

DevP
Altostratus
Altostratus

Hi there,

Can anyone perhaps advise on setting up the irule for creating universal persistence based on a part of the uri?

I used the irule shown below.
The persistence table lookup shows a correct persistence (show /ltm persistence persist-records)
But the http_response_log also shows the persistence somewhere fails.
The result is that the application on the backend servers fails when these connections are loadbalanced to different servers.

when HTTP_REQUEST {
set client [IP::client_addr]:[TCP::client_port]
set var1 [URI::query [HTTP::uri] "myuripart"]
if { $var1 != "" } {
persist uie $var1
}
}

when HTTP_RESPONSE {
if { $var1 != "" } {
persist add uie $var1
log local0.info "http_response_log: $client -> $var1 -> [LB::server]"
}
}

Used K7392 for reference

Thanks in advance.

 

2 REPLIES 2

AlexBCT
MVP
MVP

Hi DevP, 

I suspect that it has to do with the logic in the HTTP_RESPONSE section. In your case, the iRule for the response fully relies on the var1 that's created in the HTTP_REQUEST section. As such, if HTTP_REQUEST already set the persistence record, there is no need to do it for the response as well. If the HTTP_REQUEST section did NOT create a var1 variable, the HTTP_RESPONSE section also won't do anything. 

I would recommend removing the HTTP_RESPONSE section and then see if you still get error messages. If yes, please shout and we can dig a bit deeper. If so, would be great if you could move the log statement to the HTTP_REQUEST section as well. 

For info; the reason why K7392 is mentioning the HTTP_RESPONSE section, is in the special case of cookies. In those requests, the initial request does NOT yet have the cookie and as such, the initial request does not get included in the persistence table, which means persistence for those sessions wouldn't start until the 2nd request, by which time it's already too late. As your requests should always have the "myuripart" in the request, you don't have that issue. - Thanks for referencing the K article though, it helps better understand the code 😉 

Hope this helps. 

Hello AlexBCT,

Added log in the request too:
log local0.info "http_request_log: [persist lookup uie $var1]"

With the logging to the HTTP_REQUEST part of the irule we do see a correct persist to the same server. The HTTP_RESPONSE however shows also a different server. Application is still failing.

Jun 27 10:46:15 BIGIP2 info tmm1[22659]: Rule /Common/irule-persist <HTTP_REQUEST>: http_request_log:
Jun 27 10:46:15 BIGIP2 info tmm1[22659]: Rule /Common/irule-persist <HTTP_RESPONSE>:http_response_log: 10.20.78.132%9:54076 -> myuripart -> /ACC/SERVERPOOL1_443 10.13.50.142%9 443
Jun 27 10:46:15 BIGIP2 info tmm2[22659]: Rule /Common/irule-persist <HTTP_REQUEST>: http_request_log: /ACC/SERVERPOOL1_443 10.13.50.142%9 443
Jun 27 10:46:15 BIGIP2 info tmm2[22659]: Rule /Common/irule-persist <HTTP_RESPONSE>:http_response_log: 10.20.78.132%9:54079 -> myuripart -> /ACC/SERVERPOOL1_443 10.13.50.142%9 443
Jun 27 10:46:16 BIGIP2 info tmm2[22659]: Rule /Common/irule-persist <HTTP_REQUEST>: http_request_log: /ACC/SERVERPOOL1_443 10.13.50.142%9 443
Jun 27 10:46:16 BIGIP2 info tmm2[22659]: Rule /Common/irule-persist <HTTP_RESPONSE>:http_response_log: 10.20.78.132%9:54075 -> myuripart -> /ACC/SERVERPOOL1_443 10.13.50.145%9 443
Jun 27 10:46:16 BIGIP2 info tmm1[22659]: Rule /Common/irule-persist <HTTP_REQUEST>: http_request_log: /ACC/SERVERPOOL1_443 10.13.50.142%9 443
Jun 27 10:46:16 BIGIP2 info tmm1[22659]: Rule /Common/irule-persist <HTTP_RESPONSE>:http_response_log: 10.20.78.132%9:54084 -> myuripart -> /ACC/SERVERPOOL1_443 10.13.50.142%9 443
Jun 27 10:46:16 BIGIP2 info tmm[22659]: Rule /Common/irule-persist <HTTP_REQUEST>: http_request_log: /ACC/SERVERPOOL1_443 10.13.50.142%9 443
Jun 27 10:46:16 BIGIP2 info tmm[22659]: Rule /Common/irule-persist <HTTP_RESPONSE>:http_response_log: 10.20.78.132%9:54073 -> myuripart -> /ACC/SERVERPOOL1_443 10.13.50.145%9 443
Jun 27 10:46:16 BIGIP2 info tmm[22659]: Rule /Common/irule-persist <HTTP_REQUEST>: http_request_log: /ACC/SERVERPOOL1_443 10.13.50.142%9 443
Jun 27 10:46:16 BIGIP2 info tmm[22659]: Rule /Common/irule-persist <HTTP_RESPONSE>:http_response_log: 10.20.78.132%9:54073 -> myuripart -> /ACC/SERVERPOOL1_443 10.13.50.145%9 443
Jun 27 10:46:16 BIGIP2 info tmm2[22659]: Rule /Common/irule-persist <HTTP_REQUEST>: http_request_log: /ACC/SERVERPOOL1_443 10.13.50.142%9 443
Jun 27 10:46:16 BIGIP2 info tmm2[22659]: Rule /Common/irule-persist <HTTP_RESPONSE>:http_response_log: 10.20.78.132%9:54075 -> myuripart -> /ACC/SERVERPOOL1_443 10.13.50.145%9 443
Jun 27 10:46:16 BIGIP2 info tmm2[22659]: Rule /Common/irule-persist <HTTP_REQUEST>: http_request_log: /ACC/SERVERPOOL1_443 10.13.50.142%9 443
Jun 27 10:46:16 BIGIP2 info tmm2[22659]: Rule /Common/irule-persist <HTTP_RESPONSE>:http_response_log: 10.20.78.132%9:54075 -> myuripart -> /ACC/SERVERPOOL1_443 10.13.50.145%9 443
Jun 27 10:46:17 BIGIP2 info tmm2[22659]: Rule /Common/irule-persist <HTTP_REQUEST>: http_request_log: /ACC/SERVERPOOL1_443 10.13.50.142%9 443
Jun 27 10:46:17 BIGIP2 info tmm2[22659]: Rule /Common/irule-persist <HTTP_RESPONSE>:http_response_log: 10.20.78.132%9:54075 -> myuripart -> /ACC/SERVERPOOL1_443 10.13.50.145%9 443
Jun 27 10:46:32 BIGIP2 info tmm2[22659]: Rule /Common/irule-persist <HTTP_REQUEST>: http_request_log: /ACC/SERVERPOOL1_443 10.13.50.142%9 443
Jun 27 10:46:32 BIGIP2 info tmm2[22659]: Rule /Common/irule-persist <HTTP_RESPONSE>:http_response_log: 10.20.78.132%9:54087 -> myuripart -> /ACC/SERVERPOOL1_443 10.13.50.143%9 443

Any ideas to look for?