Forum Discussion
NimbostratusMBLB for HSM Messages
Hi all !
I´ve been trying to load balance messages destinated to a Thales HSM. Since HSM client uses a single connection to communicate to HSM I´ll use MBLB to achieve that. The HSM Message has a header, a message length indicator and the message itself. I´ve applied a MBLB profife to my virtual server and created the following iRule:
when CLIENT_ACCEPTED {
set client_closed 0
TCP::collect
log local0. "Client Connected !"
}
periodically checks if the client connection closed, if so, also closes associated server connection.
when CLIENT_CLOSED {
set client_closed 1
}
Triggered when a connection has been established with the target node
when SERVER_CONNECTED {
after 1000 -periodic if {$client_closed} {TCP::close}
}
when CLIENT_DATA {
scan [TCP::payload] %c%c head rlen
log local0. "Header = $head -- Length = $rlen"
if {($head == 0)} {
if {[TCP::payload length] < [expr {2 + $rlen}]} {
TCP::collect
return
}
}
TCP::release [expr {$rlen + 2}]
TCP::notify request
TCP::collect
}
I´ve been using a client to send messages to the virtual server. Checking the traffic with TCPDUMP I can see the messages balancing to members of my pool and they´ve been returning to BigIP but the client application only receives the message back when it is originated from the first server selected to handle the message load balancing. Messages from the second server never come back to client.
Follows the behavior on my client application:
Connected!
Send: 0000BA1234F843005571922
Received: 0000BB0058647
Send: 0000BA1234F843005571922
Send: 0000BA1234F843005571922
Received: 0000BB0058647
Send: 0000BA1234F843005571922
Send: 0000BA1234F843005571922
Received: 0000BB0058647
VS Config:
virtual HSM-MBLB {
snat automap
pool LB-POOL
destination 192.168.1.132:1500
ip protocol tcp
rules hsm-mblb
profiles {
mymblb {}
tcp {}
}
}
pool LB-POOL {
members {
192.168.2.10:1500 {}
192.168.2.11:1500 {}
}
}
I´ve been using a BigIP LTM Virtual Edition to test this scenario.
[root@BigIP-VE-001:Active] config bigpipe version
Kernel:
Linux 2.6.18-164.2.1.el5.1.0.f5app
Package:
BIG-IP Version 10.1.0 3341.1084
Final Edition
Thanks,
Carlos Covolo
1 Reply
- Hi
Not sure I have the answer ..but a here are a few thoughts
1) Looks like you are using the free trial version off the F5 website. This is a old code base, and it might be worth getting a 45 day eval key from you local F5 SE to test a v10.2.x, or v11.x version.
2) looking at the example of the SMTP proxy (https://devcentral.f5.com/wiki/iRules.SMTPProxy.ashx) ... maybe you need to re-evaluate your collect/release statements ?
The below , with a bit more logging may help ?
===============
when CLIENT_ACCEPTED {
log local0. "Client Connected !"
set client_closed 0
Extra logging to see where the collection is done
log local0. "TCP collect 0"
TCP::collect
}
periodically checks if the client connection closed, if so, also closes associated server connection.
when CLIENT_CLOSED {
set client_closed 1
}
Triggered when a connection has been established with the target node
when SERVER_CONNECTED {
after 1000 -periodic if {$client_closed} {TCP::close}
}
when CLIENT_DATA {
scan [TCP::payload] %c%c head rlen
log local0. "Client data"
log local0. "Header = $head -- Length = $rlen"
if {($head == 0)} {
if {[TCP::payload length] < [expr {2 + $rlen}]} {
allready collecting- commenting out the TCP collect statement
TCP::collect
return
}
}
log local0. "TCP release 1"
TCP::release
TCP::release [expr {$rlen + 2}]
TCP notify is not doing anything usefull in this irule
TCP::notify request
Extra logging to see where the collection is done
log local0. "TCP collect 1"
TCP::collect
}
