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 example172.16.0.0/24. 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 examplemanagement. 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).
As a security measure, we recommend that you 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
routing-config.yaml
to instruct the VMs' software to route traffic to certain destinations via a specified subnet/NIC.
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 subnetidentifierof a subnet defined in thesite-parameterssection as described above. -
ip-addresses:-
ip: A list of IP addresses, in the same order as theinstancesthat will be assigned those IP addresses. Note that while, in general, the SDF supports various formats for specifying IP addresses, for custom VMs theiplist form must be used.
-
-
traffic-types: A list of traffic types to be carried on this subnet.
Examples
Example 1
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 172.16.0.11 for management traffic
and 172.18.0.11 for sip and internal traffic,
the next VM (vm02) is assigned 172.16.0.12 and 172.18.0.12, and so on.
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.
vnfcs:
- name: custom
cluster-configuration:
count: 3
instances:
- name: vm01
- name: vm02
- name: vm03
networks:
- name: Management network
ip-addresses:
ip:
- 172.16.0.11
- 172.16.0.12
- 172.16.0.13
subnet: management-subnet
traffic-types:
- management
- name: Core Signaling network
ip-addresses:
ip:
- 172.18.0.11
- 172.18.0.12
- 172.18.0.13
subnet: core-signaling-subnet
traffic-types:
- sip
- internal
...Example 2
The following example shows a partial service group definition, describing three VMs with IPs allocated on three subnets - one for management traffic, one for cluster traffic, and one for Diameter & 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 172.16.0.11 for management traffic,
172.17.0.11 for cluster traffic etc.;
the next VM (vm02) will be assigned 172.16.0.12, 172.17.0.12 etc; and so on.
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.
vnfcs:
- name: custom
cluster-configuration:
count: 3
instances:
- name: vm01
- name: vm02
- name: vm03
networks:
- name: Management network
ip-addresses:
ip:
- 172.16.0.11
- 172.16.0.12
- 172.16.0.13
subnet: management-subnet
traffic-types:
- management
- name: Cluster
ip-addresses:
ip:
- 172.17.0.11
- 172.17.0.12
- 172.17.0.13
subnet: cluster
traffic-types:
- cluster
- name: Core Signaling network
ip-addresses:
ip:
- 172.18.0.11
- 172.18.0.12
- 172.18.0.13
subnet: core-signaling-subnet
traffic-types:
- diameter
- internal
...Traffic type assignment restrictions
For all custom service groups in a site, where two or more service groups use a particular traffic type, this traffic type must be assigned to the same subnet throughout the site. For example, it is not permitted to use one subnet for management traffic on the custom VMs and a different subnet for management traffic on another VM type.
Within each site, the management and cluster traffic types must each be assigned to a different subnet.
