In recent years, as cloud environments have become more widespread, telecom operators and communication service providers began placing Network Function Virtualization (NFV) at the core of their operational strategies. Today, the NFV technology is a networking reality, enabling operators to create Virtual Network Functions (VNFs) as well as providing them with more control over how their network components work and how they are developed. Furthermore, VNFs deliver more flexibility, operability and, most importantly, speed of deployment as compared to their hardware counterparts.

Despite the fact that a substantial part of Telco market still hardly relies on old, well-known fixed function boxes, the industry realizes that customer premises equipment (CPE) upgrade is necessary to embrace the technology shift. As services and technology evolve, CPE becomes more powerful, being capable of handling advanced functionality. Therefore, we decided to practically demonstrate how VNFs can be deployed on these next-generation hardware platforms and what performance characteristics they provide.

Hardware Platform

As the target platform, we have chosen the NXP QorIQ® LS1046A reference design board [1], a small business router solution, mainly because it has 2 10GB ports and supports DPDK (Data Plane Development Kit). For more details, visit NXP website.

Software Components

Since Firewall is an element of CPE that highly consumes a device’s processing speed and memory, we decided to evaluate a reference implementation of the DPDK-based virtual Firewall (vFW) VNF, one of the components of OPNFV (Open Platform for NFV) Sample Virtual Network Function (SampleVNF) Project.

OPNFV is a collaborative open source ecosystem for network functions virtualization started by the Linux Foundation in 2014 [2]. SampleVNF is one of OPNFV projects aimed to provide VNF developers with open source approximations of Telco-grade VNFs to perform prototyping and adoption of real life use-cases.

Before We Start

To get Firewall up and running on your new CPE box, the following building blocks should be prepared:

  • The build environment
  • The operating system for CPE
  • The DPDK framework for the NXP board
  • The virtual Firewall SampleVNF

Further we will describe the steps to be taken to get each of them ready.

Preparing the Build Host

The first step of the deployment process is preparation of the build host.

1. Make sure your host has an access to the remote Ubuntu official server.

2. For root users, there is no limitation for the build. For non-root users, obtain sudo permission by running the command:

                    
                        $ sudoedit /etc/sudoers
                    
                

and add a line:

                    
                        <user-account-name> ALL=(ALL) NOPASSWD: ALL
                    
                

Preparing NXP LSDK

Layerscape Software Developer’s Kit (LSDK) is the next generation of Linux enablement software for Layerscape and QorIQ family of processors. It provides all the necessary drivers, tools and libraries required to enable all features of the ARM-based Layerscape processors and Power-based QorIQ P-series and T-series processors [3].

1. Download flexbuild form NXP website. Please note that registration is required.

2. After the download has been completed, extract its content:

                    
                        tar xvzf flexbuild_lsdk1803.tgz
cd flexbuild
source setup.env
                    
                

3. Download the images for boot partition and NXP-specific components:

                    
                        wget http://www.nxp.com/lgfiles/sdk/lsdk1803/app_components_arm64.tgz
wget http://www.nxp.com/lgfiles/sdk/lsdk1803/bootpartition_arm64_lts_4.9.tgz
wget http://www.nxp.com/lgfiles/sdk/lsdk1803/arm64-modules-4.9.79.tgz 
                    
                

4. Build LSDK Ubuntu userland with the following commands:

                    
                        flex-builder -i mkrfs -a arm64
tar xvzf app_components_arm64.tgz -C build/apps
tar xvzf arm64-modules-4.9.79.tgz -C build/rfs/rootfs_ubuntu_xenial_arm64/lib/modules
flex-builder -i merge-component -a arm64
                    
                

5. Now flash the generated LSDK image to drive. For this purpose we were using a solid-state drive (SSD):

                    
                        flex-installer -b bootpartition_arm64_lts_4.9.tgz -r rootfs_ubuntu_xenial_arm64.tgz  -m ls1046ardb  -d /dev/sdb
                    
                

Booting the Board

1. Configure the console connection. To streamline the process, we recommend referring to the board quick start guide.

2. Connect the SSD drive.

3. Turn on the board.

4. Press any key, when the following message appears: Hit any key to stop autoboot:0

5. Update the board boot image using the following commands:

                    
                        load scsi 0:2 a0000000 firmware_ls2088ardb_uboot_norboot.img
sf probe 0:1
sf erase 0 +$filesize && sf write 0xa0000000 0 $filesize
cpld reset altbank
                    
                

6. When the login prompt appears, enter default username and password: root/ root.

7. When LSDK is successfully booted, you can make it a default boot target by changing the SW3[1:8] (jumper switch) setting from 01000110 to 01001110.

Binding the 10GB Ports with DPDK (USDPAA) Driver

User Space Data Path Acceleration Architecture (USDPAA) is a software framework, providing Linux user space applications with direct access to software portals. By default, all the available interfaces are configured as standard Linux interfaces. In order to allow the DPDK to create interfaces, we need to boot the board with the custom device tree. To prepare it, the following steps should be taken:

1. Prepare the environment on the build machine:

                    
                        cd flexbuild
source setup.env
                    
                

2. Modify the fsl-ls1046a-rdb-usdpaa.dts file to assign FMAN ports to Linux by removing the following Ethernet node that corresponds to FM0-MAC3 (RGMII-1):

                    
                        vim ./packages/linux/linux/arch/arm64/boot/dts/freescale/fsl-ls1046a-rdb-usdpaa.dts

