Listed below are the main generic prerequisites required so that the uCPE Manager can be deployed on the host platform: A uCPE device with Enea NFV Access Run Time Platform installed. A machine running CentOS 7 with network access to the physical device. CPU, RAM and storage requirements for the uCPE Manager: For small-sized deployments (tens of devices): 4 cores 16 GB RAM 300 GB hard-drive For mid-sized deployments (hundreds of devices): 8 cores 32 GB RAM 300 GB hard-drive For large deployments (thousands of devices): 16 cores 64-256 GB RAM 1 - 2 TB hard-drive

Unpack the uCPE Manager and install it following the instructions below.

Install Java: Install OpenJDK 11: sudo yum install java-11-openjdk-devel Verify the installation: java -version openjdk version "11.0.3" 2019-04-16 LTS OpenJDK Runtime Environment 18.9 (build 11.0.3+7-LTS) OpenJDK 64-Bit Server VM 18.9 (build 11.0.3+7-LTS, mixed mode, sharing) The following system variables need to point to the OpenJDK 11 installation: export JAVA_HOME=$(dirname $(dirname $(readlink $(readlink $(which javac))))) export PATH=$PATH:$JAVA_HOME/bin export CLASSPATH=.:$JAVA_HOME/jre/lib:$JAVA_HOME/lib:$JAVA_HOME/lib/tools.jar If there are multiple java versions installed, switch between them using the following command: alternatives --config java Open a terminal with administrative rights, i.e. log into a bash shell with root privileges. Choose the target installation folder, e.g. /opt/ems. Everything will be installed under a folder called ucpemanager within the target installation folder. The application files will be installed in /opt/ems/ucpemanager/application. The database will be installed in /opt/ems/ucpemanager/database. If you have multiple spindles, it is recommended to let the application run off one and the database off the other. This will result in optimum performance. It is also recommended that the swap disk be the same as the one used for the application. Assuming another spindle is used (/drive2) do the following: Create a folder which will host the database (e.g. emsDatabase). Create a soft-link that will point to this folder: ln -s /opt/ems/elementcenter/database /drive2/emsDatabase Follow the installation process as described below.

Open a terminal with administrative rights, i.e. log into a bash shell with root privileges. cd to the folder you are installing from. Verify that the folder you are installing from contains the following files: README install.sh doinstall.sh configureHA.sh ucpemanager-x.y-Buildz-Linux.tar.gz ReleaseNotes Run the following command: ./install.sh /opt/ems ucpemanager-x.y-Buildz-Linux.tar.gz This command will: Extract the application files from the compressed install kit. Install the bundled database (if the user specifies an internal database). Install ucpemanager as a service with the name ucpemanager. Start the ucpemanager service. The service will be automatically started when the computer boots up. The user may enable the firewall in order to allow access to these specific ports: 80 (TCP), 443 (TCP), 54327 (UDP) and 5701:5708 (TCP). If callhome is used access to the following ports must also be allowed: 4334 (TCP) and 2021:2040 (TCP). Otherwise, the user should check that the CentOS machine where the uCPE Manager is installed has the firewall disabled. Verify that the installation has succeeded by: Pointing your browser to the server machine running the uCPE Manager. In the login screen, log in with the username: admin and password: admin. In order to manage the ucpemanager service, user can run: service ucpemanager start/stop

It is possible to use a restore file created by the "System Backup" utility provided in the uCPE Manager, to install a system and set it to a known state. The file to be used is the zip file created by System Backup, not the one created by the uninstall or upgrade processes described below. The name format of this file will be: SystemBackup_MMMDD_YYYY_HHMM_SS.zip (e.g SystemBackup_Feb19_2013_2257_42.zip). Follow the steps for Installation provided above and provide an additional argument as shown below: ./install.sh \ /opt/ems ucpemanager-1.0-Build8-Linux.tar.gz \ SystemBackup_MMMDD_YYYY_HHMM_SS.zip The other steps are exactly the same as specified in the Installation instructions.

