2.0 beta NFVBENCH-91 Allow multi-chaining with separate edge networks

Includes complete refactoring of code
Beta for NFVbench 2.0

Change-Id: I2997f0fb7722d5ac626cd11a68692ae458c7676e
Signed-off-by: ahothan <ahothan@cisco.com>

1 files changed, 113 insertions, 81 deletions

diff --git a/nfvbench/cfg.default.yaml b/nfvbench/cfg.default.yaml
index 2af6d63..fdf40c6 100755
--- a/nfvbench/cfg.default.yaml
+++ b/nfvbench/cfg.default.yaml
@@ -18,7 +18,8 @@
 # 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
+
+# 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
@@ -29,7 +30,7 @@ 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
+# 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
@@ -67,39 +68,10 @@ flavor:
 # 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: '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
@@ -112,6 +84,9 @@ service_chain: 'PVP'
 # 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.
@@ -119,20 +94,13 @@ service_chain_count: 1
 # 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
-
 # 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
 
@@ -151,54 +119,94 @@ traffic_generator:
     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.
-    # `tg_gateway_ip_addrs` base IPs for traffic generator ports, quantity depends on chain count
+    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
-    # `gateway_ip_addrs`: base IPs of router gateways on both networks, quantity depends on chain count
+    tg_gateway_ip_addrs: ['1.1.0.100', '2.2.0.100']
+    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)
-    # `mac_addrs_left` & `mac_addrs_right`: Lists of MAC addresses corresponding to the number of chains
-    # specified for `service_chain_count`.
+    udp_src_port:
+    udp_dst_port:
+
+    # 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
-    #   - The MAC addresses will only be used when `service_chain` is EXT and `no_arp` is true.
-    #   - The length of each list must match the number of chains being used.
+    #     (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']
-    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:
+    #     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)
+    #         DFo 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.
-    # `cores`: Specify the number of cores for TRex traffic generator. ONLY applies to trex-local.
+    #       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)
     # `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.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
     #
     generator_profile:
         - name: trex-local
@@ -208,12 +216,12 @@ traffic_generator:
           software_mode: false
           interfaces:
             - port: 0
-              switch_port:
               pci:
-            - port: 1
               switch_port:
+            - port: 1
               pci:
-          intf_speed: 10Gbps
+              switch_port:
+          intf_speed:
 
 # -----------------------------------------------------------------------------
 # These variables are not likely to be changed
@@ -257,22 +265,22 @@ loop_vm_name: 'nfvbench-loop-vm'
 
 internal_networks:
     left:
-        name: 'nfvbench-net0'
-        subnet: 'nfvbench-subnet0'
+        name: 'nfvbench-lnet'
+        subnet: 'nfvbench-lsubnet'
         cidr: '192.168.1.0/24'
         network_type: 'vlan'
         segmentation_id:
         physical_network:
     right:
-        name: 'nfvbench-net1'
-        subnet: 'nfvbench-subnet1'
+        name: 'nfvbench-rnet'
+        subnet: 'nfvbench-rsubnet'
         cidr: '192.168.2.0/24'
         network_type: 'vlan'
         segmentation_id:
         physical_network:
     middle:
-        name: 'nfvbench-net2'
-        subnet: 'nfvbench-subnet2'
+        name: 'nfvbench-mnet'
+        subnet: 'nfvbench-msubnet'
         cidr: '192.168.3.0/24'
         network_type: 'vlan'
         segmentation_id:
@@ -283,25 +291,45 @@ internal_networks:
 # SRIOV can be used by toggling below setting.
 use_sriov_middle_net: false
 
-# EXT chain only. Names of edge networks which will be used to send traffic via traffic generator.
+# EXT chain only. Prefix names of edge networks which will be 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.
+# An index will be appended to each network name to form the final name:
+# ext-lnet0 ext-rnet0 for chain #0
+# ext-lnet1 ext-rnet1 for chain #1
+# etc...
 external_networks:
-    left: 'nfvbench-net0'
-    right: 'nfvbench-net1'
+    left: 'ext-lnet'
+    right: 'ext-rnet'
 
 # 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)
+# 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)
 vlan_tagging: true
 
-# Specify only when you want to override VLAN IDs used for tagging with own values (exactly 2).
-# Default behavior (empty list) is to retrieve VLAN IDs from OpenStack networks described in external_networks.
-# This property is ignored in the case of l2-loopback
-# Example: [1998, 1999]
+# Used only in the case of EXT chain and no openstack 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: []
 
-# 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.
+# 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
@@ -330,10 +358,6 @@ 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.
@@ -434,3 +458,11 @@ 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