Port Redirection Failure
I'm using a Non-Prod F5 running 12.1.2 Build 1.292.271. We have a cluster of nodes that serve up various Apps on different ports. /App1 - 80 /App2 - 81 /App3 - 82 I have configured a pool with members that have all service ports enabled. Also a single VS with a VIP and a service port of 0. Here is my iRule: when HTTP_REQUEST { switch -glob [HTTP::uri] { "/App1*" { set port 80 } "/App2*" { set port 81 } "/App3* { set port 82 } } } when LB_SELECTED { pool [LB::server pool] member [LB::server addr] $port } When running statistics on the iRule I get failures in the "LB_SELECTED" part however from my prospective this should be the correct syntax to change the service port on a pool. I would like some feedback on this configuration and if someone can comment on this configuration. Thanks.
LB_SELECTED and HTTP commands - warning
Hi, It took me off guard when doing some test with TCP profile. Be advised that under some conditions HTTP type commands may generate TCL error like that: TCL error: /Common/host_change_member - Illegal argument. Can't execute in the current context. (line 1) invoked from within "HTTP::host" It was caused by such code: when LB_SELECTED { if { [LB::server addr] eq "10.128.30.110" } { set host "host1.test.com" } else { set host "host2.test.com" } HTTP::header replace Host $host } Pretty safe code I guess, but... If for some reason LB_SELECTED is triggered when no HTTP request is received, then mentioned error will be logged and of course connection will be reset. I don't know other conditions causing this except: In TCP profile enable Verified Accept Above option seems to be rather dangerous for standard type VS (especially HTTP) as it breaks standard LB logic. Instead of performing LB decision after successful client side 3WHS and first HTTP request received it performs LB after receiving SYN packet from client. To avoid this problem it's better to perform HTTP related operations (that have to be based on some data collected during LB_SELECTED which is triggered after HTTP_REQUEST) in HTTP_REQUEST_RELEASE. Piotr