Thanks for the tips. But wouldn’t that be considered by the load balancer a
successful connection since there was an ACK to the SYN in order to send
the 503 data? Or does that work for you because you’re relying on the
client to retry and the load balancer sending to a different server?

Regards,

David Villasmil
email: david.villasmil.w...@gmail.com
phone: +34669448337


On Tue, 6 Feb 2024 at 13:45, Sebastian Damm <sd...@pascom.net> wrote:

> We usually already have a high enough number of max tcp connections.
> However, there are certain scenarios when restarting some of our servers
> the loadbalancer sends all the clients previously connected to these
> servers to the remaining ones, leading to really full and really empty
> nodes. And sometimes we see Kamailio rejecting connections, and sometimes
> maybe the client can still connect, but the outgoing connection to the next
> hop is not possible anymore.
>
> But maybe you're right. Manually dropping the connection would probably
> not be any better than what Kamailio does after really reaching the limit.
>
> We have already implemented the maintenance mode draining, this would work
> as follows:
>
> Add a shared var named "MAINTENANCE_MODE", set it to 0 in config. Then,
> when handling the REGISTER, add something like this:
>         if msg.is_method("REGISTER"):
>             if KSR.pv.get("$shv(MAINTENANCE_MODE)") == 1:
>                 msg.log("In maintenance mode, rejecting registration")
>                 KSR.set_reply_close()
>                 KSR.hdr.append_to_reply("Retry-After: 3\r\n")
>                 KSR.sl.sl_send_reply(503, "Draining")
>                 return False
>
> You can set the value of the shared var to 1 via kamcmd. After that, on
> the next re-registration, the client will be disconnected, ending up
> hopefully on a different node after reconnect.
>
> Regards,
> Sebastian
>
>
> ------------------------------
> *From:* David Villasmil <david.villasmil.w...@gmail.com>
> *Sent:* Tuesday, February 6, 2024 13:11
> *To:* Kamailio (SER) - Users Mailing List <sr-users@lists.kamailio.org>
> *Cc:* Sebastian Damm <sd...@pascom.net>
> *Subject:* Re: [SR-Users] Get the amount of open TCP connection from
> routing logic
>
> Why not just increase the max tcp connections? Also, once you hit it,
> Kamailio will reset the syn and the load balancer should try on a different
> server.
>
> I am look for something like what you’re looking for but reset the sub
> on-demand so I can put the server in maintenance mode.
>
> Regards,
>
> David Villasmil
> email: david.villasmil.w...@gmail.com
> phone: +34669448337
>
>
> On Tue, 6 Feb 2024 at 12:47, Sebastian Damm via sr-users <
> sr-users@lists.kamailio.org> wrote:
>
> Hello,
>
> My plan is to reject new inbound requests if there is already a
> certain number of open connections on one Kamailio server. I could answer
> with a 503 and directly close the connection forcing the client to
> reconnect and the loadbalancer to send traffic to a different node on the
> next connect. It's just a last-resort measure to prevent Kamailio from
> running into the configured TCP connection limit (workarounding a
> poorly-implemented external load balancer).
>
> Since I didn't find anything in the docs: Is there a pseudovariable
> containing the current number of open tcp/tls connections on this Kamailio?
> I can (and already do) query them via kamcmd or rpc, but can I access the
> variable from inside the routing script as well?
>
> Regards,
> Sebastian
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions
> To unsubscribe send an email to sr-users-le...@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>
>
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
To unsubscribe send an email to sr-users-le...@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:

Reply via email to