Browse Source

Merge "Introduce port mirroring for sriov-vf"

Zuul 3 months ago
parent
commit
a038872273

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