[OpenSIPS-Users] OpenSIPS mhomed=yes and shared IP address using corosync
bogdan at opensips.org
Tue Nov 12 17:32:31 CET 2013
Perfect, thanks for the update. Anyhow, I already started the work on
the drouting and load-balancing module to allow you to set a certain
interface for interacting with each destination/gateway.
OpenSIPS Founder and Developer
On 11/08/2013 01:15 PM, Remco . wrote:
> Hi Bogdan,
> The proposed solution works. Instead of modifying IPaddr2 is opted to
> go for IPsrcaddr (also included as resource agent with corosync /
> linux HA stack). This agent ensures the correct source IP address is
> used for the default route. For the other subnet / interface, I
> removed the static IP addresses for both nodes and only installed a
> floating IP address. This can be enabled by setting
> /proc/sys//net///ipv4///conf///all///promote_secondaries to 1.
> This allows the kernel to choose the correct IP address for binding
> opensips, and still have a default route. mhomed=yes works like
> expected in this scenario.
> On Mon, Nov 4, 2013 at 12:28 PM, Bogdan-Andrei Iancu
> <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
> Hi Remco,
> OK, if your approach does not work, keep in mind you can still use
> local_route to change the outbound socket for the probing OPTIONs.
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developer
> On 11/02/2013 02:50 PM, Remco . wrote:
>> Hi Bogdan,
>> Thanks for your reply. The feature of setting the probe interface
>> for DR would be great. In the meantime, I studied the exact
>> behavior of the IPaddr2 resource agent a bit more. It turns out
>> it uses iproute2 to bind the address. The VIP is added as a
>> secondary IP address to the interface - no wonder the kernel
>> picks the primary. I will see if I can modify the resource agent
>> a bit so it will add the VIP as the primary IP (swap the IP
>> addresses round). That way, the mhomed=yes option will work. I
>> will report back my findings.
>> On Fri, Nov 1, 2013 at 12:27 PM, Bogdan-Andrei Iancu
>> <bogdan at opensips.org <mailto:bogdan at opensips.org>> wrote:
>> Hello Remco,
>> In mhomed, yes you let the kernel to pick the source IP based
>> on the routing table - so this approach delegate the logic
>> from OpenSIPS to the kernel. And it is up to ho well the
>> network part is set.
>> In the future I would like to add to the DR module the
>> possibility to set the probing interface (as you have now in
>> the dispatcher module). For now, what you can do is to use
>> the local_route to catch the DR pings and use
>> force_send_socket() to change the outgoing interface.
>> Best regards,
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> On 11/01/2013 10:39 AM, Remco . wrote:
>>> Hi all,
>>> I have a clustered OpenSIPS setup (using corosync with a
>>> virtual IP address). This has been working great over the
>>> last couple of years. I now want to add an extra IP address
>>> to the boxes, again floating a VIP over these interfaces.
>>> These interfaces will be used to communicate with PSTN
>>> gateways. I noticed however upon enabling these interfaces,
>>> the drouting module starts to ping the gateways using the
>>> wrong source address, i.e
>>> 18.104.22.168 = VIP on eth0
>>> 22.214.171.124 = VIP on eth1
>>> OpenSIPS is configured to listen on the the two VIPs with a
>>> listen directive.
>>> According to the kernel's routing table, it should use
>>> 126.96.36.199 but it uses 188.8.131.52 which results in failure. As I
>>> understood, mhomed=yes should achieve just this behavior by
>>> asking the kernel for the appropriate source address on
>>> sending out a packet. However, when I enable the mhomed
>>> option, OpenSIPS starts to complain about not having a
>>> socket to send out the packets. I assume this is caused by
>>> the kernel returning the real IP from the interfaces (first)
>>> instead of the VIPs.
>>> Just because of the dynamic nature of the interface
>>> selection, I won't be able to use force_send_socket().
>>> I know this question has come up on the list on several
>>> occasions, but nothing recent and I was still wondering if
>>> someone has a workaround or solution for this. I can imagine
>>> when using OpenSIPS as a load-balancer with two interfaces
>>> (in and out) you might encounter this problem as well if you
>>> try to add high availability (in which you often cannot
>>> avoid the Virtual IP scenario).
>>> Users mailing list
>>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Users