[OpenSIPS-Users] Load balancer probing from incorrect interface

Wed Nov 24 12:06:33 CET 2010

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 cannot simply do 
like: detect .3 -> it is not used by opensips -> detect next one, .2 -> 
is used by opensips, let's go for it.

maybe switching on .3 on a different port 5070 will do th trick.

Regards,
Bogdan

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

-- 
Bogdan-Andrei Iancu
OpenSIPS Bootcamp
www.voice-system.ro