Reselecting route peer in MRF
Does anyone know how to get the router in MRF to reselect a new peer? I have MRF working for a custom protocol, and can either have it round robin the mesasges between peers, or always send messages to a particular peer (until it fails). However, what I'd like to get to is at some point be able to tell the router to reselect the peer to use. The only time I seem to be able to get it to do a reselect properly is when a peer is taken down and the MR_FAILED event is triggered wherein I call MR::message nexthop none MR::retry I suspect I need to delete the route entry that is currently configured, however doing anything with GENERICMESSAGE::route delete doesn't seem to make much difference (within MR_INGRESS) Wondering if anyone has done something similar with using MRF and can point me in the right direction?Creating a disconnect message to send through MRF
I'm working through a MRF setup and one of the cases I'm trying to implement is sending a disconnect message down to the pool members when a connection disconnects from the vhost. There are similar connect and data messages which are sent to pool members when a client connects or sends data to the vhost - this is working fine. When trying to send the message through MRF, during CLIENT_CLOSED, seems to drop the message with the following logged in ltm; Pending rule (null) aborted for 1.2.3.6:54127 -> 1.2.6.5:33200 The message is created in the CLIENT_CLOSED event as; GENERICMESSAGE::message create "DISCONNECTED:$my_host" my_dest As a workaround to it not finishing processing the irule for the message, I tried using a sideband connection and send in the message that way to a separate vhost (for different irule setup, linked to the same MRF router). This mostly works, except it has some strange side effects at the moment. Anyone know how to get a message to pass through from a CLIENT_CLOSED event? or have the sideband connection work without affecting other connections?
Load balancing SMPP authentication with MRF and no iRules. Can it be done?
Hi DevCentral, I will be honest, I do not completely understand how SMPP works, and the full requirements, but of all the configurations required this is the one that's throwing me for a loop. The scenario is as follows; When an external client initiates a connection to the VS, they are required to authenticate to two servers located in two differing subnets. The LTMs must traverse other gateways to reach these subnets. The requirements are to allow the connecting client to authenticate to both servers and any subsequent messages are load balanced to either of the servers, and if possible persist to only one based on the client/source. If the server fails, the pool will reselect and direct the connection to the available member. If the authenticated session fails, or the client closes the connection, they will re-authenticate to both servers and then load balancing can take place as before. I have looked at an iRule example by Dev member NAT, and trying to understand it at the moment. Some of it I get but the majority still escapes me, and I'm currently watching a TCL crash course to try and understand further. Referencing this post, from Dev user Sam, showing the SMPP message flow, which seems similar to Diameter, and from this I have been looking at MRF to possibly circumvent the iRules, limiting the complexity for future modifications. I have not begun configuring the SMPP services as yet, focusing on other configurations required prior to undertaking this one which seems mentally as a challenge. The HA pair LTMs are currently running version 12.0.0 1.0.0.628. My questions are; Is it possible to undertake this task without using iRules? and if so, any suggestions/tips for the configuration? Based on the message flow, is MRF viable for this solution? If iRules are required for the requirements, can the iRule example (from above) be used to satisfy this requirement? I would appreciate any assistance regarding the above, and also, feel free to ask for any information which can hopefully aid in a resolution. Best regards, T33