Forum Discussion
Ganesh_Ramamoor
Nimbostratus
NimbostratusTCP Rule question
When I'm using this iRule:
when CLIENT_ACCEPTED {
TCP::collect
}
when CLIENT_DATA {
if { [TCP::payload] contains "XXX" } {
pool XXX
}
elseif { [TCP::payload] contains "YYY" } {
pool YYY
}
elseif { [TCP::payload] contains "ZZZ" } {
pool ZZZ
}
TCP::release
TCP::collect
}
It works when the client sends just one request. But when the client sends subsequent HTTP requests with the tag "YYY", I get this error message:
Nov 8 22:51:12 tmm tmm[762]: 01220001:3: TCL error: Rule TCP-Rule - Address in use (line 5) invoked from within "pool YYY"
Is there anything wrong with this iRule?
Thanks
- Once the lb decision has been made you can't repick a pool. You would need to issue an LB::detach to disconnect the server connection so a new pool could be used. You could certainly just do:
LB::detach pool YYY
LB::detach shouldn't have any effect if it's already detached (eg, the first request). 
Ganesh_RamamoorThanks a lot for your quick response. Is that the behavior even if I have a oneconnect profile? (I tried with and without and got the same result).
I tried with LB::detach and it works fine. But when I do that, suppose if the client sends a request and the server is processing that request and the server is in the process of sending the response. At that if the client sends another request, the LB::detach will close the connection to the server and the the client will not get the response to the first request, is that correct?- Well, actually, you are partially correct. The behavior is different if you have an HTTP profile. When using the HTTP profile (or fasthttp), the completion of each response causes the lb decision to be unlocked so a new pool can be chosen for the subsequent request. In that case, it doesn't actually detach unless the pool is changed. However, when using oneconnect, an implicit detach is done after every response. With regard to pipelining, yes, you would need to be careful about that. Perhaps you should add a variable to indicate a request is pending and you shouldn't process the next request until the response is received. This is behavior the http profile normally takes care of. I'm not sure why you aren't using the http profile, but I assume you have some reason.
- You're sure its the bigip closing the connection? I can't think of any reason is should (especially in the case where you are strictly using TCP). Maybe you should collect tcpdumps for both sides and try to determine for sure if it's the bigip originating the close. Also, is it a clean close or a reset?
- Ganesh_RamamoorWith the HTTP profile, I saw that the bigip was sending a FIN. But now with the TCP profile I see a reset but it's triggered by the server. So this seems to be a different problem and not an issue with the bigip. Thanks for your help.
