Browse Source

Introduce port mirroring for sriov-vf

 Add SRIOV mirroring support to Tap as a Service.
   Allows Vlans to VF mirror.
   Allows VF to VF mirror.

 Spec for new tap agent for sriov and driver for Intel i40e nic.
 Added the two implementation approaches to API.

Change-Id: If2e4e2bf70f11ab0136482cb86acad3a3eded649
Munish Mehan 10 months ago
parent
commit
f4591c55de

BIN
images/port-mirroring-vfs.png View File


BIN
images/tapaas-port-mirroring-vfs.png View File


+ 200
- 0
specs/stein/port-mirroring-sriov-vfs.rst View File

@@ -0,0 +1,200 @@
1
+..
2
+ This work is licensed under a Creative Commons Attribution 3.0 Unported
3
+ License.
4
+
5
+ http://creativecommons.org/licenses/by/3.0/legalcode
6
+
7
+===================================
8
+Port Mirroring API for VF Mirroring
9
+===================================
10
+
11
+https://blueprints.launchpad.net/neutron/+spec/port-mirroring-sriov-vf
12
+
13
+Port mirroring is a common feature where specific traffic can be mirrored to
14
+a traffic analyzer by configuring rules to identify required flows to be
15
+mirrored and by specifying the analyzer where the traffic is mirrored to.
16
+In addition, mirroring can be configured on VM interfaces to get all the
17
+traffic to and from the interface to the specified analyzer.
18
+
19
+A common use case for this feature is a client requesting an analyzer or probe
20
+for traffic that needs to be monitored for a particular VNF using SR-IOV.
21
+
22
+This spec will focus on port mirroring based on SR-IOV VF to VF. Currently this
23
+document concentrates on tapping traffic coming in and out of VMs using SR-IOV.
24
+This spec is based on enhancements done by Intel on i40e driver, see [9]_
25
+
26
+The current TAPaaS is implemented with OVS ports, see [1]_ and [3]_, this spec
27
+will implement the same for the SR-IOV ports.
28
+
29
+
30
+Problem Description
31
+===================
32
+
33
+In virtual environments there are NICs that have capabilities to send a copy
34
+of network packets seen on one VF port attached to VNF to another VF port
35
+attached to a VM analyzer.
36
+
37
+This spec helps leverage the NIC capability to do the mirroring and using Tap as
38
+Service enhancements these features can be configured on hosts and leveraged by
39
+tenants.
40
+
41
+The tenant today can use Neutron APIs to create an SRIOV port using provider
42
+network with VLAN 0 and physical network that is used in nova.conf passthrough_whitelist.
43
+This VF will not have any VLAN filters configured on it. See [2]_.
44
+The guest can be configured for multiple VLANs on the same interface. Inside the
45
+guest, sub-interfaces can be configured and can communicate on multiple VLANs.
46
+
47
+There are two approaches that can be used for implementing this.
48
+
49
+1. The tenant can use the binding_profile value_spec e.g guest_vlans to define
50
+which VLANs will be configured inside guest.
51
+
52
+Since the parameter is configured for a VF in the same manner as other PCI
53
+details of a VF, this can be exposed at the same place in the API as other
54
+SRIOV related fields in the binding profile.
55
+
56
+Since this spec only describes features available for SRIOV based implementation
57
+and the NIC(i40e) only allows VLAN filter for filtering of the packets that
58
+need to be mirrored on the NIC, this approach is sufficient until we have a
59
+spec for defining multiple VLAN filters for a direct port or on a VF.
60
+
61
+This will also help operators to look at VF config at one place in system
62
+rather than running multiple APIs to figure out VFs configuration on host.
63
+
64
+2. The second option is to change the TapFlow to include the new field,
65
+vlan_mirror. The TapFlow is the flow classifier for the TapService, so updating
66
+it with the new field will provide the agent with the data it needs to
67
+configure the port.
68
+
69
+Use Case I. Mirroring of specific VLANs to VF
70
+---------------------------------------------
71
+
72
+This use case will handle sending the mirror packets to tap service for a
73
+specific VLAN configured on the monitored VF. There can be multiple VLANs
74
+configured on the VF.
75
+
76
+
77
+Proposed Change
78
+===============
79
+Update Tap as a Service to support VF to VF mirroring.
80
+
81
+The proposed service will allow the tenants to create a tap service instance
82
+with SR-IOV port to which the user can add Neutron ports that need to be
83
+mirrored by creating tap flows from other SR-IOV port/s.
84
+
85
+The user can define various port mirroring flows for the tap service, so one
86
+tap service should be able to handle multiple tap flows.
87
+
88
+.. image:: ../../images/port-mirroring-vfs.png
89
+
90
+Use Case I. Mirroring of specific VLANs to VF
91
+---------------------------------------------
92
+
93
+This spec will also take care of developing a new driver for Tap for
94
+NicSwitchTapDriver that will perform the sysfs implementation for Intel's
95
+custom i40e driver.
96
+
97
+.. image:: ../../images/tapaas-port-mirroring-vfs.png
98
+
99
+The VFs will be derived from source port and the probe port attached
100
+to TapService. Example of how a user could mirror traffic based upon
101
+VLANs 2,4,6,18-22 to VF 3 of PF p1p1
102
+
103
+# echo add 2,4,6,18-22>/sys/class/net/p1p1/device/sriov/3/vlan_mirror
104
+
105
+Example on how a user could remove VLAN 4, 15-17 from traffic mirroring
106
+at destination VF
107
+
108
+# echo rem 4,15-17>/sys/class/net/p1p1/device/sriov/3/vlan_mirror
109
+
110
+Example on how a user could remove all VLANs from mirroring at VF 3.
111
+# echo rem 0 - 4095>/sys/class/net/p1p1/device/sriov/3/vlan_mirror
112
+
113
+The limitation of this mirror is that the vlan/s monitored get traffic in
114
+BOTH direction on probe or service port.
115
+
116
+The mirrored packets captured on the VF associated with Tap service will
117
+have vlan tags that are specified in field vlan_filter.
118
+
119
+Data Model Impact
120
+-----------------
121
+This approach will change data model for TapFlow object to include new
122
+field vlan_filter.
123
+
124
+
125
+REST API Impact
126
+---------------
127
+The implementation will be based on option 2. in section Problem description above.
128
+The change will be made to the TapFlow object to add the vlan_filter field in
129
+order for the ports to be able to filter which traffic to mirror. See [4]_
130
+The vlan_filter can be used to monitor a single vlan or a vlan range so
131
+the values can be specified as a string like "171" or "161-164" or "161-164,171".
132
+
133
+Tap Agent and Driver Impact
134
+---------------------------
135
+Tap Agent and driver for direct ports will be developed as per usecases above
136
+to configure NIC via sysfs.
137
+
138
+
139
+Effects on Existing Tap As Service APIs
140
+----------------------------------------
141
+vlan_filter will be added to TapFlow API to filter the traffic that need to be
142
+mirrored.
143
+
144
+Command Line Client Impact
145
+--------------------------
146
+Openstack/Neutron client need to be updated to support TAPaaS. See [7]_
147
+
148
+Heat support Impact
149
+-------------------
150
+
151
+The Tap as service resources do not exist in Openstack. We need to create new
152
+heat resources to support that. See [8]_
153
+
154
+
155
+Implementation
156
+==============
157
+The Tap As a Service Agents need to add support for SR-IOV ports. Need to
158
+develop a framework to support multiple agents. Also define the taas agent for
159
+sriov ports, taas-sriov-agent. Currently there is agent only for ovs.
160
+As part of the implementation a new driver for Tap as a service will be developed
161
+NicSwitchTapDriver as mentioned above in proposal. See [6]_
162
+Earlier an attempt to keep SRIOV params together was done in implementation by
163
+updating the binding profile, the change was abandoned. See [5]_
164
+
165
+
166
+Additional work to integrate with Neutron Stadium
167
+-------------------------------------------------
168
+
169
+Tempest tests for the new agent and driver.
170
+
171
+
172
+References
173
+==========
174
+
175
+.. [1] `TAP as a Service`:
176
+       https://docs.openstack.org/dragonflow/latest/specs/tap_as_a_service.html
177
+
178
+.. [2] `Networking Guide: SR-IOV`:
179
+       https://docs.openstack.org/neutron/queens/admin/config-sriov.html#enable-neutron-sriov-agent-compute
180
+
181
+.. [3] `Tap-as-a-service spec`:
182
+       https://review.openstack.org/#/c/256210/
183
+
184
+.. [4] `Tap as a Service API REFERENCE`:
185
+       https://github.com/openstack/tap-as-a-service/blob/master/API_REFERENCE.rst
186
+
187
+.. [5] `(Old)Implemention of vlan filter for mirroring by changing binding profile in neutron port`:
188
+       https://review.openstack.org/#/c/594310/
189
+
190
+.. [6] `Implementation of vlan filter for mirroing by adding vlan mirror filter to TapFlow`:
191
+       https://review.openstack.org/#/c/603501/
192
+
193
+.. [7] `Heat resources for Tap as Service`:
194
+       https://review.openstack.org/#/c/591523/
195
+
196
+.. [8] `Openstack Client update for support of Tap as Service vlan filter`
197
+       https://review.openstack.org/#/c/589253/
198
+
199
+.. [9] Intel enhanced i40e driver for support of vlan mirror filtering.
200
+       https://sourceforge.net/projects/e1000/files/i40e%20stable/2.7.12/

Loading…
Cancel
Save