summaryrefslogtreecommitdiffstats
path: root/docs/testing/user/userguide/faq.rst
blob: f5ff6b324e9e8388650e1127459e5d4e0419f17d (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
.. This work is licensed under a Creative Commons Attribution 4.0 International License.
.. SPDX-License-Identifier: CC-BY-4.0
.. (c) Cisco Systems, Inc

Frequently Asked Questions
**************************

General Questions
=================

Can NFVbench be used with a different traffic generator than TRex?
------------------------------------------------------------------
This is possible but requires developing a new python class to manage the new traffic generator interface.

Can I connect Trex directly to my compute node?
-----------------------------------------------
That is possible but you will not be able to run more advanced use cases such as PVVP inter-node which requires 2 compute nodes.

Can I drive NFVbench using a REST interface?
--------------------------------------------
NFVbench can run in server mode and accept HTTP or WebSocket/SocketIO events to run any type of measurement (fixed rate run or NDR_PDR run)
with any run configuration.

Can I run NFVbench on a Cisco UCS-B series blade?
-------------------------------------------------
Yes provided your UCS-B series server has a Cisco VIC 1340 (with a recent firmware version).
TRex will require VIC firmware version 3.1(2) or higher for blade servers (which supports more filtering capabilities).
In this setting, the 2 physical interfaces for data plane traffic are simply hooked to the UCS-B fabric interconnect (no need to connect to a switch).

Troubleshooting
===============

TrafficClientException: End-to-end connectivity cannot be ensured
------------------------------------------------------------------
Prior to running a benchmark, NFVbench will make sure that traffic is passing in the service chain by sending a small flow of packets in each direction and verifying that they are received back at the other end.
This exception means that NFVbench cannot pass any traffic in the service chain.

The most common issues that prevent traffic from passing are:
- incorrect wiring of the NFVbench/TRex interfaces
- incorrect vlan_tagging setting in the NFVbench configuration, this needs to match how the NFVbench ports on the switch are configured (trunk or access port)
   - if the switch port is configured as access port, you must disable vlan_tagging in the NFVbench configuration
   - of the switch port is configured as trunk (recommended method), you must enable it
* +-----------------------------------------------------------------------------+ |Control Node Openstack Service High Availability - Glance Api | | | +--------------+--------------------------------------------------------------+ |test case id | OPNFV_YARDSTICK_TC047: Control node Openstack service down - | | | glance api | +--------------+--------------------------------------------------------------+ |test purpose | This test case will verify the high availability of the | | | image service provided by OpenStack (glance-api) on control | | | node. | | | | +--------------+--------------------------------------------------------------+ |test method | This test case kills the processes of glance-api service on | | | a selected control node, then checks whether the request of | | | the related Openstack command is OK and the killed processes | | | are recovered. | | | | +--------------+--------------------------------------------------------------+ |attackers | In this test case, an attacker called "kill-process" is | | | needed. This attacker includes three parameters: | | | 1) fault_type: which is used for finding the attacker's | | | scripts. It should be always set to "kill-process" in this | | | test case. | | | 2) process_name: which is the process name of the specified | | | OpenStack service. If there are multiple processes use the | | | same name on the host, all of them are killed by this | | | attacker. | | | In this case. This parameter should always set to "glance- | | | api". | | | 3) host: which is the name of a control node being attacked. | | | | | | e.g. | | | -fault_type: "kill-process" | | | -process_name: "glance-api" | | | -host: node1 | | | | +--------------+--------------------------------------------------------------+ |monitors | In this test case, two kinds of monitor are needed: | | | 1. the "openstack-cmd" monitor constantly request a specific | | | Openstack command, which needs two parameters: | | | 1) monitor_type: which is used for finding the monitor class | | | and related scritps. It should be always set to | | | "openstack-cmd" for this monitor. | | | 2) command_name: which is the command name used for request. | | | In this case, the command name should be glance related | | | commands. | | | | | | 2. the "process" monitor check whether a process is running | | | on a specific node, which needs three parameters: | | | 1) monitor_type: which used for finding the monitor class and| | | related scritps. It should be always set to "process" | | | for this monitor. | | | 2) process_name: which is the process name for monitor | | | 3) host: which is the name of the node runing the process | | | | | | e.g. | | | monitor1: | | | -monitor_type: "openstack-cmd" | | | -command_name: "glance image-list" | | | monitor2: | | | -monitor_type: "process" | | | -process_name: "glance-api" | | | -host: node1 | | | | +--------------+--------------------------------------------------------------+ |metrics | In this test case, there are two metrics: | | | 1)service_outage_time: which indicates the maximum outage | | | time (seconds) of the specified Openstack command request. | | | 2)process_recover_time: which indicates the maximun time | | | (seconds) from the process being killed to recovered | | | | +--------------+--------------------------------------------------------------+ |test tool | Developed by the project. Please see folder: | | | "yardstick/benchmark/scenarios/availability/ha_tools" | | | | +--------------+--------------------------------------------------------------+ |references | ETSI NFV REL001 | | | | +--------------+--------------------------------------------------------------+ |configuration | This test case needs two configuration files: | | | 1) test case file: opnfv_yardstick_tc047.yaml | | | -Attackers: see above "attackers" discription | | | -waiting_time: which is the time (seconds) from the process | | | being killed to stoping monitors the monitors | | | -Monitors: see above "monitors" discription | | | -SLA: see above "metrics" discription | | | | | | 2)POD file: pod.yaml | | | The POD configuration should record on pod.yaml first. | | | the "host" item in this test case will use the node name in | | | the pod.yaml. | | | | +--------------+--------------------------------------------------------------+ |test sequence | description and expected result | | | | +--------------+--------------------------------------------------------------+ |step 1 | start monitors: | | | each monitor will run with independently process | | | | | | Result: The monitor info will be collected. | | | | +--------------+--------------------------------------------------------------+ |step 2 | do attacker: connect the host through SSH, and then execute | | | the kill process script with param value specified by | | | "process_name" | | | | | | Result: Process will be killed. | | | | +--------------+--------------------------------------------------------------+ |step 3 | stop monitors after a period of time specified by | | | "waiting_time" | | | | | | Result: The monitor info will be aggregated. | | | | +--------------+--------------------------------------------------------------+ |step 4 | verify the SLA | | | | | | Result: The test case is passed or not. | | | | +--------------+--------------------------------------------------------------+ |post-action | It is the action when the test cases exist. It will check the| | | status of the specified process on the host, and restart the | | | process if it is not running for next test cases | | | | +--------------+--------------------------------------------------------------+ |test verdict | Fails only if SLA is not passed, or if there is a test case | | | execution problem. | | | | +--------------+--------------------------------------------------------------+