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 <[email protected]>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 > <[email protected]>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 >> [email protected]http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
