Forum Discussion
NimbostratusCollect and process new payload from same TCP session
Hi Guys,
Another noob question. Is there any way for LTM to process subsequent TCP payload after processing the original? Below is the irule related on my first post - load balance by deciding from data on specific position. Say this rule has already been processed or completed, but the remote app sends in another data payload to be processed just the same but maintaining the TCP session, is it possible? A couple of attempts including tcp::collect again after the release, added priorites and others but none worked. Any inputs?
when CLIENT_ACCEPTED {
TCP::collect
}
when CLIENT_DATA {
use pool2 by default
pool Pool1
set mero [TCP::payload]
log local0. $mero
Start reading at the 5th byte and save 6 characters to $match
if {[binary scan $mero x5a6 match] == 1}{
log local0. "Matched $match"
if { $match eq "000001" } {
log local0. "For Pool 1"
pool Pool1
} else {
log local0. "For Pool 2"
pool Pool2
}
}
TCP::release
}
Thanks again.
Lez
13 Replies
- nitass
Employee
but the remote app sends in another data payload to be processed just the same but maintaining the TCP session, is it possible?you mean to load balance one clientside tcp connection to different pool member based on payload, don't you?
is it similar to this thread?
Dispatch messages from a single connection to pool members
https://devcentral.f5.com/Community/GroupDetails/tabid/1082223/aft/2163630/asg/50/Default.aspx 
rahtoll_74678Hi Nitass,
Yes, from the dispatch thread, i think its somewhat similar though mine selects between 2 pools based on the payload content match. i'll try to replicate the irule you had created particularly using tcp::notify on my irule and see if it works. i will let you know. thanks
lez- rahtoll_74678Hi Nitass,
just attempted to test but im having the error below. I made some random tests adding LB::detach, tcp::close, return...but to no avail. I can see it already started to read the second payload which should be the last but seems it cannot forward to the correct pool as there's already an existing connection. Any thoughts?
Nov 5 21:20:40 local/tmm info tmm[5266]: Rule test_tx_irule5 : Payload is 186
Nov 5 21:20:40 local/tmm info tmm[5266]: Rule test_tx_irule5 : PAYLOAD Matched 000000
Nov 5 21:20:40 local/tmm info tmm[5266]: Rule test_tx_irule5 : PAYLOAD 000000 goes to Pool 2
Nov 5 21:20:53 local/tmm info tmm[5266]: Rule test_tx_irule5 : Payload is 314
Nov 5 21:20:53 local/tmm info tmm[5266]: Rule test_tx_irule5 : PAYLOAD Matched 000001
Nov 5 21:20:53 local/tmm info tmm[5266]: Rule test_tx_irule5 : PAYLOAD 000001 goes to Pool 1
Nov 5 21:20:53 local/tmm info tmm[5266]: Rule test_tx_irule5 : 000001
Nov 5 21:20:53 local/tmm err tmm[5266]: 01220001:3: TCL error: test_irule5 - Address in use (line 1) i nvoked from within "pool Pool1"
when CLIENT_ACCEPTED {
TCP::collect
}
when CLIENT_DATA {
use pool2 by default
pool Pool1
set mero [TCP::payload]
log local0. $mero
Start reading at the 5th byte and save 6 characters to $match
if {[binary scan $mero x5a6 match] == 1}{
log local0. "Matched $match"
if { $match eq "000001" } {
log local0. "PAYLOAD $match goes to Pool 1"
log local0. $match
pool Pool1
} else {
log local0. "PAYLOAD $match goes to Pool 2 "
pool Pool2
}
}
TCP::release
TCP::notify request
TCP::collect
}
Many thanks,
lez 
What_Lies_Bene1Cirrostratus
Lez,
The log output suggests the error is being generated by a different iRule!
Nov 5 21:20:53 local/tmm info tmm[5266]: Rule test_tx_irule5 : 000001
Nov 5 21:20:53 local/tmm err tmm[5266]: 01220001:3: TCL error: test_irule5 - Address in use (line 1) i nvoked from within "pool Pool1"- rahtoll_74678Hi Steve,
Sorry, mixed my irule logs, may have copied the ones up the scroll, i made different irules as i try adding other stuff that i know of to attempt to somewhat make the next payload a new session, but anyway, the last 3 or so attempts, i had same output, "address in use (line 1)". I have read from other posts that such message is a bug in 11.x but im using 10.2, any ideas on this? Thanks.
Lez - What_Lies_Bene1I'm no iRules expert but can I recommend a few things;
1) Remove any persistence profile associated with the VS
2) Use OneConnect with the VS
3) Use the LB:detach command just before each Pool command - rahtoll_74678Hi Guys,
Just an update, below irule seems to have done what i need, though more tests to confirm, thanks Nitass and Steve (option 3 worked)...
when CLIENT_ACCEPTED {
TCP::collect
}
when CLIENT_DATA {
set mero [TCP::payload 11]
Start reading at the 5th byte and save 6 characters to $match
if {[binary scan $mero x5a6 match] == 1}{
log local0. "PAYLOAD Matched $match"
if { $match eq "000001" } {
log local0. "PAYLOAD $match goes to Pool 1"
log local0. $match
LB::detach
pool Pool1
log local0. "Finished choosing POOL 1"
TCP::release
} else {
log local0. "PAYLOAD $match goes to Pool 2 "
LB::detach
pool Pool2
log local0. "Finished choosing POOL 2"
TCP::release
}
}
TCP::release
TCP::notify request
TCP::collect
} - What_Lies_Bene1Glad to hear it. Let us know if the testing isn't successful.
- Lalo_Calvillo_2Hello everyone,
I´m trying to resolve a similar situation where a LB decision is made when a match is founded on payload data. I´m using practically the same iRule structure as Lez example, however it works only the first time the payload is sent. Once the LB decision is made, all the next payload data is delivered to the same elected pool, it means that the match is made only the first payload is received and the following is only forwarded.
This is a simple TCP connection ( no HTTP), a Client-Server permanent session, where I received transactions.
I followed the steps recommended by Steve as well.
1) Remove any persistence profile associated with the VS
2) Use OneConnect with the VS
3) Use the LB:detach command just before each Pool command
Please HELP!!!!! - Lalo_Calvillo_2IT WORKSSSSSS.....I found the issue. I was missing the last configuration part for the iRule that includes the following lines:
TCP::notify request
TCP::collect
Regards......
CALVILLO
![\"F5](\"https://www.f5.com/content/dam/f5/f5-logo.svg\"){kind=logo}
