sonata-nfv / son-examples

Example network services and VNFs to test SONATA's tools and platforms

son-examples

This repository contains several example network services and their corresponding VNFs that can be used to test SONATA's SDK tools and SONATA's service platform.

Services (service-projects/)

Example service projects that include NSDs, VNFDs, etc. The projects are given as source code and have to be packed before they can be pushed to the service platform or the emulator.

Emulator

• sonata-empty-service-emu: Simple service chain with three empty VNFs (UPB) Tutorial.
• sonata-snort-service-emu: Service with a single Snort VNF (UPB) Tutorial.
• sonata-sdk-test-service-emu: Service with 2 empty ubuntu VNFs chained to each other (iMinds).
• sonata-ovs-service-emu: Service with an ovs switch and a Ryu openflow controller (iMinds).
• sonata-vtc-service-emu: Service with single vTC VNF to test the vTC VNF in the emulator (UPB) Tutorial.
• sonata-fw-vtc-service-emu: This will be the service for the Y1 review of son-emu (UPB).
• sonata-fw-dpi-service-emu: Service with a Firewall (ovs+Ryu) and DPI (Snort) (iMinds).
• sonata-fw-service-emu : Service with a single firewall VNF to test the firewall in the emulator (iMinds).

Service Platform

• sonata-fw-vtc-service-sp: This will be the service for the Y1 review of SONATA's service platform.

Naming scheme

• *-emu: Service references Docker-based VNFs that can be executed in son-emu.
• *-sp: Service references VM-based VNFs that can be executed in SONATA's service platform.

Packaging

The given example projects can be packed with the son-cli tools:

First initialize a local SONATA workspace (if not already done):

• son-workspace --init

In service-projects/ do:

• son-package --project sonata-empty-service-emu -n sonata-empty-service
• son-package --project sonata-snort-service-emu -n sonata-snort-service

The created service packages can be found in:

• <service-folder>/target/<package-file.son>

VNFs (vnfs/)

Example VNF implementations. Most of them are given as Docker container configurations so that they can directly be used in the emulator. But the Docker containers can also be included and executed within VM images to run them on the service platform.

• sonata-empty-vnf-docker: Minimalistic empty VNF (UPB).
• sonata-iperf3-vnf-docker: Iperf3 traffic generator (UPB).
• sonata-snort-ids-vnf-docker: Snort 2.9 intrusion detection system (UPB).
• sonata-ovs1-vnf-docker: OpenvSwitch inside Docker container (Packets are processed in userspace inside the vswitch daemon running in the container) (iMinds).
• sonata-ryu-snort-vnf-docker: Ryu Openflow controller, running as a learning switch (rest API included) (iMinds).
• sonata-ryu-vnf-docker: Ryu Openflow controller, running as a learning switch (Snort support and rest API included) (iMinds).
• sonata-vtc-vnf-docker: nDPI based traffic classifier (requieres PF_RING to be installed on the host machine) (NCSRD).
• sonata-snort-ovs-docker: Snort intrusion detection system, extended with an interface to send alerts to a Ryu openflow controller (iMinds).
• sonata-son-emu-sap-docker: Generic container that can be used to be deployed as SAP (Service Access Point) for a service deployed in the SONATA SDK emulator. This container has some basic functionality to generate and capture traffic (iMinds).
• sonata-fw-vnf-docker : Firewall implemented by a Ryu Openflow controller and OpenVSwitch in one single VNF (iMinds).
• sonata-fw-vnf-vm : Firewall implemented by a Ryu Openflow controller and OpenVSwitch in one single VNF. Exported as a Vagrant-built VM. (iMinds).

Naming scheme

• *-docker: VNF executed as Docker container (Dockerfile).
• *-vm: VNF executed as virtual machine image (or Vagrantfile).

Build & Push Docker-based VNFs

In vnfs/ do ...

./build.sh [opt. target repository name (default=sonatanfv)]

./push.sh [opt. target repository name (default=sonatanfv)]

Usage

Deploy example service on son-emu

Step-by-step instructions that show how to deploy the example services on son-emu are given in son-emu's project wiki:

• sonata-empty-service: Service package deployment and validation
• sonata-snort-service: Snort IDS service package deployment and validation

Deploy example service on SONATA's service platform

• TODO (an example service for the service platform will be available soon)

CI/CD Integration

This repository is integrated into SONATA's CI/CD workflow. The following unittests are executed whenever a pull request is created:

• Build VNFs: Builds all Docker-based VNF images (vnfs/build.sh).
• Push VNFs: Pushes all VNF images to SONATA's Docker registry (vnfs/push.sh).
• Package services: Uses son-package to validate the service projects (service-projects/pack.sh).

Note: The packaged services are not yet uploaded anywhere. We use packaging only to validate the service projects and their descriptors.

License

Son-examples is published under Apache 2.0 license. Please see the LICENSE file for more details.

Useful Links

• Snort IDS
• SNORT IDS + Ryu
• Ryu REST api

Contributing

Contributing to the son-examples is really easy. You must:

