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

Without being able to parse the protocol, there's no way for the LTM to know which segment is last. If you are able to figure out how many bytes are in the response (e.g., from parsing the protocol headers), then you can just TCP::collect that many bytes, and SERVER_DATA will only fire when it has the entire response.

So Wireshark can reassemble the packet because it understands the protocol, GIOP in this case, and already have all the TCP segments ? I've looked at the suggestion to parse the protocol headers for the length of the packet. GIOP has a header for message size, but there are multiple GIOP messages per TCP segment. Determining the number of GIOP messages and summing the message size headers would probably be a more expensive operation than just checking the end of the payload for a specific string ?

Looking briefly at the protocol spec, yes, that probably would be more expensive than checking to see if you've got the end-of-transaction marker. If it works for you, then you probably already have the best solution.

I've got the following problem with my iRule when a client uses multiple threads using the same source port for all the threads. Doing a TCPDump I can see the transactions coming in on the outside interface, on the inside interface it goes the the nodes and I can see the response returned from the nodes. But I don't see the response leaving the outside interface. The result is that the client don't get the response and eventually times out. iRule: when RULE_INIT { set ::eot "Marker" set ::eot_found 0 } when SERVER_CONNECTED { TCP::collect } when SERVER_DATA { set payload [TCP::payload] log -noname local0. "iRule: Request from [IP::client_addr]:[TCP::client_port] load balanced to [LB::server addr]" if { $payload ends_with $::eot } { set ::eot_found 1 } TCP::release TCP::collect TCP::notify response } when USER_RESPONSE { if { $::eot_found eq 1 } { set ::eot_found 0 LB::detach } } After adding the "log" to "SERVER_CONNECTED" event I get the following error in the log file. Without this line no errors were logged. TCL error: - Error: No clientside connection established (line 6) invoked from within "IP::client_addr" Why would doing a LB detach effect the client side connection ? Thanks Tiaan

I'm not 100% sure that I understand why you'd get that error just by adding that log statement, but to answer your stated question: LB::detach severs the relationship between the client<->LTM connection and the LTM<->server connection. That's what it's there for; that's what "detaching" is. So once you've detached, well, there is no more clientside connection for this server connection, so that's why you get that error when you ask for the client's address.

How to determine last segment in reaseembled TCP packet

18 Replies

Tiaan_92076
Nimbostratus
Feb 24, 2010
Thank you. Should the "Last message repeated n times" not be logged when messages are suppressed ? It's not logged in this case.
hooleylist
Cirrostratus
Feb 24, 2010
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_92076
Nimbostratus
Feb 24, 2010
I 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.

hooleylist

Cirrostratus

Feb 24, 2010

As 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_92076
Nimbostratus
Feb 24, 2010
Tested 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.
hooleylist
Cirrostratus
Feb 24, 2010
If you combine the XML payload logging with the global counter do you see the XML logged?

Aaron
Tiaan_92076
Nimbostratus
Feb 24, 2010
Yes, 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.
hooleylist
Cirrostratus
Feb 24, 2010
If 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

Forum Discussion

How to determine last segment in reaseembled TCP packet

18 Replies

Recent Discussions

URI modification

Need help on i-rule to specific uri path

HA Active Directory for F5 authentication

NGINX - Need more details on NGNIX WAF

connect to cloudflare or cloud ec2 via SSLO

Related Content

Network segmentation in an AWS VPC

Using BIG-IQ to Determine Differences Between Advanced WAF Policies

determine HTTP or HTTPS

iRules Community Spotlight: Same Segment Load Balancing

How do I determine SP origin on a BigIP IdP