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.
Networks are defined in the
For each subnet, define the following parameters:
cidr: The subnet mask in CIDR notation, for example
172.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 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
which specifies a list of DNS server IP addresses.
Said DNS server addresses must be reachable from the management subnet.
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.
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
identifierof a subnet defined in the
site-parameterssection as described above.
ip: A list of IP addresses, in the same order as the
instancesthat will be assigned those IP addresses. Note that while, in general, the SDF supports various formats for specifying IP addresses, for RVT VMs the
iplist 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
the next VM (
vm02) is assigned
172.18.0.12, and so on.
vnfcs: - name: tsn 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 ...
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.
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.