Forum Discussion
Balancing SMPP traffic based on recipient address
we have an application sending SMS via SMPP and we need to balance the SMS messages based on recipient address to 2 different SMS Centres. SMS with recipient address starting 420 should go to SMSC1 and the rest of SMS's should go to SMSC2. Note that application creates one TCP session and throught this session sends multiple SMS, one SMS is in one TCP packet or more SMS can be placed in one TCP packet.
Thanks
- Pavel_70776NimbostratusHi Nat,
- Nat_ThirasuttakornEmployeeHi Pavel,
- Kiran_Reddy_382NimbostratusHi Nat,
- Nat_ThirasuttakornEmployeeHi Kiran,
- Nat_ThirasuttakornEmployeeHi Kiran,
- Hamdi_Fersi_350Nimbostratus
Hi, I see that the topic is quite old, but it's really saving my day, so thanks. Then I got one more question. I could understand from the iRule shared here, that you are balancing based on recipient address, and that's great, but what happens if the ESME opens only one TCP session towards the BigIP? I mean for my case here, I have 2 SMSCs, and 1 ESME, the iRule balance the traffic towards the 2. But the BIND had been done only once towards one of the SMSCs. What is happening is that, when the second SMSC receives the Submit, it shows, "Invalid Bind status", and that's normal because there is no bind done towards the second SMSC. So my question here is that I'm wondering if there is a way, that when the BIND comes to the LB, it clones it towards the 2 SMSCs. If not, I would need some help to make one ESME open only one BIND towards each SMSC (kind of persistance but on 2 servers not only one). Thanks alot for your help ! Best Regards
- Nat_ThirasuttakornEmployee
Hi Hamdi Fersi,
This iRules should replicate the bind... this part of code should do that
when SERVER_CONNECTED { if { $first_bind_resp } { TCP::collect } else { TCP::collect -all TCP::respond $bind_message } }
one thing to note, the very first iRules expect bind_transmitter (hex 0x00000002) in your case, it could be bind_transceiver (hex 0x00000009)?
anyway, this part of code record the bind message. you could change it from
switch -glob $oper { 00000002 { set bind_message [TCP::payload $len] }
to
switch -glob $oper { 00000002 - 00000009 { set bind_message [TCP::payload $len] }
so it will record the message for both type of bind
Nat
- Hamdi_Fersi_350Nimbostratus
Thanks Nat for your quick feedback. after testing that, I succeeded to get binded in one SMSC. but i never could be bound in both of them (with only one BIND request from the ESME). Do I need a second request from the ESME? The ELSE part of the SERVER_CONNECTED event is never reached. Thanks, BR//
- Nat_ThirasuttakornEmployee
yes, in this iRule, it relies on second request from ESME in order to open connection to more server.
we can use trick like adding enquire_link into TCP::payload on CLIENT_DATA it will then be balanced to 2nd server and trigger the bind replay. however, doing this way, we may make sure we drop matching enquire_link_resp coming back from server
Nat
- Hamdi_Fersi_350Nimbostratus
Fixed ! I was sending the traffic to only one SMSC: 8* { rewrite seq if { [info exists s_seq_map($seq)] } { set old_seq [lindex $s_seq_map($seq) 0] TCP::payload replace 12 4 [binary format I $s_seq_idx] set addr [lindex $s_seq_map($seq) 1] set port [lindex $s_seq_map($seq) 2] use pool or node command pool [LB::server pool] member $addr $port unset s_seq_map($seq) } }
The thing here is that it's being replicated, but only after ~30seconds (after some Enquire_Link requests received). Thanks again for your help. BR//
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com