Not really. The LB module uses internal unique ids for all the LB
destinations it manages. So the probing replies will search back the LB
destination based on this ID -> no chance to mismatch.
Regards.
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
https://www.siphub.com
On 16.04.2024 10:45, Callum Guy via Users wrote:
If the backend servers are both the same instance then this seems to
be the correct behaviour?
I believe the probing is supposed to be a simple SIP response
healthcheck which applies to the destination globally (i.e. 1.2.3.4 is
offline), the groups are just a way of splitting up resources
logically for load balancing purposes.
On Tue, 16 Apr 2024 at 08:31, Bogdan-Andrei Iancu
<bog...@opensips.org> wrote:
Hi,
What OpenSIPS version you have? And as I understand, as
configuration, you do permanent probing to the destinations and
the disabling happens because of this probing ?
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
https://www.siphub.com
On 12.04.2024 05:41, Alexander Perkins wrote:
Hi. I have an interesting issue. We have two OpenSIPS servers
with load balancer (with two different group IDs in the lb table)
and we have probing set correctly and we are using the
event, E_LOAD_BALANCER_STATUS, to capture changes to servers that
were probed. But we noticed that we have the same server URI
listed in the lb table, but with two different group IDs, if one
of the OpenSIPS servers probes that URI and it does not return,
then lb disables both groups. I'd expect it to only disable one
group.
My question is how can we tell the LB module to disable the IP,
but also look for the groupID. For example, I have a printout of
lb_list below.
"uri": "sip:1.2.3.4:5060 <http://1.2.3.4:5060>", "id": 27,
"group": 12,"enabled": "no", "auto-reenable": "on", "Resources":
[ { "name": "vz12", "max": 600, "load": 0 } ], "attrs": "0"
AND
{ "uri": "sip:1.2.3.4:5060 <http://1.2.3.4:5060>", "id": 29,
"group": 13,"enabled": "no", "auto-reenable": "on", "Resources":
[ { "name": "vz13", "max": 600, "load": 0 } ], "attrs": "0" },
Thank you,
Alex
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
*^0333 332 0000 | x-on.co.uk <https://www.x-on.co.uk> | **^ |
**^Practice Index Reviews <https://practiceindex.co.uk/gp/x-on> *
*Our new office address: 22 Riduna Park, Melton IP12 1QT.*
X-on is a trading name of X-on Health Ltd a limited company registered
in England and Wales.
Registered Office : Glebe Farm, Down Street, Dummer, Basingstoke,
Hampshire, England RG25 2AD. Company Registration No. 2578478.
The information in this e-mail is confidential and for use by the
addressee(s) only. If you are not the intended recipient, please
notify X-on immediately on +44(0)333 332 0000 and delete the
message from your computer. If you are not a named addressee you must
not use, disclose, disseminate, distribute, copy, print or reply to
this email. Views or opinions expressed by an individual
within this email may not necessarily reflect the views of X-on or its
associated companies. Although X-on routinely screens for viruses,
addressees should scan this email and any attachments
for viruses. X-on makes no representation or warranty as to the
absence of viruses in this email or any attachments.
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
