13. Network Configuration

13.1. General Structure
13.2. Available Host Options

Starting with version 2.7, the sip:provider PRO uses a dedicated network.yml file to configure the IP addresses of the system. The reason for this is to be able to access all IPs of all nodes for all services from any particular node in case of a distributed system on one hand, and in order to be able the generate /etc/network/interfaces automatically for all nodes based on this central configuration file.

13.1. General Structure

The basic structure of the file looks like this:

hosts:
  self:
    role:
      - proxy
      - lb
      - mgmt
    interfaces:
      - eth0
      - lo
    eth0:
      ip: 192.168.51.213
      netmask: 255.255.255.0
      type:
        - sip_ext
        - rtp_ext
        - web_ext
        - web_int
    lo:
      ip: 127.0.0.1
      netmask: 255.255.255.0
      type:
        - sip_int
        - ha_int

In PRO and Carrier deployments, all hosts of the system are defined, and the names are the actual host names instead of self, like this:

hosts:

  sp1:
    peer: sp2
    role: ...
    interfaces: ...

  sp2:
    peer: sp1
    role: ...
    interfaces: ...

13.2. Available Host Options

There are three different main sections for a host in the config file, which are role, interfaces and the actual interface definitions.

In PRO deployments, there is also a peer setting pointing to the second node of the pair.

role: The role setting is an array defining which logical roles a node will act as. Possible entries for this setting are:
- mgmt: This entry means the host is acting as management node for the platform. In a sip:provider PRO, this option must always been set. The management node exposes the admin and csc panels to the users and the APIs to external applications and is used to export CDRs.
- lb: This entry means the host is acting as SIP load-balancer for the platform. In a sip:provider PRO, this option must always been set. The SIP load-balancer acts as an ingress and egress point for all SIP traffic to and from the platform.
- proxy: This entry means the host is acting as SIP proxy for the platform. In a sip:provider PRO, this option must always been set. The SIP proxy acts as registrar, proxy and application server and media relay, and is responsible for providing the features for all subscribers provisioned on it.
peer: The peer setting points to the second node of the pair within the overall system. For example in sp1 the peer will always contain sp2 and vice versa in order for each node to know its companion node for providing high availability, data replication etc.
interfaces: The interfaces setting is an array defining all interface names in the system. The actual interface details are set in the actual interface settings below.
<interface name>: After the interfaces are defined in the interfaces setting, each of those interfaces needs to be specified as a separate setting with the following options:
- ip
- netmask
- shared_ip
- shared_v6ip
- advertised_ip
- type

There are different interface types, which define the services on a particular interface. For example the type ssh_ext set for a specific interface defines that the SSH daemon will listen on that interface for incoming connections. The list of possible types is as follows (note that you can assign a type only once per node):

ha_int: interface for HA communications between nodes sp1 and sp2 (for heartbeat checks, DB replication etc.)
mon_ext: interface for monitoring purposes, e.g. for snmpd
rtp_ext: interface for external RTP relay
sip_ext: interface for external SIP communication between the sip:provider PRO and the end points
sip_int: interface for internal SIP communication, e.g. between load-balancer, proxy and application servers
ssh_ext: interface for SSH remote login
web_ext: interface for the subscriber web panel and the subscriber’s SOAP/REST APIs
web_int: interface for the administrator web panel, his SOAP/REST APIs and internal API communication
aux_ext: interface for potentially insecure external components like rsyslogd service; e.g. the CloudPBX module can use those services to provide time services and remote logging facilities to end customer devices. The type aux_ext is assigned to lo interface by default. If it is needed to expose this type to the public, it is recommended to assign the type aux_ext to a separate VLAN interface to be able to limit or even block the incoming traffic easily via firewalling in case of emergency, like a (D)DOS attack on rsyslog services.