1 .. This work is licensed under a Creative Commons Attribution 4.0 International License.
2 .. SPDX-License-Identifier: CC-BY-4.0
3 .. (c) Cisco Systems, Inc
9 This section covers a few examples on how to run NFVbench with multiple different settings.
10 Below are shown the most common and useful use-cases and explained some fields from a default config file.
12 How to change any NFVbench run configuration (CLI)
13 --------------------------------------------------
14 NFVbench always starts with a default configuration which can further be partially refined (overridden) by the user from the CLI or from REST requests.
16 At first have a look at the default config:
20 nfvbench --show-default-config
22 It is sometimes useful derive your own configuration from a copy of the default config:
26 nfvbench --show-default-config > nfvbench.cfg
28 At this point you can edit the copy by:
30 - removing any parameter that is not to be changed (since NFVbench will always load the default configuration, default values are not needed)
31 - edit the parameters that are to be changed changed
33 A run with the new confguration can then simply be requested using the -c option and by using the actual path of the configuration file
34 as seen from inside the container (in this example, we assume the current directory is mapped to /tmp/nfvbench in the container):
38 nfvbench -c /tmp/nfvbench/nfvbench.cfg
40 The same -c option also accepts any valid yaml or json string to override certain parameters without having to create a configuration file.
42 NFVbench also provides many configuration options as optional arguments. For example the number of flows can be specified using the --flow-count option.
44 For example, flow count can be specified in any of 3 ways:
46 - by providing a confguration file that has the flow_count value to use (-c myconfig.yaml and myconfig.yaml contains 'flow_count: 100k')
47 - by passing that yaml paremeter inline (-c "flow_count: 100k") or (-c "{flow_count: 100k}")
48 - by using the flow count optional argument (--flow-count 100k)
50 Showing the running configuration
51 ---------------------------------
53 Because configuration parameters can be overriden, it is sometimes useful to show the final configuration (after all oevrrides are done) by using the --show-config option.
54 This final configuration is also called the "running" configuration.
56 For example, this will only display the running configuration (without actually running anything):
60 nfvbench -c "{flow_count: 100k, debug: true}" --show-config
63 Connectivity and Configuration Check
64 ------------------------------------
66 NFVbench allows to test connectivity to devices used with selected flow test, for example PVP.
67 It runs the whole test, but without actually sending any traffic or influencing interface counters.
68 It is also a good way to check if everything is configured properly in the config file and what versions of components are used.
71 To verify everything works without sending any traffic, use the --no-traffic option:
79 * ``--no-traffic`` or ``-0`` : sending traffic from traffic generator is skipped
86 Fixed rate run is the most basic type of NFVbench usage. It is usually used to verify that some amount of packets can pass network components in selected flow.
88 The first example shows how to run PVP flow (default flow) with multiple different settings:
92 nfvbench -c nfvbench.cfg --no-reset --no-cleanup --rate 100000pps --duration 30 --interval 15 --json results.json
96 * ``-c nfvbench.cfg`` : path to the config file
97 * ``--no-cleanup`` : resources (networks, VMs, attached ports) are not deleted after test is finished
98 * ``--rate 100000pps`` : defines rate of packets sent by traffic generator
99 * ``--duration 30`` : specifies how long should traffic be running in seconds
100 * ``--interval 15`` : stats are checked and shown periodically (in seconds) in this interval when traffic is flowing
101 * ``--json results.json`` : collected data are stored in this file after run is finished
103 .. note:: It is your responsibility to clean up resources if needed when ``--no-cleanup`` parameter is used. You can use the nfvbench_cleanup helper script for that purpose
105 The ``--json`` parameter makes it easy to store NFVbench results. To display collected results in a table form, do:
109 nfvbench --show-summary results.json # or shortcut -ss results.json
112 Second example aims to show how to specify which supported flow to run:
116 nfvbench -c nfvbench.cfg --rate 1Mbps --inter-node --service-chain PVVP
120 * ``-c nfvbench.cfg`` : path to the config file
121 * ``--rate 1Mbps`` : defines rate of packets sent by traffic generator
122 * ``--inter-node`` : VMs are created on different compute nodes, works only with PVVP flow
123 * ``--service-chain PVVP`` or ``-sc PVVP`` : specifies type of flow to use, default is PVP
125 .. note:: When parameter ``--inter-node`` is not used or there aren't enough compute nodes, VMs are on the same compute node.
131 Parameter ``--rate`` accepts different types of values:
133 * packets per second (pps, kpps, mpps), e.g. ``1000pps`` or ``10kpps``
134 * load percentage (%), e.g. ``50%``
135 * bits per second (bps, kbps, Mbps, Gbps), e.g. ``1Gbps``, ``1000bps``
136 * NDR/PDR (ndr, pdr, ndr_pdr), e.g. ``ndr_pdr``
138 The last mentioned value, NDR/PDR, is default one and its usage is covered more below.
144 NDR and PDR test is used to determine performance of your setup, maximum packets throughput.
146 * NDR (No Drop Rate): how many packets can be sent so (almost) none of them are dropped
147 * PDR (Partial Drop Rate): how many packets can be sent so drop rate is below given limit
149 Config file contains section where settings for NDR/PDR can be set.
150 Increasing number of attempts helps to minimize a chance of traffic hiccups influencing result.
151 Other way of increasing precision is to specify longer duration for traffic to run.
155 # NDR/PDR configuration
157 # Drop rates represent the ratio of dropped packet to the total number of packets sent.
158 # Values provided here are percentages. A value of 0.01 means that at most 0.01% of all
159 # packets sent are dropped (or 1 packet every 10,000 packets sent)
161 # No Drop Rate; Default to 0.001%
163 # Partial Drop Rate; NDR should always be less than PDR
165 # The accuracy of NDR and PDR load percentiles; The actual load percentile that match NDR
166 # or PDR should be within `load_epsilon` difference than the one calculated.
169 Because NDR/PDR is the default ``--rate`` value, it's possible to run NFVbench simply like this:
173 nfvbench -c nfvbench.cfg
179 nfvbench -c nfvbench.cfg --duration 120 --json results.json
183 * ``-c nfvbench.cfg`` : path to the config file
184 * ``--duration 120`` : specifies how long should be traffic running in each iteration
185 * ``--json results.json`` : collected data are stored in this file after run is finished
191 NFVbench allows to run multiple chains at the same time. For example it is possible to run PVP service chain N-times,
192 where N can be as much as your compute power can scale. With N = 10, NFVbench will spawn 10 VMs as a part of 10 simultaneous PVP chains.
194 Number of chains is specified by ``--service-chain-count`` or ``-scc`` flag, default value is 1.
195 For example to run NFVbench with 3 PVP chains use command:
199 nfvbench -c nfvbench.cfg --rate 10000pps -scc 3
201 It is not necessary to specify service chain because PVP is set as default. PVP service chains will have 3 VMs in 3 chains with this configuration.
202 If ``-sc PVVP`` is specified instead, there would be 6 VMs in 3 chains as this service chain has 2 VMs per chain.
203 Both **single run** or **NDR/PDR** can be run as multichain. Running multichain is a scenario closer to a real life situation than just simple run.
209 NFVbench can measure the performance of 1 or more L3 service chains that are setup externally. Instead of being setup by NFVbench,
210 the complete environment (VMs and networks) has to be setup prior to running NFVbench.
212 Each external chain is made of 1 or more VNFs and has exactly 2 end network interfaces (left and right network interfaces) that are connected to 2 neutron networks (left and right networks).
213 The internal composition of a multi-VNF service chain can be arbitrary (usually linear) as far as NFVbench is concerned,
214 the only requirement is that the service chain can route L3 packets properly between the left and right networks.
216 To run NFVbench on such external service chains:
218 - explicitly tell NFVbench to use external service chain by adding ``-sc EXT`` or ``--service-chain EXT`` to NFVbench CLI options
219 - specify the number of external chains using the ``-scc`` option (defaults to 1 chain)
220 - specify the 2 end point networks of your environment in ``external_networks`` inside the config file.
221 - The two networks specified there have to exist in Neutron and will be used as the end point networks by NFVbench ('napa' and 'marin' in the diagram below)
222 - specify the router gateway IPs for the external service chains (1.1.0.2 and 2.2.0.2)
223 - specify the traffic generator gateway IPs for the external service chains (1.1.0.102 and 2.2.0.102 in diagram below)
224 - specify the packet source and destination IPs for the virtual devices that are simulated (10.0.0.0/8 and 20.0.0.0/8)
227 .. image:: images/extchain-config.svg
229 The L3 router function must be enabled in the VNF and configured to:
231 - reply to ARP requests to its public IP addresses on both left and right networks
232 - route packets from each set of remote devices toward the appropriate dest gateway IP in the traffic generator using 2 static routes (as illustrated in the diagram)
234 Upon start, NFVbench will:
235 - first retrieve the properties of the left and right networks using Neutron APIs,
236 - extract the underlying network ID (either VLAN ID or VNI if VxLAN is used),
237 - then program the TOR to stitch the 2 interfaces from the traffic generator into each end of the service chain,
238 - then generate and measure traffic.
240 Note that in the case of multiple chains, all chains end interfaces must be connected to the same two left and right networks.
241 The traffic will be load balanced across the corresponding gateway IP of these external service chains.
243 .. note:: By default, interfaces configuration (TOR, VTS, etc.) will be run by NFVbench but these can be skipped by using ``--no-int-config`` flag.
249 NFVbench always generates L3 packets from the traffic generator but allows the user to specify how many flows to generate.
250 A flow is identified by a unique src/dest MAC IP and port tuple that is sent by the traffic generator. Note that from a vswitch point of view, the
251 number of flows seen will be higher as it will be at least 4 times the number of flows sent by the traffic generator
252 (add reverse direction of vswitch to traffic generator, add flow to VM and flow from VM).
255 The number of flows will be spread roughly even between chains when more than 1 chain is being tested.
256 For example, for 11 flows and 3 chains, number of flows that will run for each chain will be 3, 4, and 4 flows respectively.
258 The number of flows is specified by ``--flow-count`` or ``-fc`` flag, the default value is 2 (1 flow in each direction).
259 To run NFVbench with 3 chains and 100 flows, use the following command:
263 nfvbench -c nfvbench.cfg --rate 10000pps -scc 3 -fc 100
266 IP addresses generated can be controlled with the following NFVbench configuration options:
270 ip_addrs: ['10.0.0.0/8', '20.0.0.0/8']
271 ip_addrs_step: 0.0.0.1
272 tg_gateway_ip_addrs: ['1.1.0.100', '2.2.0.100']
273 tg_gateway_ip_addrs_step: 0.0.0.1
274 gateway_ip_addrs: ['1.1.0.2', '2.2.0.2']
275 gateway_ip_addrs_step: 0.0.0.1
277 ``ip_addrs`` are the start of the 2 ip address ranges used by the traffic generators as the packets source and destination packets
278 where each range is associated to virtual devices simulated behind 1 physical interface of the traffic generator.
279 These can also be written in CIDR notation to represent the subnet.
281 ``tg_gateway_ip_addrs`` are the traffic generator gateway (virtual) ip addresses, all traffic to/from the virtual devices go through them.
283 ``gateway_ip_addrs`` are the 2 gateway ip address ranges of the VMs used in the external chains. They are only used with external chains and must correspond to their public IP address.
285 The corresponding ``step`` is used for ranging the IP addresses from the `ip_addrs``, ``tg_gateway_ip_addrs`` and ``gateway_ip_addrs`` base addresses.
286 0.0.0.1 is the default step for all IP ranges. In ``ip_addrs``, 'random' can be configured which tells NFVBench to generate random src/dst IP pairs in the traffic stream.
289 Traffic Config via CLI
290 ----------------------
292 While traffic configuration can modified using the config file, it became a hassle to have to change the config file everytime you need to change traffic config.
294 Traffic config can be overridden with the CLI options.
296 Here is an example of configuring traffic via CLI:
300 nfvbench --rate 10kpps --service-chain-count 2 -fs 64 -fs IMIX -fs 1518 --unidir
302 This command will run NFVbench with two streams with unidirectional flow for three packet sizes 64B, IMIX, and 1518B.
306 * ``--rate 10kpps`` : defines rate of packets sent by traffic generator (total TX rate)
307 * ``-scc 2`` or ``--service-chain-count 2`` : specifies number of parallel chains of given flow to run (default to 1)
308 * ``-fs 64`` or ``--frame-size 64``: add the specified frame size to the list of frame sizes to run
309 * ``--unidir`` : run traffic with unidirectional flow (default to bidirectional flow)
315 NFVbench will dicover the MAC addresses to use for generated frames using:
316 - either OpenStack discovery (find the MAC of an existing VM) if the loopback VM is configured to run L2 forwarding
317 - or using dynamic ARP discovery (find MAC from IP) if the loopback VM is configured to run L3 routing or in the case of external chains.
322 The nfvbench_cleanup script will cleanup resources created by NFVbench. You need to pass the OpenStack RC file in order to connect to
328 # nfvbench_cleanup -r /tmp/nfvbench/openrc
329 Discovering Storage resources...
330 Discovering Compute resources...
331 Discovering Network resources...
332 Discovering Keystone resources...
335 +-----------+-------------------+--------------------------------------+
336 | Type | Name | UUID |
337 |-----------+-------------------+--------------------------------------|
338 | flavors | nfvbench.medium | 362b2215-89d1-4f46-8b89-8e58165ff5bc |
339 | instances | nfvbench-loop-vm0 | f78dfb74-1b8e-4c5c-8d83-652a7571da95 |
340 | networks | nfvbench-net0 | 57d7e6c9-325f-4c13-9b1b-929344cc9c39 |
341 | networks | nfvbench-net1 | 2d429bcd-33fa-4aa4-9f2e-299a735177c9 |
342 +-----------+-------------------+--------------------------------------+
344 Warning: You didn't specify a resource list file as the input. The script will delete all resources shown above.
345 Are you sure? (y/n) y
348 . Waiting for 1 instances to be fully deleted...
349 . INSTANCE 1 left to be deleted, retries left=5...
350 . INSTANCE 1 left to be deleted, retries left=4...
351 + INSTANCE nfvbench-loop-vm0 is successfully deleted
352 + FLAVOR nfvbench.medium is successfully deleted
354 + Network port 075d91f3-fa6a-428c-bd3f-ebd40cd935e1 is successfully deleted
355 + Network port 3a7ccd8c-53a6-43d0-a823-4b5ca762d06e is successfully deleted
356 + NETWORK nfvbench-net0 is successfully deleted
357 + Network port 5b5a75bd-e0b5-4f81-91b9-9e216d194f48 is successfully deleted
358 + Network port cc2d8f1b-49fe-491e-9e44-6990fc57e891 is successfully deleted
359 + NETWORK nfvbench-net1 is successfully deleted