aboutsummaryrefslogtreecommitdiffstats
path: root/tests/opnfv/test_suites/opnfv_os-odl_l2-fdio-noha_daily.yaml
AgeCommit message (Expand)AuthorFilesLines
2018-04-23remove more old apexlake testcasesRoss Brattain1-4/+0
2018-04-17remove apex lake tc007 from test suitesRoss Brattain1-2/+0
2017-02-17Update missing license headersDeepak S1-0/+8
2016-09-19Added opnfv_os-odl_l2-fdio-noha_daily.yaml and opnfv_os-nosdn-fdio-noha_daily...juraj.linkes1-0/+30
href='#n106'>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 
Traffic Capture
---------------

Tha ability to capture traffic at multiple points of the system is crucial to
many of the functional tests. It allows the verification of functionality for
both the vSwitch and the NICs using hardware acceleration for packet
manipulation and modification.

There are three different methods of traffic capture supported by VSPERF.
Detailed descriptions of these methods as well as their pros and cons can be
found in the following chapters.

Traffic Capture inside of a VM
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This method uses the standard PVP scenario, in which vSwitch first processes
and modifies the packet before forwarding it to the VM. Inside of the VM we
capture the traffic using **tcpdump** or a similiar technique. The capture
information is the used to verify the expected modifications to the packet done
by vSwitch.

.. code-block:: console

                                                            _
       +--------------------------------------------------+  |
       |                                                  |  |
       |   +------------------------------------------+   |  |
       |   |  Traffic capture and Packet Forwarding   |   |  |
       |   +------------------------------------------+   |  |
       |          ^                            :          |  |
       |          |                            |          |  |  Guest
       |          :                            v          |  |
       |   +---------------+          +---------------+   |  |
       |   | logical port 0|          | logical port 1|   |  |
       +---+---------------+----------+---------------+---+ _|
                   ^                          :
                   |                          |
                   :                          v            _
       +---+---------------+----------+---------------+---+  |
       |   | logical port 0|          | logical port 1|   |  |
       |   +---------------+          +---------------+   |  |
       |           ^                          :           |  |
       |           |                          |           |  |  Host
       |           :                          v           |  |
       |   +--------------+            +--------------+   |  |
       |   |   phy port   |  vSwitch   |   phy port   |   |  |
       +---+--------------+------------+--------------+---+ _|
                   ^                          :
                   |                          |
                   :                          v
       +--------------------------------------------------+
       |                                                  |
       |                traffic generator                 |
       |                                                  |
       +--------------------------------------------------+

PROS:

- supports testing with all traffic generators
- easy to use and implement into test
- allows testing hardware offloading on the ingress side

CONS:

- does not allow testing hardware offloading on the egress side

An example of Traffic Capture in VM test:

.. code-block:: python

    # Capture Example 1 - Traffic capture inside VM (PVP scenario)
    # This TestCase will modify VLAN ID set by the traffic generator to the new value.
    # Correct VLAN ID settings is verified by inspection of captured frames.
    {
        Name: capture_pvp_modify_vid,
        Deployment: pvp,
        Description: Test and verify VLAN ID modification by Open vSwitch,
        Parameters : {
            VSWITCH : OvsDpdkVhost, # works also for Vanilla OVS
            TRAFFICGEN_DURATION : 5,
            TRAFFIC : {
                traffic_type : rfc2544_continuous,
                frame_rate : 100,
                'vlan': {
                    'enabled': True,
                    'id': 8,
                    'priority': 1,
                    'cfi': 0,
                },
            },
            GUEST_LOOPBACK : ['linux_bridge'],
        },
        TestSteps: [
            # replace original flows with vlan ID modification
            ['!vswitch', 'add_flow', '$VSWITCH_BRIDGE_NAME', {'in_port': '1', 'actions': ['mod_vlan_vid:4','output:3']}],
            ['!vswitch', 'add_flow', '$VSWITCH_BRIDGE_NAME', {'in_port': '2', 'actions': ['mod_vlan_vid:4','output:4']}],
            ['vswitch', 'dump_flows', '$VSWITCH_BRIDGE_NAME'],
            # verify that received frames have modified vlan ID
            ['VNF0', 'execute_and_wait', 'tcpdump -i eth0 -c 5 -w dump.pcap vlan 4 &'],
            ['trafficgen', 'send_traffic',{}],
            ['!VNF0', 'execute_and_wait', 'tcpdump -qer dump.pcap vlan 4 2>/dev/null | wc -l','|^(\d+)$'],
            ['tools', 'assert', '#STEP[-1][0] == 5'],
        ],
    },

