Forum Discussion
Tiaan_92076
Nimbostratus
NimbostratusHow to determine last segment in reaseembled TCP packet
I need to detach the load balancing decision after a transaction is completed on a member in the pool. The transaction occasionally spans multiple TCP segments causing the SERVER_DATA event to be raised more than once for the same transaction. With "LB::detach" in the "SERVER_DATA" event the transaction fails when this happens.
Implementing the "if" statement to check if the payload ends with a certain string and then calling "TCP::notify response" to run "LB::detach" in the "USER_RESPONSE" event solves the problem. Example below from the documentation.
when SERVER_DATA {
log local0.debug "Received SERVER response ... [TCP::payload]"
if { [TCP::payload] ends_with $EOT } {
TCP::notify response
}
TCP::release
TCP::collect
}
when USER_RESPONSE {
LB::detach
log local0.debug "Detaches server connection ... "
if {[TCP::payload length] > 0} {
%TODO%
Process additional client requests here ...
}
}
Can the same be done without checking the payload ? Possibly an event fired when the last segment is received ? I could not find this in the documentation though.
Thanks
18 Replies
Tiaan_92076Thank you. Should the "Last message repeated n times" not be logged when messages are suppressed ? It's not logged in this case.
hoolioCirrostratus
You should see that log message if syslog-ng is suppressing log messages. It looks like TMM also does this. Here is an example message from /var/log/ltm:
Feb 24 04:30:49 local/tmm info tmm[2630]: 01200004:6: Per-invocation log rate exceeded; throttling.
SOL10524: Error Message: Per-invocation log rate exceeded
https://support.f5.com/kb/en-us/solutions/public/10000/500/sol10524.html
Do you see any similar log message when you don't see the iRule logging?
Aaron- Tiaan_92076I don't see any messages other than the messages logged by the iRule. The system is not being used for anything other than my iRule testing at the moment.
- hoolioAs a test, you could try making each log message unique with a global counter. I wouldn't suggest using this in production as it's unnecessary overhead.
when SERVER_CONNECTED { TCP::collect } when SERVER_DATA { if {[info exists ::counter]}{ incr ::counter } else { set ::counter 1 } log -noname local0. "iRule: Received Server Data $::counter" TCP::collect TCP::release }
You might also try removing the -noname flag and see if that has any effect.
Aaron - Tiaan_92076Tested with the global counter, the log message increments correctly.
Feb 24 15:16:58 local/tmm info tmm[2253]: iRule: Received Server Data 45
Feb 24 15:16:58 local/tmm info tmm[2253]: iRule: Received Server Data 46
Feb 24 15:16:58 local/tmm info tmm[2253]: iRule: Received Server Data 47
Feb 24 15:16:59 local/tmm info tmm[2253]: iRule: Received Server Data 48
Feb 24 15:17:00 local/tmm info tmm[2253]: iRule: Received Server Data 49
I then wrote the XML received in the packet to the log from SERVER_DATA.set payload [TCP::payload] set xml [string range $payload [string first log -noname local0. "iRule: $xml"
Although my client get the XML returned, the XML is not logged. So it looks like the SERVER_DATA event is not fired. - hoolioIf you combine the XML payload logging with the global counter do you see the XML logged?
Aaron - Tiaan_92076Yes, but it's either both the global counter message and XML logged or nothing logged at all. Ie, it looks like the SERVER_DATA event is not fired.
- hoolioIf all you're changing is the string being logged, I'd say this is a problem with the logging being suppressed--not with the iRule events triggering. You could open a case with F5 Support to get help troubleshooting this.
Aaron