ethernet@2 {
compatible = "fsl,dpa-ethernet-init";
fsl,bman-buffer-pools = <&bp7 &bp8 &bp9>;
fsl,qman-frame-queues-rx = <0x54 1 0x55 1>;
fsl,qman-frame-queues-tx = <0x74 1 0x75 1>;
};
                    
                

3. If you want to have only 10G ports configured as USDPAA ports, all 1G port entries should be removed as follows:

                    
                        ethernet@8 {
        compatible = "fsl,dpa-ethernet-init";
        fsl,bman-buffer-pools = <&bp7 &bp8 &bp9>;
        fsl,qman-frame-queues-rx = <0x5c 1 0x5d 1>;
        fsl,qman-frame-queues-tx = <0x7c 1 0x7d 1>;
};
 
ethernet@9 {
        compatible = "fsl,dpa-ethernet-init";
        fsl,bman-buffer-pools = <&bp7 &bp8 &bp9>;
        fsl,qman-frame-queues-rx = <0x5e 1 0x5f 1>;
        fsl,qman-frame-queues-tx = <0x7e 1 0x7f 1>;
};
                    
                

4. Build a new device tree:

                    
                        flex_builder -c linux -a arm64
                    
                

5. Upload fsl-ls1046a-rdb-usdpaa.dtb to the board:

                    
                        scp ./build/linux/linux/arm64/fsl-ls1046a-rdb-usdpaa.dtb <BOARD_IP>:/root/
                    
                

6. Configure the board to boot with a dtb file:

                    
                        cd /boot
mv fsl-ls1046a-rdb.dtb fsl-ls1046a-rdb-ori.dtb
ln -s fsl-ls1046a-rdb-usdpaa.dtb fsl-ls1046a-rdb.dtb
                    
                

7. Reboot the board, the fsl-ls1046a-rdb-usdpaa.dtb file will be used by Linux.

Configuring USDPAA

1. Modify the usdpaa_config_ls1046.xml  file (located  in /usr/local/dpdk/dpaa) by removing the corresponding port entry. For example, the following entry should be removed for FM0-MAC3 (RGMII-1):

                    
                        <port type="MAC" number="3" policy="hash_ipsec_src_dst_spi_policy0"/>
                    
                

2. Update the IDS policy rule for the remaining entries in the usdpaa_config_ls1046.xml file. For instance, the IDS policy rule for a DPDK port ‘X’ would be hash_ipsec_src_dst_spi_policy’X’.

                    
                        <port type="MAC" number="9" policy="hash_ipsec_src_dst_spi_policy0"/>
<port type="MAC" number="10" policy="hash_ipsec_src_dst_spi_policy1"/>
                    
                

3. Apply the configuration:

                    
                        fmc -c ./usdpaa_config_ls1043.xml -p ./usdpaa_policy_hash_ipv4_1queue.xml -a
                    
                

Building DPDK

Data Plane Development Kit (DPDK) consists of libraries to accelerate packet processing workloads running on a wide variety of CPU architectures. We used the DPDK 17.05 release branch.

Clone the DPDK repository and build it as follows:

                    
                        cd /usr/src/
git clone https://github.com/qoriq-open-source/dpdk.git
cd dpdk
git checkout 17.05-next-qoriq
make T=arm64-dpaa-linuxapp-gcc  CONFIG_RTE_KNI_KMOD=n  install DESTDIR=/usr/local/
                    
                

Building SampleVNF

The vanilla version of SampleVNF cannot be compiled on ARM platform due to usage of x86 specific functions. Therefore, it should be adapted to make it compatible with ARM platform.

1. Install the dependencies by executing the following commands:

                    
                        sudo apt-get update
sudo apt-get -y install build-essential linux-headers-$(uname -r) git unzip libpcap0.8-dev gcc \
make libc6 libc6-dev g++-multilib libzmq3-dev libcurl4-openssl-dev net-tools wget gcc unzip \
libpcap-dev libncurses-dev libedit-dev pciutils liblua5.2-dev libncursesw5-dev libjson0 \
libjson0-dev libssl-dev

cd /usr/src
git clone https://github.com/civetweb/civetweb.git
cd  civetweb
make
make install 
                    
                

2. Clone and build SampleVNF code from GitHub:.

                    
                        cd /usr/src
git clone https://github.com/PLVision/samplevnf.git
cd samplevnf
git checkout arm 
export RTE_SDK=/usr/local/share/dpdk/ 
export VNF_CORE=/usr/src/samplevnf
export RTE_TARGET=arm64-dpaa-linuxapp-gcc
make
                    
                

Start vFW:

                    
                        cd VNFs/vFW

./build/vFW   -p 0x3 -f config/VFW_SWLB_SinglePortPair_1Thread.cfg -s config/VFW_SWLB_SinglePortPair_script.tc
                    
                

Finally you have the vFW VNF up and running on NXP ARM board. The next step would be to evaluate its performance metrics on the given hardware platform. For this purpose, we suggest using Network Service Benchmarking (NSB), an extension to OPNFV Yardstick framework [4], enabling VNF characterization with repeatable and deterministic methods. Stay tuned for the next post, providing the detailed guidelines for vFW performance analysis utilizing this tool.

Taras Chornyi

Taras Chornyi

Networking Solutions Architect at PLVision
Taras has dedicated 7 years to Embedded Systems and Networking and continues to work in these domains, currently contributing to OPNFV projects.
Taras Chornyi

Latest posts by Taras Chornyi (see all)