Traffic Capture for testing NICs with HW offloading/acceleration
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The NIC with hardware acceleration/offloading is inserted as an additional card
into the server. Two ports on this card are then connected together using
a patch cable as shown in the diagram. Only a single port of the tested NIC is
setup with DPDK acceleration, while the other is handled by the Linux Ip stack
allowing for traffic capture. The two NICs are then connected by vSwitch so the
original card can forward the processed packets to the traffic generator. The
ports handled by Linux IP stack allow for capturing packets, which are then
analyzed for changes done by both the vSwitch and the NIC with hardware
acceleration.

.. code-block:: console

                                                       _
    +------------------------------------------------+  |
    |                                                |  |
    |   +----------------------------------------+   |  |
    |   |                 vSwitch                |   |  |
    |   |  +----------------------------------+  |   |  |
    |   |  |                                  |  |   |  |
    |   |  |       +------------------+       |  |   |  |
    |   |  |       |                  |       v  |   |  |
    |   +----------------------------------------+   |  |  Device under Test
    |      ^       |                  ^       |      |  |
    |      |       |                  |       |      |  |
    |      |       v                  |       v      |  |
    |   +--------------+          +--------------+   |  |
    |   |              |          | NIC w HW acc |   |  |
    |   |   phy ports  |          |   phy ports  |   |  |
    +---+--------------+----------+--------------+---+ _|
           ^       :                  ^       :
           |       |                  |       |
           |       |                  +-------+
           :       v                 Patch Cable
    +------------------------------------------------+
    |                                                |
    |                traffic generator               |
    |                                                |
    +------------------------------------------------+

PROS:

- allows testing hardware offloading on both the ingress and egress side
- supports testing with all traffic generators
- relatively easy to use and implement into tests

CONS:

- a more complex setup with two cards
- if the tested card only has one port, an additional card is needed

An example of Traffic Capture for testing NICs with HW offloading test:

.. code-block:: python

    # Capture Example 2 - Setup with 2 NICs, where traffic is captured after it is
    # processed by NIC under the test (2nd NIC). See documentation for further details.
    # This TestCase will strip VLAN headers from traffic sent by the traffic generator.
    # The removal of VLAN headers is verified by inspection of captured frames.
    #
    # NOTE: This setup expects a DUT with two NICs with two ports each. First NIC is
    # connected to the traffic generator (standard VSPERF setup). Ports of a second NIC
    # are interconnected by a patch cable. PCI addresses of all four ports have to be
    # properly configured in the WHITELIST_NICS parameter.
    {
        Name: capture_p2p2p_strip_vlan_ovs,
        Deployment: clean,
        Description: P2P Continuous Stream,
        Parameters : {
            _CAPTURE_P2P2P_OVS_ACTION : 'strip_vlan',
            TRAFFIC : {
                bidir : False,
                traffic_type : rfc2544_continuous,
                frame_rate : 100,
                'l2': {
                    'srcmac': ca:fe:00:00:00:00,
                    'dstmac': 00:00:00:00:00:01
                },
                'vlan': {
                    'enabled': True,
                    'id': 8,
                    'priority': 1,
                    'cfi': 0,
                },
            },
            # suppress DPDK configuration, so physical interfaces are not bound to DPDK driver
            'WHITELIST_NICS' : [],
            'NICS' : [],
        },
        TestSteps: _CAPTURE_P2P2P_SETUP + [
            # capture traffic after processing by NIC under the test (after possible egress HW offloading)
            ['tools', 'exec_shell_background', 'tcpdump -i [2][device] -c 5 -w capture.pcap '
                                               'ether src [l2][srcmac]'],
            ['trafficgen', 'send_traffic', {}],
            ['vswitch', 'dump_flows', '$VSWITCH_BRIDGE_NAME'],
            ['vswitch', 'dump_flows', 'br1'],
            # there must be 5 captured frames...
            ['tools', 'exec_shell', 'tcpdump -r capture.pcap | wc -l', '|^(\d+)$'],
            ['tools', 'assert', '#STEP[-1][0] == 5'],
            # ...but no vlan headers
            ['tools', 'exec_shell', 'tcpdump -r capture.pcap vlan | wc -l', '|^(\d+)$'],
            ['tools', 'assert', '#STEP[-1][0] == 0'],
        ],
    },


