aboutsummaryrefslogtreecommitdiffstats
path: root/nfvbench/cfg.default.yaml
blob: f36cbeada8a23c55bc85b111c4b613786a1251e8 (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
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
#
# NFVbench default configuration file
#
# This configuration file is ALWAYS loaded by NFVbench and should never be modified by users.
# To specify your own property values, always define them in a separate config file
# and pass that file to the script using -c or --config <file>
# Property values in that config file will override the default values in the current file
#
---
# IMPORTANT CUSTOMIZATION NOTES
# There are roughly 2 types of NFVbench config based on the OpenStack encaps used:
# - VLAN (OVS, OVS-DPDK, ML2/VPP)
# Many of the fields to customize are relevant to only 1 of the 2 encaps
# These will be clearly labeled "VxLAN only" or "VLAN only"
# Fields that are not applicable will not be used by NFVbench and can be left empty
#
# All fields are applicable to all encaps/traffic generators unless explicitly marked otherwise.
# Fields that can be over-ridden at the command line are marked with the corresponding
# option, e.g. "--interval"


# Forwarder to use in nfvbenchvm image. Available options: ['vpp', 'testpmd']
vm_forwarder: testpmd

# By default (empty) NFVBench will try to locate a VM image file
# from the package root directory named "nfvbench-<version>.qcow2" and
# upload that file. The image name will be "nfvbench-<version>"
# This can be overridden by specifying here a pathname of a file
# that follows the same naming convention.
# In most cases, this field should be left empty as the packaging should
# include the proper VM image file
vm_image_file:

# Name of the flavor to use for the loopback VMs
#
# If the provided name is an exact match to a flavor name known by OpenStack
# (as shown from 'nova flavor-list'), that flavor will be reused.
# Otherwise, a new flavor will be created with attributes listed below.
flavor_type: 'nfvbench.medium'

# Custom flavor attributes
flavor:
  # Number of vCPUs for the flavor
  vcpus: 2
  # Memory for the flavor in MB
  ram: 8192
  # Size of local disk in GB
  disk: 0
  # metadata are supported and can be added if needed, optional
  # note that if your openstack does not have NUMA optimization
  # (cpu pinning and huge pages)
  # you must comment out extra_specs completely otherwise
  # loopback VM creation will fail
  extra_specs:
      "hw:cpu_policy": dedicated
      "hw:mem_page_size": large

# Name of the availability zone to use for the test VMs
# Must be one of the zones listed by 'nova availability-zone-list'
# If the selected zone contains only 1 compute node and PVVP inter-node flow is selected,
# application will use intra-node PVVP flow.
# List of compute nodes can be specified, must be in given availability zone if not empty
#availability_zone: 'nova'
availability_zone:
compute_nodes:


# Credentials for SSH connection to TOR switches.
tor:
    # Leave type empty or switch list empty to skip TOR switches configuration.
    # Preferably use 'no_tor_access' to achieve the same behavior.
    # (skipping TOR config will require the user to pre-stitch the traffic generator interfaces
    # to the service chain under test, needed only if configured in access mode)
    type:
    # Switches are only needed if type is not empty.
    # You can configure 0, 1 or 2 switches
    # no switch: in this case NFVbench will not attempt to ssh to the switch
    #            and stitching of traffic must be done externally
    # 1 switch: this assumes that both traffic generator interfaces are wired to the same switch
    # 2 switches: this is the recommended setting wuth redundant switches, in this case each
    #             traffic generator interface must be wired to a different switch
    switches:
        - host:
          username:
          password:
          port:

# Skip TOR switch configuration and retrieving of stats
# Can be overriden by --no-tor-access
no_tor_access: false

# Skip vswitch configuration and retrieving of stats
# Can be overriden by --no-vswitch-access
no_vswitch_access: false

# Type of service chain to run, possible options are PVP, PVVP and EXT
# PVP - port to VM to port
# PVVP - port to VM to VM to port
# EXT - external chain used only for running traffic and checking traffic generator counters,
#       all other parts of chain must be configured manually
# Can be overriden by --service-chain
service_chain: 'PVP'

# Total number of service chains, every chain has own traffic stream
# Can be overriden by --service-chain-count
service_chain_count: 1

# Total number of traffic flows for all chains and directions generated by the traffic generator.
# Minimum is '2 * service_chain_count', it is automatically adjusted if too small
# value was configured. Must be even.
# Every flow has packets with different IPs in headers
# Can be overriden by --flow-count
flow_count: 10000

# Used by PVVP chain to spawn VMs on different compute nodes
# Can be overriden by --inter-node
inter_node: false

# set to true if service chains should use SRIOV
# This requires SRIOV to be available on compute nodes
sriov: false

# Skip interfaces config on EXT service chain
# Can be overriden by --no-int-config
no_int_config: false

# Resources created by NFVbench will not be removed
# Can be overriden by --no-cleanup
no_cleanup: false

# Configuration for traffic generator
traffic_generator:
    # Name of the traffic generator, only for informational purposes
    host_name: 'nfvbench_tg'
    # this is the default traffic generator profile to use
    # the name must be defined under generator_profile
    # you can override the traffic generator to use using the
    # -g or --traffic-gen option at the command line
    default_profile: trex-local

    # IP addresses for L3 traffic.
    # All of the IPs are used as base for IP sequence computed based on chain or flow count.
    #
    # `ip_addrs` base IPs used as src and dst in packet header, quantity depends on flow count
    # `ip_addrs_step`: step for generating IP sequence. Use "random" for random patterns, default is 0.0.0.1.
    # `tg_gateway_ip_addrs` base IPs for traffic generator ports, quantity depends on chain count
    # `tg_gateway_ip_addrs__step`: step for generating traffic generator gateway sequences. default is 0.0.0.1
    # `gateway_ip_addrs`: base IPs of router gateways on both networks, quantity depends on chain count
    # `gateway_ip_addrs_step`: step for generating router gateway sequences. default is 0.0.0.1
    # `udp_src_port`: the source port for sending UDP traffic, default is picked by TRex (53)
    # `udp_dst_port`: the destination port for sending UDP traffic, default is picked by TRex (53)
    ip_addrs: ['10.0.0.0/8', '20.0.0.0/8']
    ip_addrs_step: 0.0.0.1
    tg_gateway_ip_addrs: ['1.1.0.100', '2.2.0.100']
    tg_gateway_ip_addrs_step: 0.0.0.1
    gateway_ip_addrs: ['1.1.0.2', '2.2.0.2']
    gateway_ip_addrs_step: 0.0.0.1
    udp_src_port:
    udp_dst_port:

    # Traffic Generator Profiles
    # In case you have multiple testbeds or traffic generators,
    # you can define one traffic generator profile per testbed/traffic generator.
    #
    # Generator profiles are listed in the following format:
    # `name`: Traffic generator profile name (use a unique name, no space or special character)
    # `tool`: Traffic generator tool to be used (currently supported is `TRex`).
    # `ip`: IP address of the traffic generator.
    # `cores`: Specify the number of cores for TRex traffic generator. ONLY applies to trex-local.
    # `interfaces`: Configuration of traffic generator interfaces.
    # `interfaces.port`: The port of the traffic generator to be used (leave as 0 and 1 resp.)
    # `interfaces.switch_port`: Leave empty (reserved for advanced use cases)
    # `interfaces.pci`: The PCI address of the intel NIC interface associated to this port
    # `intf_speed`: The speed of the interfaces used by the traffic generator (per direction).
    #
    generator_profile:
        - name: trex-local
          tool: TRex
          ip: 127.0.0.1
          cores: 3
          interfaces:
            - port: 0
              switch_port:
              pci:
            - port: 1
              switch_port:
              pci:
          intf_speed: 10Gbps

# -----------------------------------------------------------------------------
# These variables are not likely to be changed

# The openrc file
openrc_file:

# Number of seconds to wait for VMs to pass traffic in both directions
check_traffic_time_sec: 200

# General retry count
generic_retry_count: 100

# General poll period
generic_poll_sec: 2

# name of the loop VM
loop_vm_name: 'nfvbench-loop-vm'

# Default names, subnets and CIDRs for PVP/PVVP networks
# If a network with given name already exists it will be reused.
# - PVP only uses left and right
# - PVVP uses left, middle and right
# - for EXT chains, this structure is not relevant - refer to external_networks
# Otherwise a new internal network will be created with that name, subnet and CIDR.
# 
# segmentation_id can be set to enforce a specific VLAN id - by default (empty) the VLAN id 
#                 will be assigned by Neutron.
#                 Must be unique for each network
# physical_network can be set to pick a specific phsyical network - by default (empty) the
#                   default physical network will be picked
# In the case of SR-IOV, both physical_network and segmentation ID must be provided
# For example to setup PVP using 2 different SR-IOV ports, you must put the appropriate physnet
# names under left.physical_network and right.physical_network.
# Example of override configuration to force PVP to run on 2 SRIOV ports (phys_sriov0 and phys_sriov1)
# using VLAN ID 2000 and 2001:
# internal_networks:
#    left:
#        segmentation_id: 2000
#        physical_network: phys_sriov0
#    right:
#        segmentation_id: 2001
#        physical_network: phys_sriov1

internal_networks:
    left:
        name: 'nfvbench-net0'
        subnet: 'nfvbench-subnet0'
        cidr: '192.168.1.0/24'
        network_type: 'vlan'
        segmentation_id:
        physical_network:
    right:
        name: 'nfvbench-net1'
        subnet: 'nfvbench-subnet1'
        cidr: '192.168.2.0/24'
        network_type: 'vlan'
        segmentation_id:
        physical_network:
    middle:
        name: 'nfvbench-net2'
        subnet: 'nfvbench-subnet2'
        cidr: '192.168.3.0/24'
        network_type: 'vlan'
        segmentation_id:
        physical_network:

# EXT chain only. Names of edge networks which will be used to send traffic via traffic generator.
external_networks:
    left: 'nfvbench-net0'
    right: 'nfvbench-net1'

# Use 'true' to enable VLAN tagging of packets generated and sent by the traffic generator
# Leave empty you do not want the traffic generator to insert the VLAN tag. This is 
# needed for example if VLAN tagging is enabled on switch (trunk mode) or if you want to hook directly to a NIC
# By default is set to true (which is the nominal use case with TOR and trunk mode to Trex)
vlan_tagging: true

# Specify only when you want to override VLAN IDs used for tagging with own values (exactly 2).
# Default behavior of VLAN tagging is to retrieve VLAN IDs from OpenStack networks provided above.
# In case of VxLAN this setting is ignored and only vtep_vlan from traffic generator profile is used.
# Example: [1998, 1999]
vlans: []

# Used only with EXT chain. MAC addresses of traffic generator ports are used as destination
# if 'no_arp' is set to 'true'. Otherwise ARP requests are sent to find out destination MAC addresses.
no_arp: false

# Traffic Profiles
# You can add here more profiles as needed
# `l2frame_size` can be specified in any none zero integer value to represent the size in bytes
# of the L2 frame, or "IMIX" to represent the standard 3-packet size mixed sequence (IMIX1).
traffic_profile:
    - name: traffic_profile_64B
      l2frame_size: ['64']
    - name: traffic_profile_IMIX
      l2frame_size: ['IMIX']
    - name: traffic_profile_1518B
      l2frame_size: ['1518']
    - name: traffic_profile_3sizes
      l2frame_size: ['64', 'IMIX', '1518']

# Traffic Configuration
# bidirectional: to have traffic generated from both direction, set bidirectional to true
# profile: must be one of the profiles defined in traffic_profile
# The traffic profile can be overriden with the options --frame-size and --uni-dir
traffic:
    bidirectional: true
    profile: traffic_profile_64B

# Check config and connectivity only - do not generate traffic
# Can be overriden by --no-traffic
no_traffic: false

# Do not reset tx/rx counters prior to running
# Can be overriden by --no-reset
no_reset: false

# Test configuration

# The rate pps for traffic going in reverse direction in case of unidirectional flow. Default to 1.
unidir_reverse_traffic_pps: 1

# The rate specifies if NFVbench should determine the NDR/PDR
#  or if NFVbench should just generate traffic at a given fixed rate
# for a given duration (called "single run" mode)
# Supported rate format:
# NDR/PDR test: `ndr`, `pdr`, `ndr_pdr` (default)
# Or for single run mode:
# Packet per second: pps (e.g. `50pps`)
# Bits per second: bps, kbps, Mbps, etc (e.g. `1Gbps`, `1000bps`)
# Load percentage: % (e.g. `50%`)
# Can be overridden by --rate
rate: ndr_pdr

# Default run duration (single run at given rate only)
# Can be overridden by --duration
duration_sec: 60

# Interval between intermediate reports when interval reporting is enabled
# Can be overridden by --interval
interval_sec: 10

# NDR / PDR configuration
measurement:
    # Drop rates represent the ratio of dropped packet to the total number of packets sent.
    # Values provided here are percentages. A value of 0.01 means that at most 0.01% of all
    # packets sent are dropped (or 1 packet every 10,000 packets sent)

    # No Drop Rate in percentage; Default to 0.001%
    NDR: 0.001
    # Partial Drop Rate in percentage; NDR should always be less than PDR
    PDR: 0.1
    # The accuracy of NDR and PDR as a percnetage of line rate; The exact NDR
    # or PDR should be within `load_epsilon` line rate % from the one calculated.
    # For example, with a value 0.1, and a line rate of 10Gbps, the accuracy
    # of NDR and PDR will be within 0.1% Of 10Gbps or 10Mbps.
    # The lower the value the more iterations and the longer it will take to find the NDR/PDR.
    # In practice, due to the precision of the traffic generator it is not recommended to
    # set it to lower than 0.1
    load_epsilon: 0.1

# Location where to store results in a JSON format. Must be container specific path.
# Can be overriden by --json
json:

# Location where to store results in the NFVbench standard JSON format:
# <service-chain-type>-<service-chain-count>-<flow-count>-<packet-sizes>.json
# Example: PVP-1-10-64-IMIX.json
# Must be container specific path.
# Can be overriden by --std-json
std_json:

# Prints debug messages (verbose mode)
# Can be overriden by --debug
debug: false

# Set to a valid path name if logging to file is to be enabled
# Defaults to disabled
log_file:

# When enabled, all logs will be sent to a fluentd server at the requested IP and port
# The fluentd "tag" and "label" fields for every message will be set to "nfvbench"
fluentd:
    # by default (logging_tag is empty) nfvbench log messages are not sent to fluentd
    # to enable logging to fluents, specify a valid fluentd tag name to be used for the
    # log records
    logging_tag:

    # IP address of the server, defaults to loopback
    ip: 127.0.0.1

    # port # to use, by default, use the default fluentd forward port
    port: 24224

# Module and class name of factory which will be used to provide classes dynamically for other components.
factory_module: 'nfvbench.factory'
factory_class: 'BasicFactory'