Verify that the folder you are upgrading from contains the following files: upgrade.sh doupgrade.sh configureHA.sh ucpemanager-x.y-Buildz-Linux.tar.gz Run the following command: ./upgrade.sh /opt/ems ucpemanager-1.0-Build8-Linux.tar.gz Running this command will: Stop the currently running ucpemanager service. Create a compressed file of the ucpemanager application folder, called: ucpemanager-Backup-YYYYddMMHHmm.tar.gz, which contains a snapshot of the existing installation. Rename the application folder to application_original. Extract the application files from the specified compressed install kit. There will now exist a (new) application folder, with the contents of the new kit. Start the ucpemanager service. When the ucpemanager service starts, it will recognize the fact that an old version of the application needs to be upgraded (based upon the existence of the application_original folder. All the relevant data from the old installation will be copied to the new one and the application_original folder will be deleted.

Verify that the folder you are uninstalling from contains the following files: uninstall.sh douninstall.sh Run the following command: ./uninstall.sh /opt/ems Running this command will: Stop the currently running ucpemanager service. Create a compressed file of the ucpemanager application folder, called ucpemanager-Backup-YYYYddMMHHmm.tar.gz, which contains a snapshot of the existing installation. Uninstall the ucpemanager service, so that it will not startup on reboot. Uninstall the database service (if an internal database is being used). Completely remove the contents of the application and database folders. After these steps, the uCPE Manager is completely removed from the system.

Verify that the folder you are restoring from contains the following files: restore.sh dorestore.sh configureHA.sh ucpemanager-Backup-YYYYddMMHHmm.tar.gz (the original installation snapshot, as obtained from a previous uninstall). Run the following command: ./restore.sh /opt/ems ucpemanager-Backup-YYYYddMMHHmm.tar.gz Running this command will remove any vestiges of the existing ucpemanager service, if they exist, and reinstall the ucpemanager application on the specified target, restoring the data in the database and files in the process. The ucpemanager service is then started and the older version is now running on the system.

The following describes the steps required for setting up the virtualization infrastructure, ensuring that a uCPE device is ready for virtualized service deployment. The sections herein contain information about enrolling uCPE devices into the Enea uCPE Manager, selecting physical interfaces to be used by virtualized networking and creating different types of bridges to enable VNF communication. The Zero Touch Provisioning mechanism is also touched upon, as alternative to manual configuration of the virtualization infrastructure.

Enrolling uCPE devices into the Enea uCPE Manager can be accomplished using one of the two possible methods.

When using this mechanism, the uCPE Manager will periodically poll the uCPE device, using a specified IP address as the destination, attempting to establish a management connection. Add the uCPE device running the NFV Access Run Time Platform to the management system by: Selecting in the uCPE Manager: Devices -> Manage -> Add. Suppling information about the uCPE device, and setting the parameters that will be used to connect to it. The relevant parameters are: Type. The type of device to be added, i.e Enea universal CPE. Name. The name by which the device is referred to in the uCPE Manager. IP Address. IP address of the uCPE device. SSH Port. The NETCONF Port used for communications. Default is set to 830. SSH User Name. The user name for SSH connectivity. Default user is root. SSH Password. Leave this blank. Device Calls Home. This checkbox indicates the direction of device communications. For Direct Connection, leave this flag unchecked. Device ID. The unique identifier of the uCPE device.

Follow the same steps as described in the previous section, making sure that the Device Calls Home checkbox is selected this time. The IP Address of the uCPE device is not required. When using this mechanism, the device will initiate a connection to the uCPE Manager for NETCONF traffic (over SSH), while the uCPE Manager waits for a device connection. For more information please see section Installing Enea NFV Access for more details.

Once a management connection with the uCPE device has been established by using any of the supported methods, the virtualization networking infrastructure can be configured either manually or by using Zero Touch Provisioning. Available network interfaces can be added to the management system, for use by the networking virtualization infrastructure.

For Manual Configuration of uCPE networking, select the uCPE device first and then Configuration -> External Interfaces, where one can find a list of available network interfaces and their capabilities.

After networking interfaces have been added to the uCPE Manager, the user can change the interface type (DPDK, SR-IOV, Standard, wan). How to Edit the Configuration of an Interface

To edit an interface configuration type from the uCPE Manager, select the uCPE device, then from the top toolbar select the Configuration menu then External Interfaces -> Configuration. The already configured interfaces are displayed here, as can be seen in the figure above. In order to edit an already configured interface, double click on the desired one and a popup will appear as shown in the figure below. From the Host Interface window, a user can change the networking type and the IP address assignment:

Set the IP address assignment of the Management Interface to static To change an interface type from the uCPE Manager, select the uCPE device, then from the top toolbar select Configuration and then External Interfaces -> Configuration. The already configured interfaces are displayed here. From the interfaces' list, edit the interface which has the "Management" flag set to "true", by double clicking on it, triggering a popup window:

From the Host Interface window, change the IP address-assignment to "static". After the address assignment is set, the user needs to set the IP address, netmask and the gateway of the interface. The user can use the dropdown list to set the type of the IP version: IPv4 or IPv6 address:

Set the IP address assignment of the Management Interface to DHCP To change an interface type from the uCPE Manager, select the uCPE device, then from the top toolbar select Configuration and then External Interfaces -> Configuration. The already configured interfaces are displayed here. From the interfaces' list, edit the interface which has the "Management" flag set to "true", by double clicking on it, triggering a popup window. Within the Host Interface window change the IP address assignment to "dhcp".

Changing the static IP of the Management Interface To change an interface type from the uCPE Manager, select the uCPE device, then from the top toolbar select Configuration and then External Interfaces -> Configuration. The already configured interfaces are displayed here. From the interfaces' list, edit the interface which has the "Management" flag set to "true", by double clicking on it, triggering a popup window. Within the Host Interface window change the "static" IP address as well as the netmask and the gateway.

The user can use the dropdown list to set the type of the IP version: IPv4 or IPv6 address. In order to make physical network interfaces available to the virtualization infrastructure and VNFs, they must be configured into the management system. To add an interface into the uCPE Manager, select the uCPE device, then from the top toolbar select Configuration -> OpenVSwitch -> Host Interfaces. The available Interface types are detailed below. DPDK Interface Type Configuring a physical interface in DPDK mode will require a DPDK-based application (e.g. OVS-DPDK) in order to access and use the interface. An interface set as the DPDK can be attached to an OVS-DPDK bridge. Make sure the Enable DPDK checkbox is selected in Device -> Configuration -> DPDK, otherwise no interface can be assigned to the DPDK. To add a DPDK interface under the management system, set appropriate values for the following fields: Source: name of the physical interface. Type: dpdk Networking-type: dpdk Dpdk-type: the kernel module that allows user space access to the physical interface. Enea recommends using the vfio-pci driver. SR-IOV Interface Type SR-IOV technology allows for the creation of a number of virtual functions on the host interface, which can be used by VNFs running on the uCPE device. For SR-IOV mode configuration, the user must set values for the following fields: Source: name of the physical interface. Type: sr-iov Networking-type: srIov sriov-mode: adapter-pool sriov-num-vfs: the number of virtual functions to create. Standard Interface Type Some of the physical network interfaces available on a uCPE device, including Ethernet interfaces, do not have DPDK or SR-IOV support. Instead, the Linux kernel driver has to be used. Wi-Fi and 4G/LTE modems can also be configured and used for virtualization infrastructure and VNFs. To add Standard interfaces under the management system, the user must set values for the following fields: Source: the name of physical interface. Networking-type: standard PCI Passthrough Interface Type For the PCI Passthrough a user does not have to configure a physical interface, instead simply select the PCI address and connect it to a virtual port when the VNF instantiation step is reached.

After networking interfaces have been added to the uCPE Manager, the user can create the necessary OVS bridges. How to add OVS bridges in the uCPE Manager Select the uCPE device. Select Configuration. Click OpenvSwitch. Select the Bridges option, then click Add. Depending on the settings in Configuration -> OpenVSwitch -> DPDK, OVS bridges with or without DPDK support will be used on the uCPE device. There are three types of bridges which can be created, each one fulfiling a different role: uCPE In-band Management bridge In-band Management refers to a model where both the data plane and control plane flow over the same network path. In some situations (e.g. the uCPE device has only one routable IP address), this is the only option available to both control and configure the uCPE device, while also allowing for data-path traffic to pass over the same physical interface. The solution provided by Enea for in-band management is based upon an OpenvSwitch bridge fielding all traffic passing through the WAN physical port. As a prerequisite, the WAN physical port has to be configured to get its IP through DHCP. Any standard or DPDK-assigned network interface can be used for the In-Band management bridge. The In-Band Management bridge must be recreated each time the uCPE Manager IP address is changed. To create the In-Band Management bridge, the user must set values for the following fields: name: name of the bridge. ovs-bridge-type: inbandMgmt mgmt-address: select IPv4 as the type and fill in the IP address of the uCPE Manager. mgmt-port: the NETCONF management port. Enea recommeneds leaving this field unchanged. The first VNF instantiated on the uCPE device must be connected to the In-Band Management bridge and its WAN interface must be configured as the DHCP client. In-band Management bridge for VNFs If VNF management can be done over a dedicated virtual interface, its possible to extend the networking infrastructure configuration to also access the VNF's management interface over the WAN port. For this setup, three types of traffic will pass over the WAN physical interface: Device management. Part of the device configuration done by the uCPE Manager. VNF(s) management. Enabling or disabling features of a VNF. E.g. enabling/disabling the firewall or VPN setup. Data-path. All other traffic that is not used in the control plane and needs to reach a LAN network. To create a VNF In-Band Management bridge, the user must set values for the following fields: name: name of the bridge. ovs-bridge-type: vnfMgmt vnf-mgmt-address: select IPv4 as the type and fill in the IP address for management network, e.g 10.0.0.1. VNF management interfaces must be configured in same network as the vnf-mgmt-address of the bridge. For more information, please see 4.4 VNF Management. Data-plane Bridge Data-plane bridges are generic bridges used for the VNF data-plane. There are two supported sub-types: communication: allows for VNF communication towards LAN/WAN networks. This bridge type has at least one physical port attached to it. integration: allows for VNF-to-VNF communication (usually for service function chaining). This bridge type does not have any physical port attached. To create a Data-plane bridge, the user must set values for the following fields: name: name of the bridge. ovs-bridge-type: select communication or integration, depending on intended usage. For communication bridges, physical interfaces can be added to the bridge.

Zero-Touch Provisioning (ZTP) refers to the process of when a device starts up for the first time and its initial configuration is pushed down by an external management system, so that it is setup for proper operation without additional manual intervention by an operator. ZTP is an alternative to Manual configuration. A variety of operations can occur as part of ZTP such as initial device setup, configuration of managed objects, etc. The goal is to set up a device to the maximum possible extent without forcing an operator to be physically present (initially) to manage the device. An offline configuration is usually prepared in advance for the uCPE Manager to setup the virtualization infrastructure on the uCPE device, as soon as a device enrolls into the management system.

The Offline Configuration subsystem is used to pre-populate a configuration for a device that will be brought under management at a future point in time. When creating an offline configuration store a Device ID can be specified. This ID uniquely identifies the device to be initialized. Alternatively, a wildcard can be used in the Device ID field, which results in a configuration being pushed on all uCPE devices upon their initial connection towards the uCPE Manager. To create an offline configuration, from the top toolbar menu select Applications -> Offline Config -> Add. The following fields are available: Name: name of the device. Device type: Enea universal CPE. Device version: 2.2.2 Config Set: uCPE Config Device ID: device ID or a wildcard(*). Device Grouping Tags: a tag to group devices. When a device connects to the uCPE Manager for the first time, it checks the device to see if it has been Zero Touch Provisioned (ZTP). If not, it looks for an offline configuration that matches these values, in the following order: The Device ID. The set of tags. A "*" for Device ID (wildcard). If a match is found, the offline configuration is sent to the device as part of Zero-Touch-Provisioning. After creating the Offline Config Store, access the device through Applications -> offline config -> Config App and provision it with the required initial configuration. This operation mirrors what happens during manual configuration described in the previous section.

The custom scripts feature allows users to execute user-defined scripts on the uCPE device at various times.This allows for more flexible and advanced configurations such as a LTE modem configuration, advanced network configurations or OVS flow rule programming at any time.

The scripts need to be uploaded to the uCPE Manager prior to use. When uploading scripts to the uCPE Manager make sure to select the right script type. The following script types are supported: Once-before-startup. This script will only execute once during the startup. Always-before-startup. This script will always execute during the startup. Once-after-startup. This script will only execute once after the system has been started. Always-after-startup. This script will always execute after the system has been started. Follow the instruction below to upload scripts: Select Devices -> Custom Scripts -> Configure. Select Upload to EMS. In the Script Type menu, select the type the uploaded script should have. Press Choose File to select the scripts needed, and then press Send.

Follow the instruction below to remove scripts: Select Devices -> Custom Scripts -> Configure. Select the script you want to delete from the Uploaded Scripts tab and then click Delete, which will remove the script immediately from the uCPE Manager.

The location where the scripts are staged in the uCPE Manager can be chanaged as described below: Select Devices -> Custom Scripts -> Configure. Select the Configuration tab and specify a new loacation to store the scripts. Change the script storage location only if you have many scripts which you would prefer to store on another partition, otherwise leave this configuration as is.

How to run Custom Scripts Select Devices -> Custom Scripts -> Apply Scripts. In the Script Config Screen pop up, select the devices from the device(s) chooser list on which to run the scripts. Press the > button to move the devices to the right side of the chooser, which is the list of devices that will execute the selected scripts. Select the scripts from the list under the device(s) chooser by pressing the + button. In the pop-up window, select the scripts from the list. If there are no scripts to select, then there is no script uploaded with that particular type. Upload the script(s) needed and try again. Check the checkbox Reboot devices if you want to reboot and execute the scripts at once and then press ok. The status of execution for the scripts can be seen by opening the Fault -> Events screen and filtering by device and/or the event name Custom.

Device Upgrade/Install performs the following operations to the device: Prepare for upgrade. This stage tells the device that an upgrade is about to happen. Install file on device. This stage copies the file to the uCPE device. Upgrade Device. This stage causes the device to replace its running image with the newly copied image.

Before an install or upgrade can be completed, certain configuration data must be set. Files also need to be uploaded to the Device Upgrade image repository in order to be uploaded to the device. Launch the Device Upgrade management console by selecting Devices -> Upgrade from the top toolbar. The console when launched will contain the following tabs: Image Library. To add/delete an image. Upgrade Operations. See running upgrades, cancel any upgrades in progress, start a device upgrade. Configuration. Upgrade configuration parameters. Press Close when the message File Uploaded Successfully appears on the File Upload Screen.

Add an image to the image repository/library Select Devices -> Upgrade. Select Add from the Image Library tab to add a new image file. Click on Choose File to provide the path to the image file (must be of type rootfs.ostree.tar.bz2). Select the target hardware platform corresponding to the image being uploaded (xeon-d or atomc-3000). Click Send to upload the image to the image repository. Delete an image from the image repository Select Devices -> Upgrade. Select the image you want to delete from the Image Library tab and then click Delete.

The Upgrade Operations tab allows a user to manage device upgrades in the system. It allows the user to see all the upgrades that are currently in progress, as well as listing the completed ones. If an upgrade succeeds or fails, then a row will be added to the completed upgrades table. If one fails, the failure message will be visible here. The list of completed upgrade tasks resides in memory and will not persist across reboots of the server. How to Install/Upgrade immediately or schedule for later Select Devices -> Upgrade. Select Upgrade Devices from the Upgrade Operations tab. This will launch a Multi Device Install Image screen that will allow the user to install and upgrade more than one device at a time or upgrade later. The configurable parameters are: Scheduling. Click this checkbox if the upgrade will be done later. Schedule the day, hour and minute for when to run the upgrade. The hour represents the local uCPE Manager server hour. Description. An optional description of the operation. It is recommended to add a description so that different upgrades happening simultaneously can be distinguished. Image File. Click on Choose Image File to select the image file. Devices. The list of available devices is populated when an image file is chosen. The device(s) chooser is then populated with the list of devices that can accept that file. Press the > button to move the devices to the right side of the chooser, which is the list of devices that will be upgraded. Upgrade Operation. Available options are: Install and Activate. This will do an image installation as well as an upgrade. Install Only. This will do an image installation only. The image is copied to the device, and an upgrade will be done later either at a scheduled time or when the option Activate Only is selected. Activate Only. This will activate an already installed image on the device.

The installed releases on a device can be viewed by selecting the device first, then from the top toolbar selecting Configuration -> Upgrade. The installed releases on the device, the release status, release state, commit-id and release version will be listed in a table.

The status of the installation and upgrade can be viewed in the Upgrade Operations tab. Ongoing or scheduled upgrade operations can be viewed or cancelled. To view the status of an installation or upgrade operations Select Devices -> Upgrade. Select Upgrade Operations. The ongoing operations are listed at the top and a history of failed or successful operations are listed at the bottom. Select an Active or Completed Upgrade Operation and click the Device Status button to see detailed information regarding the upgrade operation, including the devices involved and information per device. To cancel an upgrade operation Select Devices -> Upgrade -> Upgrade Operations. Select an operation from the list and press Cancel Upgrade and Confirm. The operation will then be deleted from the list.

The default values present in the configuration of each device are recommended for use. Modifying them is for an Advanced User only. How to Configure the uCPE device Upgrade Select Devices -> Upgrade. Select Configuration. The configurable parameters are: deviceImageDir. This is the disk location of the device image repository. If an absolute path name such as /usr/local/deviceimage is given, then the absolute path name is used. If no absolute pathname is given it is considered to be relative to the installation directory. maxThreads. This number dictates how many upgrades the system can manage at one time, either individually launched or launched from the multi-device screens. This value defaults to 20, which means that 20 devices may be updated at one time. KeepAlive. This number represents the number of seconds that a thread will be kept alive before it is collected. If multiple installations are occurring, this will keep the thread alive for X seconds before it is released. If not released, it can be used by the internal scheduling system as soon as it has completed an upgrade.

Each device can receive image files and use them to upgrade. This can be done by selecting the device in the System view and clicking the Upgrade button. In the new window, an upgrade image can be chosen from the Image Files tab by selecting the image file from the list and clicking the Install on Device button. Once an image is installed on the device, the image will be available on the device and be visible in the Releases tab. It can then be selected from the list and the upgrade started by clicking the Upgrade button.

The Enea uCPE Manager is responsible for onboarding, configuring (e.g. CloudInit) and ensuring life cycle management of VNFs that are instantiated and run on the various uCPE devices.

The onboarding of a VNF means adding it to the Enea uCPE Manager VNF Catalog and preparing it for instantiation (deployment on connected uCPE devices). This is accomplished using the Enea uCPE Manager Onboarding graphical user interface. Typically, the Getting Started Guide of a VNF contains all necessary information needed to onboard a VNF.

The user must first retrieve the necessary artifacts from the VNF vendor: Download the VNF from the commercial vendor. Procure any VNF-specific files from the VNF vendor, e.g. license file. There are no standard ways of managing VNF licenses, therefore no general guidelines can be provided. One example of license handling that can be employed in the uCPE Manager is the adding of a license during the Cloud-Init setup. Optionally, get access to the VNF specific VNF Manager for day 1 and 2 configuration (in cloud or for local deployment). Procure the Getting Started Guide from the VNF vendor, preferably for KVM deployment for VNF specific configuration information.

Once all needed downloadables, documentation and more have been attained, preparation for onboarding must be completed: Determine the use-case and performance requirements of the VNF you wish to deploy: This decides what resources the VNF is configured for, along with networking and day zero configurations. Generally, the Getting Started Guide for the VNF provides guidelines for resource allocation, but since performance is dependent on hardware capacity, the right resource allocation for deployment is determined through benchmarking. Determine the amount of hardware resources needed for the VNF (RAM, number of CPUs and storage size). Determine how many Virtual Network Interfaces the VNF will use. Determine the Day-0 configuration method from the VNF Getting Started guidelines. For many VNFs, day zero configuration can be skipped in early onboarding efforts when automation is not of importance. Determine any requirements needed by the Cloud-Init file structure and the content needed when this structure is used.

How to onboard a VNF into the uCPE Manager Select from the top toolbar VNF -> Descriptors Click the On-board button. When prompted by the UI, make sure the VM Image radio button at the top of the onboarding screen is selected, it will trigger a popup menu window. This window contains data fields where both necessary and optional information about the VNF can be supplied. After doing so, press the Onboard button, the uCPE Manager will create the VNF descriptor and add it to its VNF Catalog.

Main fields VM Image File. This is the Virtual Machine image file for the VNF. Typically, it is a QCOW image. Press Choose File and select the image you wish to upload. Image Format. Select the format which matches the image file format. VNF Type Name. This is the name that will be used to identify this VNF. It will be shown in the VNFs list. Description. This field contains any description provided and is only displayed in the GUI tables in the uCPE Manager. Version. This is the version of the current VNF that you are hosting. It's used to distinguish this VNF from other versions of the same type. Memory in MB. This is the amount of memory (in megabytes) that will be provided to this type of VNF when it is instantiated. To determine the value for this field, consult the VNF vendor. Num of CPUs. The number of CPUs that will be dedicated to an instance of this VNF when created. To determine the value for this field, consult the VNF vendor. Storage in GB. How much disk space to provide an instance of this VNF. To determine the value for this field, consult the VNF vendor. Interfaces Tab Click on the Interfaces tab to show the Interfaces table. This table will contain the interfaces required by this VNF to be configured, when creating an instance. Consult the VNF vendor to determine which and how many are required. Each interface requires a name, and optionally a description, used only by the uCPE Manager. CAUTION: The user MUST conserve the same order for the virtual interfaces during both onboarding and instantiation phases. Cloud Init Tab Click the Clout Init tab to provide the Clout-Init configuration. There are three fields that need to be populated: Cloud-Init Datasource To onboard a VNF you must specify the Cloud-Init Datasource that the VNF uses. This information is procured from the VNF Vendor. Choose one of the following methods to specify the datasource: None. If there is no datasource. ConfigDrive. This method allows you to provide any number of content-data files containing Cloud-Init data. NoCloud. This is a simpler method that uses only one cloud init file (User-Data). ISO. Pre-cooked cloud-init image. This image must be created by the user according to VNF requirements. Cloud-Init Disk Type The Cloud-Init Disk Type field must be set to either Disk, or CD-ROM, depending on what the VNF requires. You can get this information from the VNF Vendor. Content Files Table The Content Files Table is ONLY used if you choose ConfigDrive as the Cloud-Init Datasource. For each content file added, you must provide a Path. When a user uses the uCPE Manager to create an instance for multiple VNFs, they will be prompted to provide a data file for each entry in this table. Each type of VNF will require different cloud-init files, e.g.: a license file. The data files will be added to the cloud-init image that the user provides at the instantiation of the VNF. If the cloud-init image is not provided, no Cloud-Init Data Source will be created for that VNF and there will be no warning. Consult with the VNF vendor to determine what is required for the VNF you are onboarding. Properties Tab In this table, you can enter values for properties that will be used during instantiation of the VNF. The values will augment the default values in the Domain.XML file used by libvirt/virsh (running in NFV Access) when creating an instance of the VNF. Consult with the VNF Vendor or ENEA support for values needed by specific VNFs. Property Values numHugePages defines the number of huge memory pages the VNF uses (for DPDK). vnfMgmtIpAddress: the IP address of the VNF's management interface, connected to a vnfMgmt bridge (e.g. 10.0.0.2). internalMgmtPort: the VNF's TCP/UDP port used for management (e.g. 443). externalMgmtPort: the Management port used for external access (e.g. 60001). The last three properties are useful in conjuction with the vnfMgmt bridge type. They allow the user to map the internal VNF management port to an external port, useful for VNF configuration from WAN. In the previous example, the internal TCP port 443 (HTTPS) was mapped to the external port 60001, which allows the user to access the VNF management port from a web browser e.g. https://<WAN_IP>:60001.

When a VNF is onboarded and available in the VNF catalog, it can be instantiated on connected uCPE devices. The configurations provided when the VNF is onboarded, serve as a template for instantiation. Before instantiating any VNF, please make sure the available storage space on the uCPE device is big enough to accommodate the VNF you need to instantiate. Follow the instructions below to instantiate a VNF: Select from the top toolbar VNF -> Instances Click the Add button. Fill out the following mandatory fields: Name: a descriptive name. VNF Type: a list of onboarded VNFs. uCPE Device: the uCPE device to instantiate the VNF on. Networking Configuration: Connect each configured NIC with a bridge, SR-IOV or PCI Passthrough. Set up each NIC with a driver method. All configured NICs must be set up before instantiating a VNF. Failure to do so will end in a failed instantiation. Add VNF-specific configuration data by uploading a Cloud-Init file (when the Cloud-Init is used). Add any VNF-specific files (e.g license files). Hit the Create button to deploy the VNF and run it on the specified uCPE device. Selecting the VNF -> Events menu will show that the VNF was created and a connection was established.

Once the VNF is deployed, the VNF console can be entered using SSH and virsh commands. The VNF Console is a typical starting point for determining a successful deployment and configuring a VNF beyond Day Zero. SSH to the uCPE device from the Enea uCPE Manager (Device->SSH) using user: root and no password. In SSH: Use the virsh list command to list all running VNFs and to determine the VNF's instance number. Use the virsh console <instance number> command to enter the VNF-specific console.