Traffic Capture on the Traffic Generator
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Using the functionality of the Traffic generator makes it possible to configure
Traffic Capture on both it's ports. With Traffic Capture enabled, VSPERF
instructs the Traffic Generator to automatically export captured data into
a pcap file. The captured packets are then sent to VSPERF for analysis and
verification, monitoring any changes done by both vSwitch and the NICs.

Vsperf currently only supports this functionality with the **T-Rex** generator.

.. code-block:: console

                                                            _
       +--------------------------------------------------+  |
       |                                                  |  |
       |           +--------------------------+           |  |
       |           |                          |           |  |
       |           |                          v           |  |  Host
       |   +--------------+            +--------------+   |  |
       |   |   phy port   |  vSwitch   |   phy port   |   |  |
       +---+--------------+------------+--------------+---+ _|
                   ^                          :
                   |                          |
                   :                          v
       +--------------------------------------------------+
       |                                                  |
       |                traffic generator                 |
       |                                                  |
       +--------------------------------------------------+

PROS:

- allows testing hardware offloading on both the ingress and egress side
- does not require an additional NIC

CONS:

- currently only supported by **T-Rex** traffic generator

An example Traffic Capture on the Traffic Generator test:

.. code-block:: python


    # Capture Example 3 - Traffic capture by traffic generator.
    # This TestCase uses OVS flow to add VLAN tag with given ID into every
    # frame send by traffic generator. Correct frame modificaiton is verified by
    # inspection of packet capture received by T-Rex.
    {
        Name: capture_p2p_add_vlan_ovs_trex,
        Deployment: clean,
        Description: OVS: Test VLAN tag modification and verify it by traffic capture,
        vSwitch : OvsDpdkVhost, # works also for Vanilla OVS
        Parameters : {
            TRAFFICGEN : Trex,
            TRAFFICGEN_DURATION : 5,
            TRAFFIC : {
                traffic_type : rfc2544_continuous,
                frame_rate : 100,
                # enable capture of five RX frames
                'capture': {
                    'enabled': True,
                    'tx_ports' : [],
                    'rx_ports' : [1],
                    'count' : 5,
                },
            },
        },
        TestSteps : STEP_VSWITCH_P2P_INIT + [
            # replace standard L2 flows by flows, which will add VLAN tag with ID 3
            ['!vswitch', 'add_flow', 'int_br0', {'in_port': '1', 'actions': ['mod_vlan_vid:3','output:2']}],
            ['!vswitch', 'add_flow', 'int_br0', {'in_port': '2', 'actions': ['mod_vlan_vid:3','output:1']}],
            ['vswitch', 'dump_flows', 'int_br0'],
            ['trafficgen', 'send_traffic', {}],
            ['trafficgen', 'get_results'],
            # verify that captured frames have vlan tag with ID 3
            ['tools', 'exec_shell', 'tcpdump -qer /#STEP[-1][0][capture_rx] vlan 3 '
                                    '2>/dev/null | wc -l', '|^(\d+)$'],
            # number of received frames with expected VLAN id must match the number of captured frames
            ['tools', 'assert', '#STEP[-1][0] == 5'],
        ] + STEP_VSWITCH_P2P_FINIT,
    },