Configuring VNFs on NFX350 Devices
The NFX350 devices enable you to instantiate and manage virtualized network functions (VNFs) from the Junos Control Plane (JCP). The JCP supports the creation and management of third-party VNFs.
Load a VNF Image
To configure a VNF, you must log in to the JCP:
user@host:~ # cliuser@host>
To load a VNF image on the device from a remote location, you can either use the
file-copy command or copy the image from a USB by using the
usb-pass-through command.
You can save the VNF image in the /var/public directory if you are using up to two VNFs. If you are using more than two VNFs, save the files on an external SSD. If you are using an external SSD for VNFs, make sure to initialize and add the SSD to the device. For more information, see Configuring the Solid State Disk on NFX350 Device.
user@host> file copy source-address /var/public For example:
user@host> file copy scp://192.0.2.0//tftpboot/centos.img /var/public Alternatively, you can load a VNF image by using the NETCONF
command, file-put.
To copy a VNF image from a USB, see Supporting File Transfer from USB on NFX Series Devices.
Prepare the Bootstrap Configuration
You can bootstrap a VNF by attaching a CD-ROM, a USB storage device, or a config drive that contains a bootstrap-config ISO file.
For an example of creating an ISO file, see the procedure in Creating a vSRX Bootstrap ISO Image. The procedure might differ based on the operating system (for example, Linux, Ubuntu) that you use to create the ISO file.
A bootstrap configuration file must contain an initial configuration that allows the VNF to be accessible from an external controller, and accepts SSH, HTTP, or HTTPS connections from an external controller for further runtime configurations.
The system saves the bootstrap-config ISO file in the /var/public folder. The file is saved only if the available space in the folder is more than double the total size of the contents in the file. If the available space in the folder is not sufficient, an error message is displayed when you commit the configuration.
When you reboot the system, the system generates a new bootstrap-config ISO file and replaces the existing ISO file with the new ISO file on the VNF.
Allocate CPUs for a VNF
Table 1 lists the CPUs available for VNF usage for the NFX350 models.
|
Model |
CPUs Available for VNF Usage |
||||
|---|---|---|---|---|---|
|
Throughput Mode |
Hybrid Mode |
Compute Mode |
Custom Mode |
||
|
Flex Mode |
Perf Mode |
||||
|
NFX350-S1 |
0 |
8 |
10 |
11 | 6 |
|
NFX350-S2 |
0 |
10 |
14 |
19 | 10 |
|
NFX350-S3 |
0 |
14 |
20 |
27 | 12 |
The resource allocations for flex and perf custom modes are based on the templates provided in the default Junos configuration.
When you change the performance mode of the device, it is recommended to check the availability of the CPUs for VNFs.
To check the CPU availability and its status:
user@host> show system visibility cpu CPU Statistics (Time in sec) ------------------------------------------------------------------------------- CPU Id User Time System Time Idle Time Nice Time IOWait Time Intr. Service Time ------ --------- ----------- --------- --------- ----------- ------------------ 0 7762 1475 60539 0 84 0 1 191 511 70218 0 10 0 2 102 32 70841 0 12 0 3 0 0 70999 0 0 0 4 0 0 70999 0 0 0 5 0 0 70999 0 0 0 6 70949 0 50 0 0 0 7 9005 532 59602 0 0 0 8 23 7 70966 0 0 0 9 21 7 70969 0 0 0 10 20 6 70969 0 0 0 11 18 6 70970 0 0 0 CPU Usages ---------------- CPU Id CPU Usage ------ --------- 0 17.899999999999999 1 0.0 2 0.0 3 0.0 4 0.0 5 0.0 6 100.0 7 15.199999999999999 8 0.0 9 0.0 10 0.0 11 0.0 CPU Pinning Information ------------------------------------ Virtual Machine vCPU CPU --------------------------- ---- --- vjunos0 0 0 System Component CPUs ------------------------------- -------- ovs-vswitchd 0, 6
user@host> show vmhost mode Starting network management services: snmpd libvirtMib_subagent. Synchronizing UEFI key-store: Failed to get revocation list: 2 Juniper Dev keys are not revoked. Doing nothing cp: cannot stat '/var/platform/lte_vm_xml_params': No such file or directory rm: cannot remove '/lib/udev/rules.d/lte_usb.rules': No such file or directory Mode: -------- Current Mode: compute CPU Allocations: Name Configured Used ---------------------------------------------------------------------------------------------------------------------- Junos Control Plane 8 3,8 Juniper Device Manager 8 8 LTE 8 - NFV Backplane Control Path 8 8 NFV Backplane Data Path 1 1 Layer 2 Control Path - - Layer 2 Data Path - - Layer 3 Control Path 0 0 Layer 3 Data Path 2 2 CPUs available for VNFs 3,4,5,6,7,11,12,13,14,15 - CPUs turned off 9,10 - Memory Allocations: Name Configured Used ---------------------------------------------------------------------------------------------------------------------- Junos Control Plane (mB) 2048 2011 NFV Backplane 1G hugepages 4 8 NFV Backplane 2M hugepages - 0 Layer 2 1G hugepages - - Layer 2 2M hugepages - - Layer 3 1G hugepages 4 4 Layer 3 2M hugepages 5633 5377
The CPUs available for VNFs section
in the output message shows the CPUs that are available to onboard
VNFs.
vjunos0 is a system VNF, you cannot modify the CPU allocation for the vjunos0.
To specify the number of virtual CPUs that are required for a VNF:
The physical CPU number can be either a number or a number range. By default, a VNF is allocated one virtual CPU that is not connected to any physical CPU.
You cannot change the CPU configuration of a VNF while the VNF is running. You must restart the VNF for the changes to take effect.
Starting in Junos OS Release 22.1 R1, you can pin the emulator to specific physical CPUs by using the following command:
user@host# set virtual-network-functions vnf-name emulator physical-cpu cpu-range
You cannot use CPU 0 or offline CPUs for emulator pinning. If you do not pin the emulator to a specific physical CPU, QEMU automatically pins it to a virtual CPU. Changes to emulator pinning take effect immediately on a running VNF.
To enable hardware virtualization or hardware acceleration for VNF CPUs:
user@host# set virtual-network-functions vnf-name virtual-cpu features hardware-virtualization
Allocate Memory for a VNF
By default, a certain amount of memory is allocated for VNFs. Table 2 lists the possible memory availability for VNF usage for the NFX350 models.
|
Model |
Total Memory Available |
Hugepages Availability for VNF Usage in Compute, Hybrid, and Throughput Modes |
Hugepages Availability for VNF Usage in Custom Mode |
|
|---|---|---|---|---|
|
Flex Mode |
Perf Mode |
|||
|
NFX350-S1 |
32 GB |
7 1G hugepages |
24 1G hugepages |
22 1G hugepages |
|
NFX350-S2 |
64 GB |
23 1G hugepages |
50 1G hugepages |
49 1G hugepages |
|
NFX350-S3 |
128 GB |
62 1G hugepages |
110 1G hugepages |
108 1G hugepages |
The resource allocations for flex and perf custom modes are based on the templates provided in the default Junos configuration.
To check the available memory:
user@host> show system visibility memory
Memory Information
------------------
Virtual Memory:
---------------
Total (KiB): 15914364
Used (KiB): 13179424
Available (KiB): 3087076
Free (KiB): 2734940
Percent Used : 80.6
Huge Pages:
------------
Total 1GiB Huge Pages: 7
Free 1GiB Huge Pages: 5
Configured 1GiB Huge Pages: 5
Total 2MiB Huge Pages: 1376
Free 2MiB Huge Pages: 1
Configured 2MiB Huge Pages: 0
Hugepages Usage:
----------------------------------------------------------------------------------------------------------
Name Type Used 1G Hugepages Used 2M Hugepages
--------------------------------- ---------------------------------- ------------------ ------------------
srxpfe other process 1 1375
ovs-vswitchd other process 2 0vjunos0 is a system VNF, you cannot modify the memory allocation for the vjunos0.
To specify the maximum primary memory that the VNF can use:
user@host# set virtual-network-functions vnf-name memory size size
You cannot change the memory configuration of a VNF while the VNF is running. You must restart the VNF for the changes to take effect.
Configure Interfaces and VLANs for a VNF
You can configure a VNF interface, map a VNF interface to a virtual function, and attach the interface to a physical NIC port, a management interface, or VLANs, assign a VLAN ID to it, and enable trust mode on it.
Prior to Junos OS Releases 21.3R1, 21.2R2, 21.2R1, 21.1R2, and 20.4R3, the step to configure an SR-IOV VNF interface and to assign a VLAN ID is as follows:
user@host# set virtual-network-functions vnf-name interfaces vnf-interface-name mapping interface physical-interface-name virtual-function vlan-id vlan-id
Starting from Junos OS Releases 21.3R1, 21.2R2, 21.2R1, 21.1R2, and 20.4R3, the steps to configure an SR-IOV VNF interface, to assign a VLAN ID, and to enable trust mode are as follows:
To map a VNF interface to a virtual function:
user@host# set virtual-network-functions vnf-name interfaces vnf-interface-name mapping interface physical-interface-name
To attach a VNF interface to a physical NIC port by using the SR-IOV virtual function and assign a VLAN ID:
user@host# set virtual-network-functions vnf-name interfaces vnf-interface-name mapping interface virtual-function vlan-id vlan-id
vlan-id is the VLAN ID of the port and is an optional value.
To enable trust mode:
user@host# set virtual-network-functions vnf-name interfaces vnf-interface-name mapping interface virtual-function trust
-
Trust mode is supported on NFX Series devices from Junos OS Releases 21.3R1, 21.2R2, 21.2R1, 21.1R2, and 20.4R3.
-
If you enable trust mode on VNF SR-IOV interface, then the VNF interface goes into promiscuous mode.
To disable spoof check
user@host# set virtual-network-functions vnf-name interfaces interface-name mapping interface virtual-function disable-spoof-check
To attach a VNF interface to a VLAN:
-
Create a VLAN:
user@host# set vmhost vlan vlan-name
-
Attach a VNF interface to a VLAN:
user@host# set virtual-network-functions vnf-name interfaces interface-name mapping vlan members list-of-vlans [mode trunk|access]
A VNF interface can be mapped to one or more physical interface .You can enable this functionality by configuring the virtual port peer (VPP) feature. You can configure mappings between an OVS interface of a VNF to one or more front panel interfaces. The VNF interface becomes inactive if all of the mapped physical interfaces are inactive. The VNF interface becomes active even if at least one of the mapped physical interface is active.
-
The mapped physical interface does not become inactive if a VNF interface is inactive.
-
Before upgrading a software image that does not support trust mode to an image that supports trust mode, it is recommended to delete all VNF interface to virtual-function mappings from the configuration.
-
Before downgrading a software image that supports trust mode to an image that does not support trust mode, it is necessary to delete all VNF interface to virtual-function mappings from the configuration. Else, the device goes into Amnesiac state after the downgrade.
The interface to the VNF is an OVS port and this mapping is defined in the configuration. If the mapping rules can view multiple physical ports before triggering the action, configuring the VPP feature allows you to manage multiple, redundant physical links.
You can configure a mapping between VNF virtual interfaces and JCP physical interfaces (ge-0/0/x and xe-0/0/x). One virtual interface can be mapped to one or more physical interfaces. There is no limit on the number of physical interfaces to which a VNF virtual interface can be mapped to. You can map a VNF virtual interface to all the physical interfaces or you can map multiple VNF interfaces to a single physical interface.
To configure VPP:
root@host# set virtual-network-functions vnf-name interfaces interface-name mapping peer-interfaces physical-interface-name
For example:
root@host# set virtual-network-functions centos1 interfaces eth2 mapping peer-interfaces ge-0/0/6
To view mapping of the peer interfaces, run the show system visibility
vnf vnf-name command.
-
The interfaces attached to a VNF are persistent across VNF restarts.
-
If the VNF supports hot-plugging, you can attach the interfaces while the VNF is running. Otherwise, you must add the interfaces, and then restart the VNF.
-
You cannot change the mapping of a VNF interface while the VNF is running.
You can prevent the VNF interface from sending or receiving traffic by using
the deny-forwarding CLI option.
If the deny-forwarding option is enabled on an interface
that is a part of cross-connect, then the cross-connect status goes down and
drops all traffic.
set virtual-network-options vnf-name interface interface-name forwarding-options deny-forwarding
To specify the target PCI address for a VNF interface:
user@host# set virtual-network-functions vnf-name interfaces interface-name pci-address target-pci-address
You can use the target PCI address to rename or reorganize interfaces within the VNF.
For example, a Linux-based VNF can use udev rules within the VNF to name the interface based on the PCI address.
-
The target PCI address string should be in the following format:
0000:00:<slot:>:0, which are the values for domain:bus:slot:function. The value for slot should be different for each VNF interface. The values for domain, bus, and function should be zero. -
You cannot change the target PCI address of VNF interface while the VNF is running.
To delete a VNF interface:
user@host# delete virtual-network-functions vnf-name interfaces interface-name user@host# commit
-
To delete a VNF interface, you must stop the VNF, delete the interface, and then restart the VNF.
-
After attaching or detaching a virtual function, you must restart the VNF for the changes to take effect.
-
eth0 and eth1 are reserved for the default VNF interfaces that are connected to the internal network and the out-of-band management network. Therefore, the configurable VNF interface names start from eth2.
-
Within a VNF, the interface names can be different, based on guest OS naming conventions. VNF interfaces that are configured in the JCP might not appear in the same order within the VNF.
-
You must use the target PCI addresses to map to the VNF interfaces that are configured in the JCP and you must name them accordingly.
Configure Storage Devices for VNFs
An NFX350 device supports the following storage options for VNFs:
CD-ROM
Disk
USB
To add a virtual CD or to update the source file of a virtual CD:
user@host# set virtual-network-functions vnf-name storage device-name type cdrom source file file-name
You can specify a valid device name in the format hdx, sdx, or vdx—for example, hdb, sdc, vdb, and so on.
To add a virtual USB storage device:
user@host# set virtual-network-functions vnf-name storage device-name type usb source file file-name
To attach an additional hard disk:
user@host# set virtual-network-functions vnf-name storage device-name type disk [bus-type virtio | ide] [file-type raw | qcow2] source file file-name
To delete a virtual CD, USB storage device, or hard disk from the VNF:
user@host# delete virtual-network-functions vnf-name storage device-name
After attaching or detaching a CD from a VNF, you must restart the device for the changes to take effect. The CD detach operation fails if the device is in use within the VNF.
A VNF supports one virtual CD, one virtual USB storage device, and multiple virtual hard disks.
You can update the source file in a CD or USB storage device while the VNF is running.
You must save the source file in the /var/public directory, and the file must have read and write permission for all users.
Instantiate a VNF
You can instantiate a VNF by configuring the VNF name, and by specifying the path of an image.
While instantiating a VNF with an image, two VNF interfaces are added by default. These interfaces are required for management and for the internal network.
Only QCOW2, IMG, and RAW image types are supported.
To instantiate a VNF by using an image:
user@host# set virtual-network-functions vnf-name image file-path user@host# set virtual-network-functions vnf-name image image-type image-type user@host# commit
When you configure VNFs, do not use VNF names in the format vnfn—for example, vnf1, vnf2, and so on. Configurations that contain such names fail to commit.
(Optional) To specify a UUID for the VNF:
user@host# set virtual-network-functions vnf-name [uuid vnf-uuid]
uuid is an optional parameter.
We recommend that you allow the system to allocate a UUID for the
VNF.
You cannot change the image configuration for a VNF after saving and committing the configuration. To change the image for a VNF, you must delete the VNF and create a VNF again.
Verify the VNF Instantiation
To verify that the VNF is instantiated successfully:
user@host> show virtual-network-functions ID Name State Liveliness -------------------------------------------------------------------------------- 1 vjunos0 Running alive 2 centos1 Running alive 3 centos2 Running alive
The output in the Liveliness field of a VNF indicates whether the IP address of the VNF is reachable over the internal management network. The default IP address of the liveliness bridge is 192.0.2.1/24. Note that this IP address is internal to the device and is used for VNF management.