[OpenSIPS-Users] OpenSIPS mhomed=yes and shared IP address using corosync

[Remco .]

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.

Regards,
Remco.





On Mon, Nov 4, 2013 at 12:28 PM, Bogdan-Andrei Iancu <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.
>
> Regards,
>
> Bogdan-Andrei Iancu
> OpenSIPS Founder and Developerhttp://www.opensips-solutions.com
>
>
> 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.
>
> Thanks,
>
>  Remco.
>
>
> On Fri, Nov 1, 2013 at 12:27 PM, Bogdan-Andrei Iancu <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 Developerhttp://www.opensips-solutions.com
>>
>>
>> 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
>>
>>  1.1.1.1 = VIP on eth0
>>  2.2.2.2 = 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 2.2.2.2 but it
>> uses 1.1.1.1 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).
>>
>>  Thanks,
>>  Remco.
>>
>>
>> _______________________________________________
>> Users mailing listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20131108/2f76a3c2/attachment.htm>