Re: [OpenSIPS-Users] Load balancer probing from incorrect interface
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.205.11 probe-external And on machine B I put: 10.0.10.2 probe-internal 66.180.205.12 probe-external So when opensips fails over from A to B, it picks up the new probing-IP from the hosts file. Then the probes from the default IP as selected by the kernel routing table work correctly, as they are coming from a port other than 5060. Hope this helps, Bill On 11/24/10 6:10 AM, Bogdan-Andrei Iancu wrote: 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 IP, then source IP address selection fails. The challenge is that my instance of opensips is an HA service between two machines, so I cannot simply specify IPs to listen on in opensips.cfg because the source IPs I need to probe from will change depending on which machine opensips is running on. That is not possible - you cannot change at runtime the interfaces opensips works with - you cannot make it to listen on a newly added interface, you cannot make it stop using an already configured interface. Each time you change the interfaces on the server, if you need to restart opensips. It looks like the solution to make this work with the existing get_out_socket code is to be able to specify interface aliases in the listen= directive. If I could do something like this: listen=udp:eth0:5090# for probing eth0 IP alias listen=udp:eth0.0:5090# for probing eth0:0 IP alias listen=udp:eth1.1:5090# for probing eth1:1 IP alias Then opensips could pick the appropriate IP from the interface/alias on the machine where it is running. If that's too complex, then the brute-force method would be to allow this: listen=udp:*:5090# for probing to be honest, never tried something like that - let me know if it works for you Regards, Bogdan I can't simply use the port= directive because I've got other services running on 5060. Thoughts? Thanks! Bill On 11/12/10 8:27 PM, 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 ___ 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
Re: [OpenSIPS-Users] Load balancer probing from incorrect interface
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?
Re: [OpenSIPS-Users] Load balancer probing from incorrect interface
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 IP, then source IP address selection fails. The challenge is that my instance of opensips is an HA service between two machines, so I cannot simply specify IPs to listen on in opensips.cfg because the source IPs I need to probe from will change depending on which machine opensips is running on. That is not possible - you cannot change at runtime the interfaces opensips works with - you cannot make it to listen on a newly added interface, you cannot make it stop using an already configured interface. Each time you change the interfaces on the server, if you need to restart opensips. It looks like the solution to make this work with the existing get_out_socket code is to be able to specify interface aliases in the listen= directive. If I could do something like this: listen=udp:eth0:5090# for probing eth0 IP alias listen=udp:eth0.0:5090 # for probing eth0:0 IP alias listen=udp:eth1.1:5090 # for probing eth1:1 IP alias Then opensips could pick the appropriate IP from the interface/alias on the machine where it is running. If that's too complex, then the brute-force method would be to allow this: listen=udp:*:5090 # for probing to be honest, never tried something like that - let me know if it works for you Regards, Bogdan I can't simply use the port= directive because I've got other services running on 5060. Thoughts? Thanks! Bill On 11/12/10 8:27 PM, 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 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu OpenSIPS Bootcamp www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Load balancer probing from incorrect interface
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 IP address selection fails. The challenge is that my instance of opensips is an HA service between two machines, so I cannot simply specify IPs to listen on in opensips.cfg because the source IPs I need to probe from will change depending on which machine opensips is running on. It looks like the solution to make this work with the existing get_out_socket code is to be able to specify interface aliases in the listen= directive. If I could do something like this: listen=udp:eth0:5090# for probing eth0 IP alias listen=udp:eth0.0:5090 # for probing eth0:0 IP alias listen=udp:eth1.1:5090 # for probing eth1:1 IP alias Then opensips could pick the appropriate IP from the interface/alias on the machine where it is running. If that's too complex, then the brute-force method would be to allow this: listen=udp:*:5090 # for probing I can't simply use the port= directive because I've got other services running on 5060. Thoughts? Thanks! Bill On 11/12/10 8:27 PM, 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 ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Load balancer probing from incorrect interface
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? Thanks, Bill ___ 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 -- Bogdan-Andrei Iancu OpenSIPS Bootcamp 15 - 19 November 2010, Edison, New Jersey, USA www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Load balancer probing from incorrect interface
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
Re: [OpenSIPS-Users] Load balancer probing from incorrect interface
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,
Re: [OpenSIPS-Users] Load balancer probing from incorrect interface
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?
--
Bogdan-Andrei Iancu
OpenSIPS Bootcamp
15 - 19 November 2010, Edison, New Jersey, USA
www.voice-system.ro
Index: forward.c
===
--- forward.c (revision 7362)
+++ forward.c (working copy)
@@ -166,7 +166,10 @@
}
su2ip_addr(ip, from);
si=find_si(ip, 0, proto);
- if (si==0) goto error;
+ if (si==0) {
+ LM_ERR(-- detected IP %s,proto=%d\n,ip_addr2a(ip),proto);
+ goto error;
+ }
close(temp_sock);
LM_DBG(socket determined: %p\n, si );
return si;
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Load balancer probing from incorrect interface
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
Re: [OpenSIPS-Users] Load balancer probing from incorrect interface
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? Thanks, Bill ___ 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
Re: [OpenSIPS-Users] Load balancer probing from incorrect interface
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? Thanks, Bill ___ 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 -- Bogdan-Andrei Iancu OpenSIPS Bootcamp 15 - 19 November 2010, Edison, New Jersey, USA www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Load balancer probing from incorrect interface
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? Thanks, Bill ___ 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
[OpenSIPS-Users] Load balancer probing from incorrect interface
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? Thanks, Bill ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Load balancer probing from incorrect interface
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? Thanks, Bill ___ 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
