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"
21 # The OpenStack openrc file to use (must be a valid full pathname). If running
22 # in a container, this path must be valid in the container.
24 # The only case where this field can be empty is when measuring a system that does not run
25 # OpenStack or when OpenStack APIs are not accessible or OpenStack APis use is not
26 # desirable. In that case the EXT service chain must be used.
29 # Forwarder to use in nfvbenchvm image. Available options: ['vpp', 'testpmd']
32 # By default (empty) NFVBench will try to locate a VM image file
33 # from the package root directory named "nfvbench-<version>.qcow2" and
34 # upload that file. The image name will be "nfvbench-<version>"
35 # This can be overridden by specifying here a pathname of a file
36 # that follows the same naming convention.
37 # In most cases, this field should be left empty as the packaging should
38 # include the proper VM image file
41 # Name of the flavor to use for the loopback VMs
43 # If the provided name is an exact match to a flavor name known by OpenStack
44 # (as shown from 'nova flavor-list'), that flavor will be reused.
45 # Otherwise, a new flavor will be created with attributes listed below.
46 flavor_type: 'nfvbench.medium'
48 # Custom flavor attributes
50 # Number of vCPUs for the flavor
52 # Memory for the flavor in MB
54 # Size of local disk in GB
56 # metadata are supported and can be added if needed, optional
57 # note that if your openstack does not have NUMA optimization
58 # (cpu pinning and huge pages)
59 # you must comment out extra_specs completely otherwise
60 # loopback VM creation will fail
62 "hw:cpu_policy": dedicated
63 "hw:mem_page_size": large
65 # Name of the availability zone to use for the test VMs
66 # Must be one of the zones listed by 'nova availability-zone-list'
67 # If the selected zone contains only 1 compute node and PVVP inter-node flow is selected,
68 # application will use intra-node PVVP flow.
69 # List of compute nodes can be specified, must be in given availability zone if not empty
70 #availability_zone: 'nova'
75 # Credentials for SSH connection to TOR switches.
77 # Leave type empty or switch list empty to skip TOR switches configuration.
78 # Preferably use 'no_tor_access' to achieve the same behavior.
79 # (skipping TOR config will require the user to pre-stitch the traffic generator interfaces
80 # to the service chain under test, needed only if configured in access mode)
82 # Switches are only needed if type is not empty.
83 # You can configure 0, 1 or 2 switches
84 # no switch: in this case NFVbench will not attempt to ssh to the switch
85 # and stitching of traffic must be done externally
86 # 1 switch: this assumes that both traffic generator interfaces are wired to the same switch
87 # 2 switches: this is the recommended setting wuth redundant switches, in this case each
88 # traffic generator interface must be wired to a different switch
95 # Skip TOR switch configuration and retrieving of stats
96 # Can be overriden by --no-tor-access
99 # Skip vswitch configuration and retrieving of stats
100 # Can be overriden by --no-vswitch-access
101 no_vswitch_access: false
103 # Type of service chain to run, possible options are PVP, PVVP and EXT
104 # PVP - port to VM to port
105 # PVVP - port to VM to VM to port
106 # EXT - external chain used only for running traffic and checking traffic generator counters,
107 # all other parts of chain must be configured manually
108 # Can be overriden by --service-chain
111 # Total number of service chains, every chain has own traffic stream
112 # Can be overriden by --service-chain-count
113 service_chain_count: 1
115 # Total number of traffic flows for all chains and directions generated by the traffic generator.
116 # Minimum is '2 * service_chain_count', it is automatically adjusted if too small
117 # value was configured. Must be even.
118 # Every flow has packets with different IPs in headers
119 # Can be overriden by --flow-count
122 # Used by PVVP chain to spawn VMs on different compute nodes
123 # Can be overriden by --inter-node
126 # set to true if service chains should use SRIOV
127 # This requires SRIOV to be available on compute nodes
130 # Skip interfaces config on EXT service chain
131 # Can be overriden by --no-int-config
134 # Resources created by NFVbench will not be removed
135 # Can be overriden by --no-cleanup
138 # Configuration for traffic generator
140 # Name of the traffic generator, only for informational purposes
141 host_name: 'nfvbench_tg'
142 # this is the default traffic generator profile to use
143 # the name must be defined under generator_profile
144 # you can override the traffic generator to use using the
145 # -g or --traffic-gen option at the command line
146 default_profile: trex-local
148 # IP addresses for L3 traffic.
149 # All of the IPs are used as base for IP sequence computed based on chain or flow count.
151 # `ip_addrs` base IPs used as src and dst in packet header, quantity depends on flow count
152 # `ip_addrs_step`: step for generating IP sequence. Use "random" for random patterns, default is 0.0.0.1.
153 # `tg_gateway_ip_addrs` base IPs for traffic generator ports, quantity depends on chain count
154 # `tg_gateway_ip_addrs__step`: step for generating traffic generator gateway sequences. default is 0.0.0.1
155 # `gateway_ip_addrs`: base IPs of router gateways on both networks, quantity depends on chain count
156 # `gateway_ip_addrs_step`: step for generating router gateway sequences. default is 0.0.0.1
157 # `udp_src_port`: the source port for sending UDP traffic, default is picked by TRex (53)
158 # `udp_dst_port`: the destination port for sending UDP traffic, default is picked by TRex (53)
159 ip_addrs: ['10.0.0.0/8', '20.0.0.0/8']
160 ip_addrs_step: 0.0.0.1
161 tg_gateway_ip_addrs: ['1.1.0.100', '2.2.0.100']
162 tg_gateway_ip_addrs_step: 0.0.0.1
163 gateway_ip_addrs: ['1.1.0.2', '2.2.0.2']
164 gateway_ip_addrs_step: 0.0.0.1
168 # Traffic Generator Profiles
169 # In case you have multiple testbeds or traffic generators,
170 # you can define one traffic generator profile per testbed/traffic generator.
172 # Generator profiles are listed in the following format:
173 # `name`: Traffic generator profile name (use a unique name, no space or special character)
174 # `tool`: Traffic generator tool to be used (currently supported is `TRex`).
175 # `ip`: IP address of the traffic generator.
176 # `cores`: Specify the number of cores for TRex traffic generator. ONLY applies to trex-local.
177 # `software_mode`: Advice TRex to use software mode which provides the best compability. But
178 # note that TRex will not use any hardware acceleration technology under
179 # software mode, therefore the performance of TRex will be significantly
180 # lower. ONLY applies to trex-local.
181 # `interfaces`: Configuration of traffic generator interfaces.
182 # `interfaces.port`: The port of the traffic generator to be used (leave as 0 and 1 resp.)
183 # `interfaces.switch_port`: Leave empty (reserved for advanced use cases)
184 # `interfaces.pci`: The PCI address of the intel NIC interface associated to this port
185 # `intf_speed`: The speed of the interfaces used by the traffic generator (per direction).
202 # -----------------------------------------------------------------------------
203 # These variables are not likely to be changed
205 # Number of seconds to wait for VMs to pass traffic in both directions
206 check_traffic_time_sec: 200
208 # General retry count
209 generic_retry_count: 100
211 # General poll period
214 # name of the loop VM
215 loop_vm_name: 'nfvbench-loop-vm'
217 # Default names, subnets and CIDRs for PVP/PVVP networks
218 # If a network with given name already exists it will be reused.
219 # - PVP only uses left and right
220 # - PVVP uses left, middle and right
221 # - for EXT chains, this structure is not relevant - refer to external_networks
222 # Otherwise a new internal network will be created with that name, subnet and CIDR.
224 # segmentation_id can be set to enforce a specific VLAN id - by default (empty) the VLAN id
225 # will be assigned by Neutron.
226 # Must be unique for each network
227 # physical_network can be set to pick a specific phsyical network - by default (empty) the
228 # default physical network will be picked
229 # In the case of SR-IOV, both physical_network and segmentation ID must be provided
230 # For example to setup PVP using 2 different SR-IOV ports, you must put the appropriate physnet
231 # names under left.physical_network and right.physical_network.
232 # Example of override configuration to force PVP to run on 2 SRIOV ports (phys_sriov0 and phys_sriov1)
233 # using VLAN ID 2000 and 2001:
236 # segmentation_id: 2000
237 # physical_network: phys_sriov0
239 # segmentation_id: 2001
240 # physical_network: phys_sriov1
244 name: 'nfvbench-net0'
245 subnet: 'nfvbench-subnet0'
246 cidr: '192.168.1.0/24'
251 name: 'nfvbench-net1'
252 subnet: 'nfvbench-subnet1'
253 cidr: '192.168.2.0/24'
258 name: 'nfvbench-net2'
259 subnet: 'nfvbench-subnet2'
260 cidr: '192.168.3.0/24'
265 # In the scenario of PVVP + SRIOV, there is choice of how the traffic will be
266 # handled in the middle network. The default (false) will use vswitch, while
267 # SRIOV can be used by toggling below setting.
268 use_sriov_middle_net: false
270 # EXT chain only. Names of edge networks which will be used to send traffic via traffic generator.
272 left: 'nfvbench-net0'
273 right: 'nfvbench-net1'
275 # Use 'true' to enable VLAN tagging of packets generated and sent by the traffic generator
276 # Leave empty you do not want the traffic generator to insert the VLAN tag. This is
277 # needed for example if VLAN tagging is enabled on switch (trunk mode) or if you want to hook directly to a NIC
278 # By default is set to true (which is the nominal use case with TOR and trunk mode to Trex)
281 # Specify only when you want to override VLAN IDs used for tagging with own values (exactly 2).
282 # Default behavior of VLAN tagging is to retrieve VLAN IDs from OpenStack networks provided above.
283 # In case of VxLAN this setting is ignored and only vtep_vlan from traffic generator profile is used.
284 # Example: [1998, 1999]
287 # Used only with EXT chain. MAC addresses of traffic generator ports are used as destination
288 # if 'no_arp' is set to 'true'. Otherwise ARP requests are sent to find out destination MAC addresses.
292 # You can add here more profiles as needed
293 # `l2frame_size` can be specified in any none zero integer value to represent the size in bytes
294 # of the L2 frame, or "IMIX" to represent the standard 3-packet size mixed sequence (IMIX1).
296 - name: traffic_profile_64B
298 - name: traffic_profile_IMIX
299 l2frame_size: ['IMIX']
300 - name: traffic_profile_1518B
301 l2frame_size: ['1518']
302 - name: traffic_profile_3sizes
303 l2frame_size: ['64', 'IMIX', '1518']
305 # Traffic Configuration
306 # bidirectional: to have traffic generated from both direction, set bidirectional to true
307 # profile: must be one of the profiles defined in traffic_profile
308 # The traffic profile can be overriden with the options --frame-size and --uni-dir
311 profile: traffic_profile_64B
313 # Check config and connectivity only - do not generate traffic
314 # Can be overriden by --no-traffic
317 # Do not reset tx/rx counters prior to running
318 # Can be overriden by --no-reset
323 # The rate pps for traffic going in reverse direction in case of unidirectional flow. Default to 1.
324 unidir_reverse_traffic_pps: 1
326 # The rate specifies if NFVbench should determine the NDR/PDR
327 # or if NFVbench should just generate traffic at a given fixed rate
328 # for a given duration (called "single run" mode)
329 # Supported rate format:
330 # NDR/PDR test: `ndr`, `pdr`, `ndr_pdr` (default)
331 # Or for single run mode:
332 # Packet per second: pps (e.g. `50pps`)
333 # Bits per second: bps, kbps, Mbps, etc (e.g. `1Gbps`, `1000bps`)
334 # Load percentage: % (e.g. `50%`)
335 # Can be overridden by --rate
338 # Default run duration (single run at given rate only)
339 # Can be overridden by --duration
342 # Interval between intermediate reports when interval reporting is enabled
343 # Can be overridden by --interval
346 # NDR / PDR configuration
348 # Drop rates represent the ratio of dropped packet to the total number of packets sent.
349 # Values provided here are percentages. A value of 0.01 means that at most 0.01% of all
350 # packets sent are dropped (or 1 packet every 10,000 packets sent)
352 # No Drop Rate in percentage; Default to 0.001%
354 # Partial Drop Rate in percentage; NDR should always be less than PDR
356 # The accuracy of NDR and PDR as a percnetage of line rate; The exact NDR
357 # or PDR should be within `load_epsilon` line rate % from the one calculated.
358 # For example, with a value 0.1, and a line rate of 10Gbps, the accuracy
359 # of NDR and PDR will be within 0.1% Of 10Gbps or 10Mbps.
360 # The lower the value the more iterations and the longer it will take to find the NDR/PDR.
361 # In practice, due to the precision of the traffic generator it is not recommended to
362 # set it to lower than 0.1
365 # Location where to store results in a JSON format. Must be container specific path.
366 # Can be overriden by --json
369 # Location where to store results in the NFVbench standard JSON format:
370 # <service-chain-type>-<service-chain-count>-<flow-count>-<packet-sizes>.json
371 # Example: PVP-1-10-64-IMIX.json
372 # Must be container specific path.
373 # Can be overriden by --std-json
376 # Prints debug messages (verbose mode)
377 # Can be overriden by --debug
380 # Set to a valid path name if logging to file is to be enabled
381 # Defaults to disabled
384 # When enabled, all results and/or logs will be sent to a fluentd servers at the requested IPs and ports
385 # A list of one or more fluentd servers identified by their IPs and port numbers should be given.
386 # For each recipient it is possible to enable both sending logs and performance
387 # results, or enable either logs or performance results. For enabling logs or results logging_tag or
388 # result_tag should be set.
391 # by default (logging_tag is empty) nfvbench log messages are not sent to fluentd
392 # to enable logging to fluents, specify a valid fluentd tag name to be used for the
396 # by default (result_tag is empty) nfvbench results are not sent to fluentd
397 # to enable sending nfvbench results to fluentd, specify a valid fluentd tag name
398 # to be used for the results records, which is different than logging_tag
401 # IP address of the server, defaults to loopback
404 # port # to use, by default, use the default fluentd forward port
407 # by default (logging_tag is empty) nfvbench log messages are not sent to fluentd
408 # to enable logging to fluents, specify a valid fluentd tag name to be used for the
411 # Module and class name of factory which will be used to provide classes dynamically for other components.
412 factory_module: 'nfvbench.factory'
413 factory_class: 'BasicFactory'
415 # Custom label added for every perf record generated during this run.
416 # Can be overriden by --user-label