Merge "Introduce port mirroring for sriov-vf"
This commit is contained in:
Zuul
Gerrit Code Review
commit
a038872273
Binary file not shown.
|
After Width: | Height: | Size: 208 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 97 KiB |
|
|
@ -0,0 +1,200 @@
|
|||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
===================================
|
||||
Port Mirroring API for VF Mirroring
|
||||
===================================
|
||||
|
||||
https://blueprints.launchpad.net/neutron/+spec/port-mirroring-sriov-vf
|
||||
|
||||
Port mirroring is a common feature where specific traffic can be mirrored to
|
||||
a traffic analyzer by configuring rules to identify required flows to be
|
||||
mirrored and by specifying the analyzer where the traffic is mirrored to.
|
||||
In addition, mirroring can be configured on VM interfaces to get all the
|
||||
traffic to and from the interface to the specified analyzer.
|
||||
|
||||
A common use case for this feature is a client requesting an analyzer or probe
|
||||
for traffic that needs to be monitored for a particular VNF using SR-IOV.
|
||||
|
||||
This spec will focus on port mirroring based on SR-IOV VF to VF. Currently this
|
||||
document concentrates on tapping traffic coming in and out of VMs using SR-IOV.
|
||||
This spec is based on enhancements done by Intel on i40e driver, see [9]_
|
||||
|
||||
The current TAPaaS is implemented with OVS ports, see [1]_ and [3]_, this spec
|
||||
will implement the same for the SR-IOV ports.
|
||||
|
||||
|
||||
Problem Description
|
||||
===================
|
||||
|
||||
In virtual environments there are NICs that have capabilities to send a copy
|
||||
of network packets seen on one VF port attached to VNF to another VF port
|
||||
attached to a VM analyzer.
|
||||
|
||||
This spec helps leverage the NIC capability to do the mirroring and using Tap as
|
||||
Service enhancements these features can be configured on hosts and leveraged by
|
||||
tenants.
|
||||
|
||||
The tenant today can use Neutron APIs to create an SRIOV port using provider
|
||||
network with VLAN 0 and physical network that is used in nova.conf passthrough_whitelist.
|
||||
This VF will not have any VLAN filters configured on it. See [2]_.
|
||||
The guest can be configured for multiple VLANs on the same interface. Inside the
|
||||
guest, sub-interfaces can be configured and can communicate on multiple VLANs.
|
||||
|
||||
There are two approaches that can be used for implementing this.
|
||||
|
||||
1. The tenant can use the binding_profile value_spec e.g guest_vlans to define
|
||||
which VLANs will be configured inside guest.
|
||||
|
||||
Since the parameter is configured for a VF in the same manner as other PCI
|
||||
details of a VF, this can be exposed at the same place in the API as other
|
||||
SRIOV related fields in the binding profile.
|
||||
|
||||
Since this spec only describes features available for SRIOV based implementation
|
||||
and the NIC(i40e) only allows VLAN filter for filtering of the packets that
|
||||
need to be mirrored on the NIC, this approach is sufficient until we have a
|
||||
spec for defining multiple VLAN filters for a direct port or on a VF.
|
||||
|
||||
This will also help operators to look at VF config at one place in system
|
||||
rather than running multiple APIs to figure out VFs configuration on host.
|
||||
|
||||
2. The second option is to change the TapFlow to include the new field,
|
||||
vlan_mirror. The TapFlow is the flow classifier for the TapService, so updating
|
||||
it with the new field will provide the agent with the data it needs to
|
||||
configure the port.
|
||||
|
||||
Use Case I. Mirroring of specific VLANs to VF
|
||||
---------------------------------------------
|
||||
|
||||
This use case will handle sending the mirror packets to tap service for a
|
||||
specific VLAN configured on the monitored VF. There can be multiple VLANs
|
||||
configured on the VF.
|
||||
|
||||
|
||||
Proposed Change
|
||||
===============
|
||||
Update Tap as a Service to support VF to VF mirroring.
|
||||
|
||||
The proposed service will allow the tenants to create a tap service instance
|
||||
with SR-IOV port to which the user can add Neutron ports that need to be
|
||||
mirrored by creating tap flows from other SR-IOV port/s.
|
||||
|
||||
The user can define various port mirroring flows for the tap service, so one
|
||||
tap service should be able to handle multiple tap flows.
|
||||
|
||||
.. image:: ../../images/port-mirroring-vfs.png
|
||||
|
||||
Use Case I. Mirroring of specific VLANs to VF
|
||||
---------------------------------------------
|
||||
|
||||
This spec will also take care of developing a new driver for Tap for
|
||||
NicSwitchTapDriver that will perform the sysfs implementation for Intel's
|
||||
custom i40e driver.
|
||||
|
||||
.. image:: ../../images/tapaas-port-mirroring-vfs.png
|
||||
|
||||
The VFs will be derived from source port and the probe port attached
|
||||
to TapService. Example of how a user could mirror traffic based upon
|
||||
VLANs 2,4,6,18-22 to VF 3 of PF p1p1
|
||||
|
||||
# echo add 2,4,6,18-22>/sys/class/net/p1p1/device/sriov/3/vlan_mirror
|
||||
|
||||
Example on how a user could remove VLAN 4, 15-17 from traffic mirroring
|
||||
at destination VF
|
||||
|
||||
# echo rem 4,15-17>/sys/class/net/p1p1/device/sriov/3/vlan_mirror
|
||||
|
||||
Example on how a user could remove all VLANs from mirroring at VF 3.
|
||||
# echo rem 0 - 4095>/sys/class/net/p1p1/device/sriov/3/vlan_mirror
|
||||
|
||||
The limitation of this mirror is that the vlan/s monitored get traffic in
|
||||
BOTH direction on probe or service port.
|
||||
|
||||
The mirrored packets captured on the VF associated with Tap service will
|
||||
have vlan tags that are specified in field vlan_filter.
|
||||
|
||||
Data Model Impact
|
||||
-----------------
|
||||
This approach will change data model for TapFlow object to include new
|
||||
field vlan_filter.
|
||||
|
||||
|
||||
REST API Impact
|
||||
---------------
|
||||
The implementation will be based on option 2. in section Problem description above.
|
||||
The change will be made to the TapFlow object to add the vlan_filter field in
|
||||
order for the ports to be able to filter which traffic to mirror. See [4]_
|
||||
The vlan_filter can be used to monitor a single vlan or a vlan range so
|
||||
the values can be specified as a string like "171" or "161-164" or "161-164,171".
|
||||
|
||||
Tap Agent and Driver Impact
|
||||
---------------------------
|
||||
Tap Agent and driver for direct ports will be developed as per usecases above
|
||||
to configure NIC via sysfs.
|
||||
|
||||
|
||||
Effects on Existing Tap As Service APIs
|
||||
----------------------------------------
|
||||
vlan_filter will be added to TapFlow API to filter the traffic that need to be
|
||||
mirrored.
|
||||
|
||||
Command Line Client Impact
|
||||
--------------------------
|
||||
Openstack/Neutron client need to be updated to support TAPaaS. See [7]_
|
||||
|
||||
Heat support Impact
|
||||
-------------------
|
||||
|
||||
The Tap as service resources do not exist in Openstack. We need to create new
|
||||
heat resources to support that. See [8]_
|
||||
|
||||
|
||||
Implementation
|
||||
==============
|
||||
The Tap As a Service Agents need to add support for SR-IOV ports. Need to
|
||||
develop a framework to support multiple agents. Also define the taas agent for
|
||||
sriov ports, taas-sriov-agent. Currently there is agent only for ovs.
|
||||
As part of the implementation a new driver for Tap as a service will be developed
|
||||
NicSwitchTapDriver as mentioned above in proposal. See [6]_
|
||||
Earlier an attempt to keep SRIOV params together was done in implementation by
|
||||
updating the binding profile, the change was abandoned. See [5]_
|
||||
|
||||
|
||||
Additional work to integrate with Neutron Stadium
|
||||
-------------------------------------------------
|
||||
|
||||
Tempest tests for the new agent and driver.
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. [1] `TAP as a Service`:
|
||||
https://docs.openstack.org/dragonflow/latest/specs/tap_as_a_service.html
|
||||
|
||||
.. [2] `Networking Guide: SR-IOV`:
|
||||
https://docs.openstack.org/neutron/queens/admin/config-sriov.html#enable-neutron-sriov-agent-compute
|
||||
|
||||
.. [3] `Tap-as-a-service spec`:
|
||||
https://review.openstack.org/#/c/256210/
|
||||
|
||||
.. [4] `Tap as a Service API REFERENCE`:
|
||||
https://github.com/openstack/tap-as-a-service/blob/master/API_REFERENCE.rst
|
||||
|
||||
.. [5] `(Old)Implemention of vlan filter for mirroring by changing binding profile in neutron port`:
|
||||
https://review.openstack.org/#/c/594310/
|
||||
|
||||
.. [6] `Implementation of vlan filter for mirroing by adding vlan mirror filter to TapFlow`:
|
||||
https://review.openstack.org/#/c/603501/
|
||||
|
||||
.. [7] `Heat resources for Tap as Service`:
|
||||
https://review.openstack.org/#/c/591523/
|
||||
|
||||
.. [8] `Openstack Client update for support of Tap as Service vlan filter`
|
||||
https://review.openstack.org/#/c/589253/
|
||||
|
||||
.. [9] Intel enhanced i40e driver for support of vlan mirror filtering.
|
||||
https://sourceforge.net/projects/e1000/files/i40e%20stable/2.7.12/
|
||||
Loading…
Reference in New Issue