The SDF defines subnets. Each subnet corresponds to a virtual NIC on the VMs, which in turn maps to a physical NIC on the VNFI. The mapping from subnets to VMs' vNICs is one-to-one, but the mapping from vNICs to physical NICs can be many-to-one.

A traffic scheme is a mapping of traffic types (such as management or SIP traffic) to these subnets. The list of traffic types required by each VM, and the possible traffic schemes, can be found in Traffic types and traffic schemes.

Defining subnets

Networks are defined in the site-parameters:networking:subnets section. For each subnet, define the following parameters:

  • cidr: The subnet mask in CIDR notation, for example All IP addresses assigned to the VMs must be congruent with the subnet mask.

  • default-gateway: The default gateway IP address. Must be congruent with the subnet mask.

  • identifier: A unique identifier for the subnet, for example management. This identifier is used when assigning traffic types to the subnet (see below).

  • vim-network: The name of the corresponding VNFI physical network, as configured on the VNFI.

The subnet that is to carry management traffic must include a dns-servers option, which specifies a list of DNS server IP addresses. Said DNS server addresses must be reachable from the management subnet.

Physical network requirements

Each physical network attached to the VNFI must be at least 100Mb/s Ethernet (1Gb/s or better is preferred). The networks must be IPv4 - for the RVT VMs, IPv6 is not supported.

As a security measure, it is recommended to set up network firewalls to prevent traffic flowing between subnets. Note however that the VMs' software will send traffic over a particular subnet only when the subnet includes the traffic’s destination IP address; if the destination IP address is not on any of the VM’s subnets, it will use the management subnet as a default route.

As such, you must configure routing rules in the YAML configuration to instruct the VMs' software to route traffic to certain destinations via a specified subnet/NIC. For example, where the SGC connects to an SS7 signaling gateway on a different subnet, you should configure a routing rule to route traffic to that gateway’s IP address(es) over the subnet that is assigned the ss7 traffic type.

If configuring routing rules for every destination is not possible, then an acceptable, but less secure, workaround is to firewall all interfaces except the management interface.

Allocating IP addresses and traffic types

Within each service group, define a networks section, which is a list of subnets on which the VMs in the service group will be assigned addresses. Define the following fields for each subnet:

  • name: A human-readable name for the subnet.

  • subnet: The subnet identifier of a subnet defined in the site-parameters section as described above.

  • ip-addresses:ip: A list of IP addresses, in the same order as the instances that will be assigned those IP addresses. Note that while, in general, the SDF supports various formats for specifying IP addresses, for RVT VMs the ip list form must be used.

  • traffic-types: A list of traffic types to be carried on this subnet.

The following example shows a partial service group definition, describing three VMs with IPs allocated on two subnets - one for management traffic, and one for SIP and internal signaling traffic. The order of the IP addresses on each subnet matches the order of the instances, so the first VM (vm01) will be assigned IP addresses for management traffic and for sip and internal traffic, the next VM (vm02) is assigned and, and so on.

  - name: tsn
      count: 3
      - name: vm01
      - name: vm02
      - name: vm03
      - name: Management network
        subnet: management-subnet
          - management
      - name: Core Signaling network
        subnet: core-signaling-subnet
          - sip
          - internal

Ensure that each VM in the service group has an IP address - i.e. each list of IP addresses must have the same number of elements as there are VM instances.

Traffic type assignment restrictions

For all RVT service groups in the SDF, where two or more service groups use a particular traffic type, this traffic type must be assigned to the same subnet throughout. For example, it is not permitted to use one subnet for management traffic on the TSN VMs and a different subnet for management traffic on another VM type.

The management, cluster and access traffic types must each be assigned to a different subnet.

Previous page Next page
Rhino VoLTE TAS VMs Version 4.0.0