15. Network Configuration

15.1. General Structure
15.2. Available Host Options

Starting with version 2.7, the sip:provider CE 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.

15.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 CE systems, there is only one host entry in the file, and it’s always named self.

15.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.

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 CE, 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 CE, 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 CE, 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.
- db: This entry means the host is acting as the database node for the platform. In a sip:provider CE, this option must always be set. The database node exposes the mysql and redis databases.
- rtp: This entry means the host is acting as the RTP relay node for the platform. In a sip:provider CE, this option must always be set. The RTP relay node runs the rtpengine.
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
- 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):

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 CE and the end points
sip_ext_incoming: extra listen interface for external SIP traffic (optional)
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.