2 # NFVbench default configuration file
4 # This configuration file is ALWAYS loaded by NFVbench and should never be modified by users.
5 # To specify your own property values, always define them in a separate config file
6 # and pass that file to the script using -c or --config <file>
7 # Property values in that config file will override the default values in the current file
10 # IMPORTANT CUSTOMIZATION NOTES
11 # There are roughly 2 types of NFVbench config based on the OpenStack encaps used:
12 # - VLAN (OVS, OVS-DPDK, ML2/VPP)
13 # Many of the fields to customize are relevant to only 1 of the 2 encaps
14 # These will be clearly labeled "VxLAN only" or "VLAN only"
15 # Fields that are not applicable will not be used by NFVbench and can be left empty
17 # All fields are applicable to all encaps/traffic generators unless explicitly marked otherwise.
18 # Fields that can be over-ridden at the command line are marked with the corresponding
19 # option, e.g. "--interval"
22 # The OpenStack openrc file to use - must be a valid full pathname. If running
23 # in a container, this path must be valid in the container.
25 # The only case where this field can be empty is when measuring a system that does not run
26 # OpenStack or when OpenStack APIs are not accessible or OpenStack APis use is not
27 # desirable. In that case the EXT service chain must be used.
29 # If openrc is not admin some parameters are mandatory and must be filled with valid values in config file such as :
31 # - hypervisor_hostname
35 # Forwarder to use in nfvbenchvm image. Available options: ['vpp', 'testpmd']
38 # By default (empty) NFVbench will try to locate a VM image file
39 # from the package root directory named "nfvbench-<version>.qcow2" and
40 # upload that file. The image name will be "nfvbench-<version>"
41 # This can be overridden by specifying here a pathname of a file
42 # that follows the same naming convention.
43 # In most cases, this field should be left empty as the packaging should
44 # include the proper VM image file
47 # Name of the flavor to use for the loopback VMs
49 # If the provided name is an exact match to a flavor name known by OpenStack
50 # (as shown from 'nova flavor-list'), that flavor will be reused.
51 # Otherwise, a new flavor will be created with attributes listed below.
52 flavor_type: 'nfvbench.medium'
54 # Custom flavor attributes
56 # Number of vCPUs for the flavor
58 # Memory for the flavor in MB
60 # Size of local disk in GB
62 # metadata are supported and can be added if needed, optional
63 # note that if your openstack does not have NUMA optimization
64 # (cpu pinning and huge pages)
65 # you must comment out extra_specs completely otherwise
66 # loopback VM creation will fail
68 "hw:cpu_policy": dedicated
69 "hw:mem_page_size": large
71 # Name of the availability zone to use for the test VMs
72 # Must be one of the zones listed by 'nova availability-zone-list'
73 # availability_zone: 'nova'
74 # If openrc is not admin set a valid value
76 # To force placement on a given hypervisor, set the name here
77 # (if multiple names are provided, the first will be used)
78 # Leave empty to let openstack pick the hypervisor
80 # If openrc is not admin set a valid value for hypervisor hostname
81 # Example of value: hypervisor_hostname: "server1"
84 # Type of service chain to run, possible options are PVP, PVVP and EXT
85 # PVP - port to VM to port
86 # PVVP - port to VM to VM to port
87 # EXT - external chain used only for running traffic and checking traffic generator counters,
88 # all other parts of chain must be configured manually
89 # Can be overriden by --service-chain
92 # Total number of service chains, every chain has own traffic stream
93 # Can be overriden by --service-chain-count
94 service_chain_count: 1
96 # Specifies if all chains share the same right/left/middle networks
97 service_chain_shared_net: false
99 # Total number of traffic flows for all chains and directions generated by the traffic generator.
100 # Minimum is '2 * service_chain_count', it is automatically adjusted if too small
101 # value was configured. Must be even.
102 # Every flow has packets with different IPs in headers
103 # Can be overriden by --flow-count
106 # set to true if service chains should use SRIOV
107 # This requires SRIOV to be available on compute nodes
110 # Perform port to port loopback (direct or through switch)
111 # Should be used with EXT service chain and no ARP (no_arp: true)
112 # When enabled, the vlans property must contain the same VLAN id for all chains.
113 # Can be overriden by --l2-loopback
116 # Resources created by NFVbench will not be removed
117 # Can be overriden by --no-cleanup
120 # Configuration for traffic generator
122 # Name of the traffic generator, only for informational purposes
123 host_name: 'nfvbench_tg'
124 # this is the default traffic generator profile to use
125 # the name must be defined under generator_profile
126 # you can override the traffic generator to use using the
127 # -g or --traffic-gen option at the command line
128 default_profile: trex-local
130 # IP addresses for L3 traffic.
131 # This section describes the addresses to use to fill in the UDP packets sent by the
132 # traffic generator. If you VNFs are L2 forwarders, these fields below do not need to change.
133 # If your VNFs are L3 routers, the fields below must match the static routes in your VNFs
134 # so that UDP packets can be routed back to the peer port of the traffic generator.
136 # All of the IPs are used as base for IP sequence computed based on chain or flow count.
137 # (sim-devices-left)---(tg-gateway-left)---(vnf-left)- ...
138 # -(vnf-right)---(tg-gateway-right)---(sim-devices-right)
140 # `ip_addrs` base IPs used as src and dst in packet header, quantity depends on flow count
141 # these are used for addressing virtual devices simulated by the traffic generator
142 # and be a different subnet than tg_gateway_ip_addrs and gateway_ip_addrs
143 # `ip_addrs_step`: step for generating IP sequence. Use "random" for random patterns, default is 0.0.0.1.
144 ip_addrs: ['10.0.0.0/8', '20.0.0.0/8']
145 ip_addrs_step: 0.0.0.1
146 # `tg_gateway_ip_addrs` base IP for traffic generator ports in the left and right networks to the VNFs
147 # chain count consecutive IP addresses spaced by tg_gateway_ip_addrs_step will be used
148 # `tg_gateway_ip_addrs__step`: step for generating traffic generator gateway sequences. default is 0.0.0.1
149 tg_gateway_ip_addrs: ['1.1.0.100', '2.2.0.100']
150 tg_gateway_ip_addrs_step: 0.0.0.1
151 # `gateway_ip_addrs`: base IPs of VNF router gateways (left and right), quantity used depends on chain count
152 # must correspond to the public IP on the left and right networks
153 # for each left-most and right-most VNF of every chain.
154 # must be the same subnet but not same IP as tg_gateway_ip_addrs.
155 # chain count consecutive IP addresses spaced by gateway_ip_addrs_step will be used
156 # `gateway_ip_addrs_step`: step for generating router gateway sequences. default is 0.0.0.1
157 gateway_ip_addrs: ['1.1.0.2', '2.2.0.2']
158 gateway_ip_addrs_step: 0.0.0.1
159 # `udp_src_port`: the source port for sending UDP traffic, default is picked by TRex (53)
160 # `udp_dst_port`: the destination port for sending UDP traffic, default is picked by TRex (53)
164 # VxLAN only: optionally specify what VLAN tag to use for the VxLAN overlay
165 # This is used if the vxlan tunnels are running on a specific VLAN.
166 # Leave empty if there is no VLAN tagging required, or specify the VLAN id to use
167 # for all VxLAN tunneled traffic
169 # VxLAN only: local/source vteps IP addresses for port 0 and 1 ['10.1.1.230', '10.1.1.231']
171 # VxLAN only: remote IP address of the remote VTEPs that terminate all tunnels originating from local VTEPs
174 # L2 ADDRESSING OF UDP PACKETS
175 # Lists of dest MAC addresses to use on each traffic generator port (one dest MAC per chain)
176 # Leave empty for PVP, PVVP, EXT with ARP
177 # Only used when `service_chain` is EXT and `no_arp` is true.
178 # - If both lists are empty the far end MAC of the traffic generator will be used for left and right
179 # (this is typicaly used to loop back on the first hop switch or using a loopback cable)
180 # - The length of each list must match the number of chains being used!
181 # - The index of each list must correspond to the chain index to ensure proper pairing.
182 # - Below is an example of using two chains:
183 # - mac_addrs_left: ['00:00:00:00:01:00', '00:00:00:00:02:00']
184 # - mac_addrs_right: ['00:00:00:00:01:01', '00:00:00:00:02:01']
185 # UDP packets sent on port 0 will use dest MAC '00:00:00:00:01:00' for chain #0 and
186 # dest MAC '00:00:00:00:02:00' for chain #1
187 # UDP packets sent on port 1 will use dest MAC '00:00:00:00:01:01' for chain #0 and
188 # dest MAC '00:00:00:00:02:01' for chain #1
189 # It is expected that the looping device (L2 forwarder) will rewrite the src and dst MAC
190 # of the looping UDP packet so that it can reach back to the peer port of the traffic
196 # Traffic Generator Profiles
197 # In case you have multiple testbeds or traffic generators,
198 # you can define one traffic generator profile per testbed/traffic generator.
199 # In most cases you only need to fill in the pci address for the 2 ports used by the
200 # traffic generator and leave all other fields unchanged
202 # Generator profiles are listed in the following format:
203 # `name`: Traffic generator profile name (use a unique name, no space or special character)
204 # Do not change this field
205 # `tool`: Traffic generator tool to be used (currently supported is `TRex`).
206 # Do not change this field
207 # `ip`: IP address of the traffic generator.
208 # The default loopback address is used when the traffic generator runs on the same host
210 # `cores`: Specify the number of cores for running the TRex traffic generator.
211 # ONLY applies to trex-local.
212 # `software_mode`: Advice TRex to use software mode which provides the best compability. But
213 # note that TRex will not use any hardware acceleration technology under
214 # software mode, therefore the performance of TRex will be significantly
215 # lower. ONLY applies to trex-local.
216 # Recommended to leave the default value (false)
217 # `interfaces`: Configuration of traffic generator interfaces.
218 # `interfaces.port`: The port of the traffic generator to be used (leave as 0 and 1 resp.)
219 # `interfaces.switch_port`: Leave empty (deprecated)
220 # `interfaces.pci`: The PCI address of the intel NIC interface associated to this port
221 # This field is required and cannot be empty
222 # Use lspci to list the PCI address of all devices
223 # Example of value: "0000:5e:00.0"
224 # `intf_speed`: The speed of the interfaces used by the traffic generator (per direction).
225 # Empty value (default) to use the speed discovered by the traffic generator.
226 # Recommended to leave this field empty.
227 # Do not use unless you want to override the speed discovered by the
228 # traffic generator. Expected format: 10Gbps
245 # Simpler override for trex core count and mbuf multilier factor
246 # if empty defaults to the one specified in generator_profile.cores
249 # mbuffer ratio to use for TRex (see TRex documentation for more details)
252 # -----------------------------------------------------------------------------
253 # These variables are not likely to be changed
255 # Number of seconds to wait for VMs to pass traffic in both directions
256 check_traffic_time_sec: 200
258 # General retry count
259 generic_retry_count: 100
261 # General poll period
264 # name of the loop VM
265 loop_vm_name: 'nfvbench-loop-vm'
267 # Default names, subnets and CIDRs for PVP/PVVP networks (openstack only)
269 # If a network with given name already exists it will be reused.
270 # - PVP only uses left and right
271 # - PVVP uses left, middle and right
272 # - for EXT chains, this structure is not relevant - refer to external_networks
273 # Otherwise a new internal network will be created with that name, subnet and CIDR.
275 # network_type must be 'vlan' (for VLAN and SRIOV) or 'vxlan' (for VxLAN)
276 # all 3 networks must use the same network type in this release
277 # segmentation_id can be set to enforce a specific segmentation id (vlan ID or VNI if vxlan)
278 # by default (empty) the segmentation id will be assigned by Neutron.
279 # If specified, it must be unique for each network
280 # For multi-chaining, see notes below
281 # physical_network can be set to pick a specific phsyical network - by default (empty) the
282 # default physical network will be picked
283 # SR-IOV: both physical_network and VLAN segmentation ID must be provided
284 # VxLAN: the VNI must generally be provided (except special Neutron VxLAN implementations)
286 # For example to setup 1xPVP using 2 different SR-IOV ports, you must put the appropriate physnet
287 # names under left.physical_network and right.physical_network.
288 # For multi-chaining and non shared networks,
289 # Example of override configuration to force PVP to run on 2 SRIOV ports (phys_sriov0 and phys_sriov1)
290 # using VLAN ID 2000 and 2001:
293 # segmentation_id: 2000
294 # physical_network: phys_sriov0
296 # segmentation_id: 2001
297 # physical_network: phys_sriov1
299 # For multi-chaining and non shared network mode (VLAN, SRIOV, VxLAN):
300 # - the segmentation_id field if provided must be a list of values (as many as chains)
301 # - segmentation_id auto-indexing:
302 # the segmentation_id field can also be a single value that represents the base value from which
303 # values for each chain is derived using the chain ID as an offset. For example
304 # if 2000 is specified, NFVbench will use 2000 for chain 0, 2001 for chain 1 etc...
305 # The ranges of all the networks must not overlap.
306 # - the physical_network can be a single name (all VFs to be allocated on same physnet)
307 # of a list of physnet names to use different PFs
309 # Example of 2-chain configuration:
312 # segmentation_id: [2000, 2001]
313 # physical_network: phys_sriov0
315 # segmentation_id: [2010, 2011]
316 # physical_network: phys_sriov1
318 # Equivalent to (using auto-indexing):
321 # segmentation_id: 2000
322 # physical_network: phys_sriov0
324 # segmentation_id: 2010
325 # physical_network: phys_sriov1
329 name: 'nfvbench-lnet'
330 subnet: 'nfvbench-lsubnet'
331 cidr: '192.168.1.0/24'
336 name: 'nfvbench-rnet'
337 subnet: 'nfvbench-rsubnet'
338 cidr: '192.168.2.0/24'
343 name: 'nfvbench-mnet'
344 subnet: 'nfvbench-msubnet'
345 cidr: '192.168.3.0/24'
350 # In the scenario of PVVP + SRIOV, there is choice of how the traffic will be
351 # handled in the middle network. The default (false) will use vswitch, while
352 # SRIOV can be used by toggling below setting.
353 use_sriov_middle_net: false
355 # EXT chain only. Prefix names of edge networks which will be used to send traffic via traffic generator.
357 # If service_chain_shared_net is true, the left and right networks must pre-exist and match exactly by name.
359 # If service_chain_shared_net is false, each chain must have its own pre-existing left and right networks.
360 # An index will be appended to each network name to form the final name:
361 # ext-lnet0 ext-rnet0 for chain #0
362 # ext-lnet1 ext-rnet1 for chain #1
368 # Use 'true' to enable VXLAN encapsulation support and sent by the traffic generator
369 # When this option enabled internal networks 'network type' parameter value should be 'vxlan'
372 # Use 'true' to enable VLAN tagging of packets generated and sent by the traffic generator
373 # Leave empty or set to false if you do not want the traffic generator to insert the VLAN tag (this is
374 # needed for example if VLAN tagging is enabled on switch (access mode) or if you want to hook
375 # directly to a NIC).
376 # By default is set to true (which is the nominal use case with TOR and trunk mode to Trex ports)
377 # If VxLAN is enabled, this option should be set to false (vlan tagging for encapsulated packets
378 # is not supported). Use the vtep_vlan option to enable vlan tagging for the VxLAN overlay network.
381 # Used only in the case of EXT chain and no openstack or not admin access to specify the VLAN IDs to use.
382 # This property is ignored when OpenStakc is used or in the case of l2-loopback.
383 # If OpenStack is used leave the list empty, VLAN IDs are retrieved from OpenStack networks using Neutron API.
384 # If networks are shared across all chains (service_chain_shared_net=true), the list should have exactly 2 values
385 # If networks are not shared across chains (service_chain_shared_net=false), the list should have
387 # In the special case of l2-loopback the list should have the same VLAN id for all chains
389 # [1998, 1999] left network uses vlan 1998 right network uses vlan 1999
390 # [[1,2],[3,4]] chain 0 left vlan 1, right vlan 2 - chain 1 left vlan 3 right vlan 4
391 # [1010, 1010] same VLAN id with l2-loopback enabled
395 # ARP is used to discover the MAC address of VNFs that run L3 routing.
396 # Used only with EXT chain.
397 # False (default): ARP requests are sent to find out dest MAC addresses.
398 # True: do not send ARP but use provisioned dest macs instead
399 # (see mac_addrs_left and mac_addrs_right)
403 # You can add here more profiles as needed
404 # `l2frame_size` can be specified in any none zero integer value to represent the size in bytes
405 # of the L2 frame, or "IMIX" to represent the standard 3-packet size mixed sequence (IMIX1).
407 - name: traffic_profile_64B
409 - name: traffic_profile_IMIX
410 l2frame_size: ['IMIX']
411 - name: traffic_profile_1518B
412 l2frame_size: ['1518']
413 - name: traffic_profile_3sizes
414 l2frame_size: ['64', 'IMIX', '1518']
416 # Traffic Configuration
417 # bidirectional: to have traffic generated from both direction, set bidirectional to true
418 # profile: must be one of the profiles defined in traffic_profile
419 # The traffic profile can be overriden with the options --frame-size and --uni-dir
422 profile: traffic_profile_64B
424 # Check config and connectivity only - do not generate traffic
425 # Can be overriden by --no-traffic
430 # The rate pps for traffic going in reverse direction in case of unidirectional flow. Default to 1.
431 unidir_reverse_traffic_pps: 1
433 # The rate specifies if NFVbench should determine the NDR/PDR
434 # or if NFVbench should just generate traffic at a given fixed rate
435 # for a given duration (called "single run" mode)
436 # Supported rate format:
437 # NDR/PDR test: `ndr`, `pdr`, `ndr_pdr` (default)
438 # Or for single run mode:
439 # Packet per second: pps (e.g. `50pps`)
440 # Bits per second: bps, kbps, Mbps, etc (e.g. `1Gbps`, `1000bps`)
441 # Load percentage: % (e.g. `50%`)
442 # Can be overridden by --rate
445 # Default run duration (single run at given rate only)
446 # Can be overridden by --duration
449 # Interval between intermediate reports when interval reporting is enabled
450 # Can be overridden by --interval
453 # Default pause between iterations of a binary search (NDR/PDR)
456 # NDR / PDR configuration
458 # Drop rates represent the ratio of dropped packet to the total number of packets sent.
459 # Values provided here are percentages. A value of 0.01 means that at most 0.01% of all
460 # packets sent are dropped (or 1 packet every 10,000 packets sent)
462 # No Drop Rate in percentage; Default to 0.001%
464 # Partial Drop Rate in percentage; NDR should always be less than PDR
466 # The accuracy of NDR and PDR as a percnetage of line rate; The exact NDR
467 # or PDR should be within `load_epsilon` line rate % from the one calculated.
468 # For example, with a value 0.1, and a line rate of 10Gbps, the accuracy
469 # of NDR and PDR will be within 0.1% Of 10Gbps or 10Mbps.
470 # The lower the value the more iterations and the longer it will take to find the NDR/PDR.
471 # In practice, due to the precision of the traffic generator it is not recommended to
472 # set it to lower than 0.1
475 # Location where to store results in a JSON format. Must be container specific path.
476 # Can be overriden by --json
479 # Location where to store results in the NFVbench standard JSON format:
480 # <service-chain-type>-<service-chain-count>-<flow-count>-<packet-sizes>.json
481 # Example: PVP-1-10-64-IMIX.json
482 # Must be container specific path.
483 # Can be overriden by --std-json
486 # Prints debug messages (verbose mode)
487 # Can be overriden by --debug
490 # Set to a valid path name if logging to file is to be enabled
491 # Defaults to disabled
494 # When enabled, all results and/or logs will be sent to a fluentd servers at the requested IPs and ports
495 # A list of one or more fluentd servers identified by their IPs and port numbers should be given.
496 # For each recipient it is possible to enable both sending logs and performance
497 # results, or enable either logs or performance results. For enabling logs or results logging_tag or
498 # result_tag should be set.
501 # by default (logging_tag is empty) nfvbench log messages are not sent to fluentd
502 # to enable logging to fluents, specify a valid fluentd tag name to be used for the
506 # by default (result_tag is empty) nfvbench results are not sent to fluentd
507 # to enable sending nfvbench results to fluentd, specify a valid fluentd tag name
508 # to be used for the results records, which is different than logging_tag
511 # IP address of the server, defaults to loopback
514 # port # to use, by default, use the default fluentd forward port
517 # by default (logging_tag is empty) nfvbench log messages are not sent to fluentd
518 # to enable logging to fluents, specify a valid fluentd tag name to be used for the
521 # Module and class name of factory which will be used to provide classes dynamically for other components.
522 factory_module: 'nfvbench.factory'
523 factory_class: 'BasicFactory'
525 # Custom label added for every perf record generated during this run.
526 # Can be overriden by --user-label
530 # THESE FIELDS SHOULD BE USED VERY RARELY
532 # Skip vswitch configuration and retrieving of stats
533 # Can be overriden by --no-vswitch-access
534 # Should be left to the default value (false)
535 no_vswitch_access: false