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 packet on the automatically selected IP but since port 5060 is occupied on that address, the socket is failing?

If so, is it possible to specify a different source port so the packet will go out?


Thanks,
Bill



On 11/12/2010 5:43 AM, Bogdan-Andrei Iancu wrote:
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 your case, if 10.0.10.2 and 10.0.10.3 doing the same, but 10.0.10.3
is used by default by kernel for reaching 10.0.10.xx network, simply use
10.0.10.3 for opensips also.

Regards,
Bogdan

Bill W wrote:
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 all because it's trying to bind to an IP that doesn't
belong to opensips.

For example:
DBG:tm:t_uac: next_hop=<sip:10.0.10.1>
DBG:core:mk_proxy: doing DNS lookup...
ERROR:core:get_out_socket: -- detected IP 10.0.10.2,proto=1
ERROR:tm:uri2sock: no corresponding socket for af 2
ERROR:tm:t_uac: no socket found
ERROR:load_balancer:lb_do_probing: probing failed

10.0.10.1 is on another machine
10.0.10.2 is on this machine
10.0.10.3 is on this machine, and allocated to opensips via listen=

Opensips should be binding to 10.0.1.3 which is specified in the
listen= directive, not 10.0.10.2, which is another IP on the box but
is not allocated to opensips.

Summary:
With mhomed=1 opensips is detecting the correct interface to ping
from, but it is selecting an IP on that interface that is not
specified in the listen= directives.

Hopefully I explained the behavior clearly.

Thanks,
Bill.





On 11/11/2010 11:39 AM, Bogdan-Andrei Iancu wrote:
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 look sane to me :)

Regards,
Bogdan

Bill W wrote:
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 <freeswitch:5060>
eth0:0 66.180.205.3 <opensips:5060>

DBG:tm:t_uac: next_hop=<sip:66.180.205.11>
DBG:core:mk_proxy: doing DNS lookup...
ERROR:core:get_out_socket: -- detected IP 66.180.205.11,proto=1
ERROR:core:get_out_socket: no socket found
ERROR:tm:uri2sock: no corresponding socket for af 2
ERROR:tm:t_uac: no socket found
ERROR:load_balancer:lb_do_probing: probing failed

It's not getting the IP from the listen= directive but from an
interface probe, which is getting the wrong IP.


On 11/11/2010 6:29 AM, Bogdan-Andrei Iancu wrote:
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 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/10/2010 5:38 AM, Bogdan-Andrei Iancu wrote:
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: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 11/8/2010 6:05 AM, Bogdan-Andrei Iancu wrote:
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= 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 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:
id | group_id | dst_uri | probe_mode
----+----------+-------------------+------------
1 | 1 | sip:66.180.205.11 | 2
2 | 1 | sip:66.180.205.12 | 2
3 | 2 | sip:10.0.10.1 | 2
4 | 2 | sip:10.0.10.2 | 2


What's happening is that the load balancer is trying to probe
the
public
IPs from the private interface IP (and failing of course).

tcpdump output on internal interface:
18:13:26.471734 IP 10.0.10.3.5060> 66.180.205.11.5060: SIP,
length:
18:13:28.473802 IP 10.0.10.3.5060> 66.180.205.11.5060: SIP,
length:


Thoughts?





_______________________________________________
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




_______________________________________________
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

Reply via email to