[OpenSIPS-Users] Load balancer probing from incorrect interface

Fri Nov 12 11:43:43 CET 2010

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
>

-- 
Bogdan-Andrei Iancu
OpenSIPS Bootcamp
15 - 19 November 2010, Edison, New Jersey, USA
www.voice-system.ro