1. Clone this repository;
2. Work on your proposed changes, preferably through submitting issues;
3. Submit a Pull Request;
4. Follow/answer related issues (see Feedback-Chanel, below).

---

Lead Developers

The following lead developers are responsible for this repository and have admin rights. They can, for example, merge pull requests.

• Manuel Peuster (https://github.com/mpeuster)
• Felipe Vicens (https://github.com/felipevicens)

Feedback-Chanel

• You may use the mailing list [email protected]
• GitHub issues

son-examples's Issues

sonatanfv/sonata-fw-vnf image is broken

start_fw.sh#L20 inside Docker image assumes interface names to be (fwin, fwout), while during actual sonata-fw-service-emu project creation the interface names are listed as (input, output) (see fw-vnf-vnfd.yml#L44).

When I create sonata-fw-service-emu project, I can actually see could not open network device fwin (No such device) (resp. fwout) in ovs-vsctl show output.

$ son-package --project sonata-fw-service-emu -n sonata-fw-service
...
$ curl -i -X POST -F [email protected] http://127.0.0.1:5000/packages
...
$ curl -X POST http://127.0.0.1:5000/instantiations -d "{}"
...
$ sudo docker exec -it mn.fw /bin/bash 
$ root@fw:~# ovs-vsctl show
112e0b1d-d48c-4bcd-a304-af8495364b9b
    Bridge "ovs1"
        Controller "tcp:127.0.0.1:6633"
            is_connected: true
        fail_mode: secure
        Port "ovs1"
            Interface "ovs1"
                type: internal
        Port fwin
            Interface fwin
                error: "could not open network device fwin (No such device)"
        Port fwout
            Interface fwout
                error: "could not open network device fwout (No such device)"
    ovs_version: "2.5.0"

I tried this fix start_fw.sh#L20

- declare -a PORTS=("fwin" "fwout")
+ declare -a PORTS=("input" "output")

and things started working as expected, i.e., I don't see No such device error in ovs-vsctl show and when I deployed sonata-fw-service-emu project similar to Example-3 client <-> server ping works.

Update old descriptors to the new format

Example service descriptors are outdated. They should be updated to the new connection points naming conventions, following the rules described in:

sonata-nfv/son-cli#222

Low iperf3 throughput with sonata-fw-vnf-docker image

Hi,

Can you please take a look at my example and help me identify the network bottleneck at sonata-fw-vnf-docker image? I created client - firewall - server chain and trying to measure performance of the chain with iperf3. The client can ping server, but iperf3 reports 0 bits/sec on the server as follows:

root@client:/# iperf3 -c 10.0.0.5 -t 10 -b 100M                                                                                                               
Connecting to host 10.0.0.5, port 5201
[  4] local 10.0.0.2 port 44502 connected to 10.0.0.5 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  87.7 KBytes   718 Kbits/sec   15   1.41 KBytes       
[  4]   1.00-2.00   sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes       
[  4]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes       
[  4]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes       
[  4]   4.00-5.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes       
[  4]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes       
[  4]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec    1   1.41 KBytes       
[  4]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes       
[  4]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes       
[  4]   9.00-10.00  sec  0.00 Bytes  0.00 bits/sec    0   1.41 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-10.00  sec  87.7 KBytes  71.8 Kbits/sec   18             sender
[  4]   0.00-10.00  sec  0.00 Bytes  0.00 bits/sec                  receiver

I get around 28 Gbps when I replace the firewall image with sonata-snort-ovs-vnf-docker in client - snort - server setup.

Note that knodir/sonata-fw-vnf image I use in the example is the same as sonata-fw-vnf-docker but also has tcpdump for debugging.

I feel there is some problem with ovs1 bridge and its ports (see firewall image Dockerfile), but I could not unearth it after 6 hours of debugging. So, any help is appreciated.

Update: I forgot to mention the main observation. Establishing iperf3 connection takes a long time (~2-3mins) and once the connection is established, the client process (iperf3 -c 10.0.0.5) on the host machine (where docker container is running) hits 100% core. strace -p <iperf3-process> shows the process is on select() call (meaning it is doing network IO), although reported throughput on the server is 0 kbps. I am not sure if this can be due to closed port issue (in firewall).

Make structure compatible to SOANTA SDK projects

• use son-package to generate son files

Improve README.md

Add service package used for SP E2E service instantiation test/demo

The two existing service package examples are used for the emulator (they reference Docker images not VM images)!

We should also provide an example package that can be used with the service platform.

I am not sure which package is used for the SP E2E integration test?

I assume there is no package yet and the NSDs/VNFDs from here are used?

Investigate Y1 required VNFs

We're focused now on choosing the Y1 demo VNFs

Automatic service packaging

Automatically pack the example services in packages/ and upload the *.son files somewhere (like it is already done for the VNFs that are pushed to the Docker registry).

Simple file server?
Catalogues?

Investigate SSH solutions

Given the Y1 VNFs chosen (see #1), the common denominator interface is using the Secured SHell.

Automatically validate NSDs/VNFDs

Jenkins job: Use the automatic schema validator and apply them to the xSDs in packages/.