# # 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 # 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" # The OpenStack openrc file to use - must be a valid full pathname. If running # in a container, this path must be valid in the container. # # The only case where this field can be empty is when measuring a system that does not run # OpenStack or when OpenStack APIs are not accessible or OpenStack APis use is not # desirable. In that case the EXT service chain must be used. # # If openrc is not admin some parameters are mandatory and must be filled with valid values in config file such as : # - availability_zone # - hypervisor_hostname # - vlans openrc_file: # 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-.qcow2" and # upload that file. The image name will be "nfvbench-" # 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 for the test VM flavor: # Number of vCPUs for the flavor, must be at least 2! vcpus: 2 # Memory for the flavor in MB ram: 4096 # 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 # Enable multiqueue for all test VM interfaces (PVP and PVVP only). # When enabled, the test VM image will get added the property to enable # multiqueue (hw_vif_multiqueue_enabled='true'). # The number of queues per interace will be set to the number of vCPUs configured for # the VM. # By default there is only 1 queue per interface # The max allowed queue per interface is 8. # The valid range for this parameter is [1..min(8, vcpu_count)] # When multiqueue is used the recommended setting is to set it to same value as the # number of vCPU used - up to a max of 8 queues. # Setting to a lower value than vCPU should also work. For example if using 4 vCPU and # vif_multiqueue_size is set to 2, openstack will create 4 queues per interface but the # test VM will only use the first 2 queues. vif_multiqueue_size: 1 # Increase number of buffers allocated for VPP VM forwarder. May be needed in scenarios with large # number of interfaces and worker threads, or a lot of physical interfaces with multiple RSS queues. # Value is per CPU socket. Default is 16384. num_mbufs: 16384 # Name of the availability zone to use for the test VMs # Must be one of the zones listed by 'nova availability-zone-list' # availability_zone: 'nova' # If openrc is not admin set a valid value availability_zone: # To force placement on a given hypervisor, set the name here # (if multiple names are provided, the first will be used) # Leave empty to let openstack pick the hypervisor compute_nodes: # If openrc is not admin set a valid value for hypervisor hostname # Example of value: hypervisor_hostname: "server1" hypervisor_hostname: # 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 # Specifies if all chains share the same right/left/middle networks service_chain_shared_net: false # 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 # set to true if service chains should use SRIOV # This requires SRIOV to be available on compute nodes sriov: false # Perform port to port loopback (direct or through switch) # Should be used with EXT service chain and no ARP (no_arp: true) # When enabled, the vlans property must contain the same VLAN id for all chains. # Can be overriden by --l2-loopback l2_loopback: 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. # This section describes the addresses to use to fill in the UDP packets sent by the # traffic generator. If you VNFs are L2 forwarders, these fields below do not need to change. # If your VNFs are L3 routers, the fields below must match the static routes in your VNFs # so that UDP packets can be routed back to the peer port of the traffic generator. # All of the IPs are used as base for IP sequence computed based on chain or flow count. # (sim-devices-left)---(tg-gateway-left)---(vnf-left)- ... # -(vnf-right)---(tg-gateway-right)---(sim-devices-right) # # `ip_addrs` base IPs used as src and dst in packet header, quantity depends on flow count # these are used for addressing virtual devices simulated by the traffic generator # and be a different subnet than tg_gateway_ip_addrs and gateway_ip_addrs # `ip_addrs_step`: step for generating IP sequence. Use "random" for random patterns, default is 0.0.0.1. ip_addrs: ['10.0.0.0/8', '20.0.0.0/8'] ip_addrs_step: 0.0.0.1 # `tg_gateway_ip_addrs` base IP for traffic generator ports in the left and right networks to the VNFs # chain count consecutive IP addresses spaced by tg_gateway_ip_addrs_step will be used # `tg_gateway_ip_addrs__step`: step for generating traffic generator gateway sequences. default is 0.0.0.1 tg_gateway_ip_addrs: ['1.1.0.100', '2.2.0.100'] tg_gateway_ip_cidrs: ['1.1.0.0/24','2.2.0.0/24'] tg_gateway_ip_addrs_step: 0.0.0.1 # `gateway_ip_addrs`: base IPs of VNF router gateways (left and right), quantity used depends on chain count # must correspond to the public IP on the left and right networks # for each left-most and right-most VNF of every chain. # must be the same subnet but not same IP as tg_gateway_ip_addrs. # chain count consecutive IP addresses spaced by gateway_ip_addrs_step will be used # `gateway_ip_addrs_step`: step for generating router gateway sequences. default is 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`: 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) udp_src_port: udp_dst_port: # VxLAN only: optionally specify what VLAN tag to use for the VxLAN overlay # This is used if the vxlan tunnels are running on a specific VLAN. # Leave empty if there is no VLAN tagging required, or specify the VLAN id to use # for all VxLAN tunneled traffic vtep_vlan: # VxLAN only: local/source vteps IP addresses for port 0 and 1 ['10.1.1.230', '10.1.1.231'] src_vteps: # VxLAN only: remote IP address of the remote VTEPs that terminate all tunnels originating from local VTEPs dst_vtep: # L2 ADDRESSING OF UDP PACKETS # Lists of dest MAC addresses to use on each traffic generator port (one dest MAC per chain) # Leave empty for PVP, PVVP, EXT with ARP # Only used when `service_chain` is EXT and `no_arp` is true. # - If both lists are empty the far end MAC of the traffic generator will be used for left and right # (this is typicaly used to loop back on the first hop switch or using a loopback cable) # - The length of each list must match the number of chains being used! # - The index of each list must correspond to the chain index to ensure proper pairing. # - Below is an example of using two chains: # - mac_addrs_left: ['00:00:00:00:01:00', '00:00:00:00:02:00'] # - mac_addrs_right: ['00:00:00:00:01:01', '00:00:00:00:02:01'] # UDP packets sent on port 0 will use dest MAC '00:00:00:00:01:00' for chain #0 and # dest MAC '00:00:00:00:02:00' for chain #1 # UDP packets sent on port 1 will use dest MAC '00:00:00:00:01:01' for chain #0 and # dest MAC '00:00:00:00:02:01' for chain #1 # It is expected that the looping device (L2 forwarder) will rewrite the src and dst MAC # of the looping UDP packet so that it can reach back to the peer port of the traffic # generator. # mac_addrs_left: mac_addrs_right: # Traffic Generator Profiles # In case you have multiple testbeds or traffic generators, # you can define one traffic generator profile per testbed/traffic generator. # In most cases you only need to fill in the pci address for the 2 ports used by the # traffic generator and leave all other fields unchanged # # Generator profiles are listed in the following format: # `name`: Traffic generator profile name (use a unique name, no space or special character) # Do not change this field # `tool`: Traffic generator tool to be used (currently supported is `TRex`). # Do not change this field # `ip`: IP address of the traffic generator. # The default loopback address is used when the traffic generator runs on the same host # as NFVbench. # `cores`: Specify the number of cores for running the TRex traffic generator. # ONLY applies to trex-local. # `software_mode`: Advice TRex to use software mode which provides the best compability. But # note that TRex will not use any hardware acceleration technology under # software mode, therefore the performance of TRex will be significantly # lower. ONLY applies to trex-local. # Recommended to leave the default value (false) # `limit_memory`: Specify the memory reserved for running the TRex traffic generator (in MB). Limit the amount # of packet memory used. (Passed to dpdk as -m arg) # ONLY applies to trex-local. # `zmq_pub_port`: Specify the ZMQ pub port number for the TRex traffic generator instance (default value is 4500). # ONLY applies to trex-local. # `zmq_rpc_port`: Specify the ZMQ rpc port for the TRex traffic generator instance (default value is 4501). # 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 (deprecated) # `interfaces.pci`: The PCI address of the intel NIC interface associated to this port # This field is required and cannot be empty # Use lspci to list the PCI address of all devices # Example of value: "0000:5e:00.0" # `intf_speed`: The speed of the interfaces used by the traffic generator (per direction). # Empty value (default) to use the speed discovered by the traffic generator. # Recommended to leave this field empty. # Do not use unless you want to override the speed discovered by the # traffic generator. Expected format: 10Gbps # # `platform`: Optional. Used to tune the performance and allocate the cores to the right NUMA. # See https://trex-tgn.cisco.com/trex/doc/trex_manual.html (6.2.3. Platform section configuration) # for more details # `platform.master_thread_id`: Hardware thread_id for control thread. (Valid value is mandatory if platform property is set) # `platform.latency_thread_id`: Hardware thread_id for RX thread. (Valid value is mandatory if platform property is set) # `platform.dual_if`: Section defines info for interface pairs (according to the order in “interfaces” list). (Valid value is mandatory if platform property is set) # Each section, starting with “- socket” defines info for different interface pair. (Valid value is mandatory if platform property is set) # `platform.dual_if.socket`: The NUMA node from which memory will be allocated for use by the interface pair. (Valid value is mandatory if platform property is set) # `platform.dual_if.threads`: Hardware threads to be used for sending packets for the interface pair. (Valid value is mandatory if platform property is set) # Threads are pinned to cores, so specifying threads actually determines the hardware cores. # Example of values: # platform: # master_thread_id: 0 # latency_thread_id: 2 # dual_if: # - socket: 0 # threads: [1] # generator_profile: - name: trex-local tool: TRex ip: 127.0.0.1 cores: 4 software_mode: false limit_memory: 1024 zmq_pub_port: 4500 zmq_rpc_port: 4501 interfaces: - port: 0 pci: switch_port: - port: 1 pci: switch_port: intf_speed: platform: master_thread_id: latency_thread_id: dual_if: - socket: threads: # Use 'true' to force restart of local TRex server before next run # TRex local server will be restarted even if restart property is false in case of generator config changes between runs restart: false # Simpler override for trex core count and mbuf multilier factor # if empty defaults to the one specified in generator_profile.cores cores: # Add cache size in packet generation for TRex field engine (FE). # More information for TRex performance: # https://trex-tgn.cisco.com/trex/doc/trex_stateless.html#_tutorial_field_engine_significantly_improve_performance # If cache_size = 0 (or empty): no cache will be used by TRex (default) # If cache_size < 0: cache_size will be set to flow count value cache_size: 0 # The cache size is actually limited by the number of 64B mbufs configured in the trex platform configuration (see Trex manual 6.2.2. Memory section configuration) # Trex will use 1 x 64B mbuf per pre-built cached packet, assuming 1 pre-built cached packet per flow, it means for very large number of flows, the number of configured mbuf_64 will need to be set accordingly. mbuf_64: # mbuffer ratio to use for TRex (see TRex documentation for more details) mbuf_factor: 0.2 # A switch to disable hdrh # hdrh is enabled by default and requires TRex v2.58 or higher disable_hdrh: false # ----------------------------------------------------------------------------- # These variables are not likely to be changed # 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 (openstack only) # # 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. # # network_type must be 'vlan' (for VLAN and SRIOV) or 'vxlan' (for VxLAN) # all 3 networks must use the same network type in this release # segmentation_id can be set to enforce a specific segmentation id (vlan ID or VNI if vxlan) # by default (empty) the segmentation id will be assigned by Neutron. # If specified, it must be unique for each network # For multi-chaining, see notes below # physical_network can be set to pick a specific phsyical network - by default (empty) the # default physical network will be picked # SR-IOV: both physical_network and VLAN segmentation ID must be provided # VxLAN: the VNI must generally be provided (except special Neutron VxLAN implementations) # # For example to setup 1xPVP using 2 different SR-IOV ports, you must put the appropriate physnet # names under left.physical_network and right.physical_network. # For multi-chaining and non shared networks, # 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 # # For multi-chaining and non shared network mode (VLAN, SRIOV, VxLAN): # - the segmentation_id field if provided must be a list of values (as many as chains) # - segmentation_id auto-indexing: # the segmentation_id field can also be a single value that represents the base value from which # values for each chain is derived using the chain ID as an offset. For example # if 2000 is specified, NFVbench will use 2000 for chain 0, 2001 for chain 1 etc... # The ranges of all the networks must not overlap. # - the physical_network can be a single name (all VFs to be allocated on same physnet) # of a list of physnet names to use different PFs # # Example of 2-chain configuration: # internal_networks: # left: # segmentation_id: [2000, 2001] # physical_network: phys_sriov0 # right: # segmentation_id: [2010, 2011] # physical_network: phys_sriov1 # # Equivalent to (using auto-indexing): # internal_networks: # left: # segmentation_id: 2000 # physical_network: phys_sriov0 # right: # segmentation_id: 2010 # physical_network: phys_sriov1 internal_networks: left: name: 'nfvbench-lnet' subnet: 'nfvbench-lsubnet' cidr: '192.168.1.0/24' network_type: 'vlan' segmentation_id: physical_network: right: name: 'nfvbench-rnet' subnet: 'nfvbench-rsubnet' cidr: '192.168.2.0/24' network_type: 'vlan' segmentation_id: physical_network: middle: name: 'nfvbench-mnet' subnet: 'nfvbench-msubnet' cidr: '192.168.3.0/24' network_type: 'vlan' segmentation_id: physical_network: # IDLE INTERFACES: PVP, PVVP and non shared net only. # By default each test VM will have 2 virtual interfaces for looping traffic. # If service_chain_shared_net is false, additional virtual interfaces can be # added at VM creation time, these interfaces will not carry any traffic and # can be used to test the impact of idle interfaces in the overall performance. # All these idle interfaces will use normal ports (not direct). # Number of idle interfaces per VM (none by default) idle_interfaces_per_vm: 0 # A new network is created for each idle interface. # If service_chain_shared_net is true, the options below will be ignored # and no idle interfaces will be added. idle_networks: # Prefix for all idle networks, the final name will append the chain ID and idle index # e.g. "nfvbench-idle-net.0.4" chain 0 idle index 4 name: 'nfvbench-idle-net' # Subnet name to use for all idle subnetworks subnet: 'nfvbench-idle-subnet' # CIDR to use for all idle networks (value should not matter) cidr: '192.169.1.0/24' # Type of network associated to the idle virtual interfaces (vlan or vxlan) network_type: 'vlan' # segmentation ID to use for the network attached to the idle virtual interfaces # vlan: leave empty to let neutron pick the segmentation ID # vxlan: must specify the starting VNI value to be used (cannot be empty) # Note that NFVbench will use as many consecutive segmentation IDs as needed. # For example, for 4 PVP chains and 8 idle # interfaces per VM, NFVbench will use 32 consecutive values of segmentation ID # starting from the value provided. segmentation_id: # physnet name to use for all idle interfaces physical_network: # MANAGEMENT INTERFACE # By default each test VM will have 2 virtual interfaces for looping traffic. # If use_management_port is true, additional virtual interface can be # added at VM creation time, this interface will be used for VM management over SSH. # This will be helpful for debug (forwarder config, capture traffic...) # or to emulate VNF with management interface use_management_port: false # If a network with given name already exists it will be reused. # Otherwise a new network is created for management interface. # If use_management_port is false, the options below will be ignored # and no management interface will be added. management_network: name: 'nfvbench-management-net' # Subnet name to use for management subnetwork subnet: 'nfvbench-management-subnet' # CIDR to use for management network cidr: '192.168.0.0/24' gateway: '192.168.0.254' # Type of network associated to the management virtual interface (vlan or vxlan) network_type: 'vlan' # segmentation ID to use for the network attached to the management virtual interface # vlan: leave empty to let neutron pick the segmentation ID # vxlan: must specify the starting VNI value to be used (cannot be empty) segmentation_id: # physnet name to use for all idle interfaces physical_network: # Floating IP for management interface # If use_floating_ip is true, floating IP will be set on management interface port # One floating IP by loop VM will be used (floating ips are often limited, # use them on limited context mainly for debug). If there are 10 PVP chains, this will require 10 # floating IPs. If 10 PVVP chains, it will require 20 floating IPs use_floating_ip: false # If a network with given name already exists it will be reused. # Set same name as management_network if you want to use a floating IP from this network # Otherwise set name, subnet and CIDR information from your floating IP pool network # Floating network used to set floating IP on management port. # Only 1 floating network will be used for all VMs and chains (shared network). # If use_floating_ip is false, the options below will be ignored # and no floating IP will be added. floating_network: name: 'nfvbench-floating-net' # Subnet name to use for floating subnetwork subnet: 'nfvbench-floating-subnet' # CIDR to use for floating network cidr: '192.168.0.0/24' # Type of network associated to the management virtual interface (vlan or vxlan) network_type: 'vlan' # segmentation ID to use for the network attached to the management virtual interface # vlan: leave empty to let neutron pick the segmentation ID # vxlan: must specify the starting VNI value to be used (cannot be empty) segmentation_id: # physnet name to use for all idle interfaces physical_network: # In the scenario of PVVP + SRIOV, there is choice of how the traffic will be # handled in the middle network. The default (false) will use vswitch, while # SRIOV can be used by toggling below setting. use_sriov_middle_net: false # EXT chain only. Prefix names of edge networks or list of edge network names # used to send traffic via traffic generator. # # If service_chain_shared_net is true, the left and right networks must pre-exist and match exactly by name. # # If service_chain_shared_net is false, each chain must have its own pre-existing left and right networks. # left and right can take either a string prefix or a list of arbitrary network names # If a string prefix is passed, an index will be appended to each network name to form the final name. # Example: # external_networks: # left: 'ext-lnet' # right: 'ext-rnet' # ext-lnet0 ext-rnet0 for chain #0 # ext-lnet1 ext-rnet1 for chain #1 # etc... # If a list of strings is passed, each string in the list must be the name of the network used for the # chain indexed by the entry position in the list. # The list must have at least as many entries as there are chains # Example: # external_networks: # left: ['ext-lnet', 'ext-lnet2'] # right: ['ext-rnet', 'ext-rnet2'] # external_networks: left: right: # PVP with L3 router in the packet path only. # Only use when l3_router option is True (see l3_router) # Prefix names of edge networks which will be used to send traffic via traffic generator. # If a network with given name already exists it will be reused. # Otherwise a new edge network will be created with that name, subnet and CIDR. # # gateway can be set in case of L3 traffic with edge networks - refer to edge_networks # # 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 # edge_networks: left: name: 'nfvbench-net2' router_name: 'router_left' subnet: 'nfvbench-subnet2' cidr: '192.168.3.0/24' gateway: network_type: segmentation_id: physical_network: right: name: 'nfvbench-net3' router_name: 'router_right' subnet: 'nfvbench-subnet3' cidr: '192.168.4.0/24' gateway: network_type: segmentation_id: physical_network: # Use 'true' to enable VXLAN encapsulation support and sent by the traffic generator # When this option enabled internal networks 'network type' parameter value should be 'vxlan' vxlan: false # Use 'true' to enable VLAN tagging of packets generated and sent by the traffic generator # Leave empty or set to false if you do not want the traffic generator to insert the VLAN tag (this is # needed for example if VLAN tagging is enabled on switch (access 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 ports) # If VxLAN is enabled, this option should be set to false (vlan tagging for encapsulated packets # is not supported). Use the vtep_vlan option to enable vlan tagging for the VxLAN overlay network. vlan_tagging: true # Used only in the case of EXT chain and no openstack or not admin access to specify the VLAN IDs to use. # This property is ignored when OpenStakc is used or in the case of l2-loopback. # If OpenStack is used leave the list empty, VLAN IDs are retrieved from OpenStack networks using Neutron API. # If networks are shared across all chains (service_chain_shared_net=true), the list should have exactly 2 values # If networks are not shared across chains (service_chain_shared_net=false), the list should have # 2 list of vlan IDs # In the special case of l2-loopback the list should have the same VLAN id for all chains # Examples: # [1998, 1999] left network uses vlan 1998 right network uses vlan 1999 # [[1,2],[3,4]] chain 0 left vlan 1, right vlan 2 - chain 1 left vlan 3 right vlan 4 # [1010, 1010] same VLAN id with l2-loopback enabled # vlans: [] # ARP is used to discover the MAC address of VNFs that run L3 routing. # Used only with EXT chain. # False (default): ARP requests are sent to find out dest MAC addresses. # True: do not send ARP but use provisioned dest macs instead # (see mac_addrs_left and mac_addrs_right) 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 # Use an L3 router in the packet path. This option if set will create or reuse an openstack neutron # router (PVP, PVVP) or reuse an existing L3 router (EXT) to route traffic to the destination VM. # Can be overriden by --l3-router l3_router: 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 # Default pause between iterations of a binary search (NDR/PDR) pause_sec: 2 # 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: # ---.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 results and/or logs will be sent to a fluentd servers at the requested IPs and ports # A list of one or more fluentd servers identified by their IPs and port numbers should be given. # For each recipient it is possible to enable both sending logs and performance # results, or enable either logs or performance results. For enabling logs or results logging_tag or # result_tag should be set. 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: # by default (result_tag is empty) nfvbench results are not sent to fluentd # to enable sending nfvbench results to fluentd, specify a valid fluentd tag name # to be used for the results records, which is different than logging_tag result_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 # 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 # Module and class name of factory which will be used to provide classes dynamically for other components. factory_module: 'nfvbench.factory' factory_class: 'BasicFactory' # Custom label added for every perf record generated during this run. # Can be overriden by --user-label user_label: # THESE FIELDS SHOULD BE USED VERY RARELY # Skip vswitch configuration and retrieving of stats # Can be overriden by --no-vswitch-access # Should be left to the default value (false) no_vswitch_access: false # Enable service mode for trafic capture from TRex console (for debugging purpose) # Can be overriden by --service-mode # Should be left to the default value (false) service_mode: false # Disable extra flow stats (on high load traffic) # Can be overriden by --no-flow-stats # Should be left to the default value (false) no_flow_stats: false # Disable flow stats for latency traffic # Can be overriden by --no-latency-stats # Should be left to the default value (false) no_latency_stats: false # Disable latency measurements (no streams) # Can be overriden by --no-latency-stream # Should be left to the default value (false) no_latency_streams: false