Browse Source

Changing segmentation ID of existing network should be allowed

In the context of a live datacenter, sometimes the network teams re-organize
their VLANs by changing VLAN IDs. This is pretty straightforward in the
context of network configuration and physical servers, but when using ML2
VLAN provider networks, those IDs cannot be updated. The only possible
solution here would be to delete those networks and recreate them with a
different segmentation ID which might be a problem when you have 1000 VMs
and 2000 ports.

For this reason it would be good if we could change the segmentation ID of
an existing network.

Change-Id: I71b5b4ff2ba7ace3a8523de2ae6e4dc6a1c110c2
Related-Bug: #1806052
Rodolfo Alonso Hernandez 2 months ago
parent
commit
3f9ca0e441
1 changed files with 197 additions and 0 deletions
  1. 197
    0
      specs/stein/change-segmentation-id-vlan-provider-network.rst

+ 197
- 0
specs/stein/change-segmentation-id-vlan-provider-network.rst View File

@@ -0,0 +1,197 @@
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
+Change the segment ID of a VLAN provider network
9
+================================================
10
+
11
+Launchpad bug:
12
+https://bugs.launchpad.net/neutron/+bug/1806052
13
+
14
+This spec proposes a method to change the segmentation ID of a VLAN-type
15
+network, which is the external VLAN ID of the network. The implementation
16
+described is limited to only the OVS back-end and to single-segment
17
+provider networks.
18
+
19
+
20
+Problem Description
21
+===================
22
+
23
+Currently, Neutron does not allow the segmentation ID parameter of a provider
24
+network to change, regardless of the status of the network (active or not) or
25
+if ports exist on the network (or not). In order to change the segmentation ID,
26
+the administrator needs to delete the network, first un-binding any bound
27
+ports, then create a new network with the required segmentation ID, and
28
+finally bind the ports back to the network.
29
+
30
+
31
+Proposed Change
32
+===============
33
+
34
+The proposed solution is to be able to change the segmentation ID of a VLAN-
35
+type network, using one single command ("openstack network set") in an atomic
36
+operation.
37
+
38
+In order to implement this, several changes are needed:
39
+
40
+* The CLI, to allow to update the segmentation ID in an existing network.
41
+* The Neutron server, to allow writing those changes in the database.
42
+* The networking back-end. In this spec only OVS is covered and the
43
+  implementation will be limited to it.
44
+
45
+
46
+OpenStack Client
47
+----------------
48
+
49
+Currently, the OpenStack Client allows updating the segmentation ID of an
50
+existing network. No changes are needed.
51
+
52
+
53
+Neutron server
54
+--------------
55
+
56
+Currently, when a network update message is sent to the Neutron server, if any
57
+provider attribute is present in this message, for example 'segmentation ID',
58
+this command is rejected. The new implementation will allow updating the
59
+segmentation ID:
60
+
61
+* If the segmentation ID is the only provider parameter to be updated. No other
62
+  provider parameters (network type, physical network) are allowed.
63
+* If the network has only one segment. In multi provider networks the server
64
+  doesn't know which one of the segments should be updated.
65
+* If the provider segment type is 'vlan'. No other types are allowed.
66
+* If all ports bound to this network belong to a compatible network driver. A
67
+  compatible network driver is one which has implemented this change. In
68
+  this spec, the OVS agent implementation is described. For example, with OVS,
69
+  ports with VIF type 'vhostuser' and 'ovs' are accepted, and 'unbound' or
70
+  'binding_failed' are also allowed because they are not yet bound to any
71
+  network driver.
72
+
73
+If the above conditions are all met, the Neutron server will execute the
74
+following actions (in order):
75
+
76
+* Validate the new segment, to know if the segmentation ID falls inside the
77
+  minimum and maximum VLAN tags.
78
+* Reserve a new provider segment. This will ensure the segmentation ID is not
79
+  used in this network.
80
+* Create a new provider segment in the database.
81
+* Release the old provider segment.
82
+* Delete the old provider segment from the database.
83
+
84
+All these operations will be executed inside a write context, to provide
85
+concurrency and enable rollback in case of failure. If any of these database
86
+operations fail, including subsequent ones, the context will prevent the old
87
+segment from being deleted and the new one will not be created.
88
+
89
+
90
+Mechanism driver
91
+----------------
92
+
93
+The agent mechanism driver interface will be extended with a new function. This
94
+function will return a list of provider network attributes that can be modified
95
+in a network with ports bound to this networking back-end.
96
+
97
+By default, this function will return an empty list.
98
+
99
+
100
+Neutron OVS agent
101
+-----------------
102
+
103
+In the OVS agent, VLAN provider networks can access the provider network
104
+outside the host through the physical bridges. Each provider network has a
105
+single physical bridge assigned. A physical bridge can host the traffic of
106
+multiple provider networks, but each provider network can only send and receive
107
+traffic through one physical bridge. There is a N:1 (network:physical bridge)
108
+relationship.
109
+
110
+Inside the integration bridge, the tenant networks are isolated using virtual
111
+networks. These virtual networks have their own VLAN ID mapping, different from
112
+the provider networks VLAN ID mapping. Both VLAN maps are related through the
113
+"LocalVlanManager", which is in charge of correlating both mappings. When a
114
+packet from a tenant exits the integration bridge to the corresponding physical
115
+bridge, a flow changes the VLAN tag from the tenant VLAN ID to the provider
116
+segmentation ID. The opposite process happens in the physical bridge::
117
+
118
+  br_int:
119
+  cookie=0xb46613524bd0de42, duration=23646.484s, table=0, n_packets=0,
120
+    n_bytes=0, priority=3,in_port="int-br-phy",dl_vlan=1074
121
+    actions=mod_vlan_vid:1,resubmit(,60)
122
+
123
+  br_phy:
124
+  cookie=0x43209f9280b7fc88, duration=23666.003s, table=0, n_packets=10,
125
+    n_bytes=788, priority=4,in_port="phy-br-phy",dl_vlan=1
126
+    actions=mod_vlan_vid:1074,NORMAL
127
+
128
+When a network segmentation ID is updated, the only change needed is to update
129
+the new segmentation ID in both flows. This could be done by deleting both
130
+flows and then creating them again with the new segmentation ID. For example::
131
+
132
+  phys_br.reclaim_local_vlan(port=phys_port, lvid=lvid)
133
+  phys_br.provision_local_vlan(
134
+      port=phys_port, lvid=lvid,
135
+      segmentation_id=new_segmentation_id,
136
+      distributed=self.enable_distributed_routing)
137
+  self.int_br.reclaim_local_vlan(port=int_port,
138
+      segmentation_id=old_segmentation_id)
139
+  self.int_br.provision_local_vlan(
140
+      port=int_port, lvid=lvid,
141
+      segmentation_id=new_segmentation_id)
142
+
143
+
144
+Limitations
145
+-----------
146
+
147
+As commented, this solution will be available only for:
148
+
149
+* Single segment networks.
150
+* VLAN type networks.
151
+* Only OVS (kernel OVS or DPDK OVS) bound ports to this network.
152
+
153
+
154
+Data Model
155
+----------
156
+
157
+No changes.
158
+
159
+
160
+REST API
161
+--------
162
+
163
+A new ML2 RPC call, requested from the agent side, is needed. This new call
164
+will provide information about the updated network. With this information the
165
+agent will know if the network has changed the segmentation ID (as commented,
166
+the "LocalVlanManager" singleton stores this information).
167
+
168
+
169
+CLI impact
170
+----------
171
+
172
+No changes.
173
+
174
+
175
+Operation Impact
176
+----------------
177
+
178
+The segmentation ID change implies two actions:
179
+
180
+* To change the segmentation ID of a Neutron network without unbinding the
181
+  attached ports. Once this process is done in Neutron, the traffic from those
182
+  ports will be tagged with the new VLAN ID and transmitted through the
183
+  provider network.
184
+* To change the provider network segmentation. This process is external to
185
+  Neutron (and OpenStack).
186
+
187
+Because those processes cannot be done at the same time, the administrator
188
+should decide, depending on the site network infrastructure, the order of
189
+execution. Until both the segmentation ID of the Neutron network and the
190
+VLAN ID of the external provider network are synchronized, there will be a
191
+networking disruption.
192
+
193
+
194
+References
195
+==========
196
+
197
+None.

Loading…
Cancel
Save