Hey Bogdan,
Thanks so much for your help. For the benefit of the group, I
eventually came up with a work-around for this.
I use the following in opensips.cfg
listen=udp:probe-internal:5090
listen=udp:probe-external:5090
Then in the hosts file on machine A I put:
10.0.10.1 probe-internal
66.180.
Bill W. wrote:
Hello Bogdan,
Okay I've been researching this more. I am not a programmer, but it
looks like get_out_socket and find_si in forward.c and socket_info.c are
just comparing ip addresses, and when opensips is trying to probe an
interface on the same machine, but is not bound to that
Hi Bill,
hmm...that's a tough one as, again, the kernel, when routing to
destination 10.0.10.1 seas as alternatives both .2 and .3 local
interfaces, but for whatever reason (kernel specific), .3 is used
(default ? first configured?)...
And how the auto detection is done in opensips, you cann
Hello Bogdan,
Okay I've been researching this more. I am not a programmer, but it
looks like get_out_socket and find_si in forward.c and socket_info.c are
just comparing ip addresses, and when opensips is trying to probe an
interface on the same machine, but is not bound to that IP, then source
I
Hi Bill,
is your opensips actually listening (configured as listener in .cfg) on
a interface in the private network (where the probing needs to be done) ??
Regards,
Bogdan
Bill W wrote:
Hey Bogdan,
I enabled the mhomed=1 parameter, and now I'm getting a bunch of errors
in the logs.
ERROR
Hi Bogdan,
Thanks so much for explaining how interface selection works.
Unfortunately the other interfaces all have daemons listening on port
5060 and are in production and I can't simply reallocate IPs.
So for the error messages below, is the problem that opensips is trying
to send out a pa
Hi Bill,
I was strictly speaking about the mhomed=1 case. Opensips doing
detection (based on default IP routing rules from kernel) "sees" that it
should use first available interface (as returned by kernel)..it cannot
simply pick up all possible and see which one is also listening on.
in yo
Hey Bogdan,
I think we're confusing two issues.
The first issue was when mhomed=0, it was trying to options ping the
internal interface with an external IP, which clearly won't work, as you
described below.
The second issue is when I set mhomed=1, opensips is cannot options ping
anything at
It looks to me more like a misconfiguration on network level for the
machine ...Opensips tries to detect the interface with the default route
to the destination IP (the info id provided by kernel)..So if the kernel
"sees" 66.180.205.11 as default interface for reaching a private
IP.does loo
Ahhh, I see what's going on.
Opensips is trying to probe from a different IP on that interface
instead of the IP alias opensips bound to.
For example, on the public interface I have IP 66.180.205.11
Then I have an IP alias of 66.180.205.3 on that same interface:
eth0 66.180.205.11
eth0:0 66
Hi Bill,
could you try the attached patch along mhomed option? the patch will
simply print what is the IP opensips is trying to use for the outgoing
probes
Regards,
Bogdan
Bill W wrote:
Hey Bogdan,
Yes, I have 3 listen= lines; two with public IPs and one with a
private IP.
When I re
Hey Bogdan,
Yes, I have 3 listen= lines; two with public IPs and one with a private IP.
When I remove the mhomed=1 then things work as intended except for the
probing. I can proxy traffic correctly on all interfaces.
When I enable mhomed=1, then I get the errors below.
Thanks,
Bill
On 11/
Hey Bogdan,
I enabled the mhomed=1 parameter, and now I'm getting a bunch of errors
in the logs.
ERROR:tm:t_uac: no socket found
ERROR:load_balancer:lb_do_probing: probing failed
ERROR:core:get_out_socket: no socket found
ERROR:tm:uri2sock: no corresponding socket for af 2
Thoughts?
Bill
On
Hi Bill,
as you have a multi interface system, have you tried to enable the
"mhomed" global parameter?
http://www.opensips.org/Resources/DocsCoreFcn16#toc60
Regards,
Bogdan
Bill W. wrote:
> As an update, the load balancer probe appears to use the ip address
> specified by the first listen=
As an update, the load balancer probe appears to use the ip address
specified by the first listen= directive.
If I list the public IP first, then the probe tries to talk to the
internal IP from the external interface IP.
On 11/7/10 6:18 PM, Bill W. wrote:
> Hello everyone,
>
> I've got an opens
Hello everyone,
I've got an opensips-1.6.3-tls installation using multiple interfaces
and load balancing.
My internal interface is rfc1918 space and my external interface has
public IPs.
listen=udp:10.0.10.3:5060
listen=udp:66.180.205.3:5060
I have the following load_balancer configuration:
i
16 matches
Mail list logo
