Single subnet for management NIC and VoIP NIC

Configuring synchronization, sensors, and optimizations
Post Reply
User avatar
CRM User
Posts: 175
Joined: Sun Nov 27, 2016 3:41 pm

Single subnet for management NIC and VoIP NIC

Post by CRM User » Sat Nov 16, 2019 12:46 am

Due to some technical limitations we can only have a single NIC and single subnet (IP range) for both management and VoIP NIC's. And we want HAAst to move a 3'rd IP address (on this subnet) between peers when control fails over from one node to the other. How do we do this?
Account for questions transferred from CRM system
User avatar
Telium Support
Posts: 235
Joined: Sun Nov 27, 2016 3:27 pm

Re: Single subnet for management NIC and VoIP NIC

Post by Telium Support » Sat Nov 16, 2019 12:59 am

I should start by saying that we don't officially support this design because some of the steps involved are beyond the skill of an average administrator.

If you are very comfortable with networking, iptables, and routing then the answer is YES this can be done. (But our support team cannot assist you further with this topic).

Suppose you have
  • one NIC in each node
  • a single subnet 192.168.1.0/24 (i.e. 255.255.255.0 subnet) used by each NIC
  • Node A uses 192.168.1.1, and Node B uses 192.168.1.2
and you wish to have HAAst add 192.168.1.3 to the active node (while leaving the management IP accessible). The steps to do so are:
  • Setup the OS to assign the static address 192.168.1.1 and 192.168.1.2 to their respective nodes
  • Setup haast.conf to enable the VoIP NIC feature, and tell HAAst to use 192.168.1.3 as the shared IP
  • Setup the HAAst pre-start event handler to add the following postrouting rules in the NAT chain to source-NAT all outgoing voice traffic (5060 + RTP ports) as the shared IP:
    iptables -A POSTROUTING -t nat -p udp --dport 5060 -j SNAT --to-source 192.168.1.3
    iptables -A POSTROUTING -t nat -p udp --dport 10000:32768 -j SNAT --to-source 192.168.1.3
  • Setup the HAAst post-stop event handler to remove the above rules.

The end result will be that all voice related traffic will have their headers rewritten to show 192.168.1.3 instead of 192.168.1.1 (or 192.168.1.2). Depending on the VoIP protocols you use, TCP vs UDP selection, and other socket services you offer you may have to expand on or customize these rules. But the above should be sufficient to show how to accomplish what you want.
Post Reply