[OpenSIPS-Users] Load balancer probing from incorrect interface

Sat Nov 13 02:27:16 CET 2010

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 at lists.opensips.org
>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.opensips.org
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>
>>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>
>