1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
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
|
README.Debian for openvswitch-switch
---------------------------------
The Linux kernel 3.3 or later has an integrated Open vSwitch kernel
module. Theis Linux kernel module lacks a few features that are in
the third-party module. For details, please see the FAQ, "What
features are not available in the Open vSwitch kernel datapath that
ships as part of the upstream Linux kernel?". If you need the
additional features, you will need to build and install a Linux kernel
module by hand from the openvswitch source package.
Debian network scripts (ifupdown) integration
------------------------------------------------
This package lets a user to optionally configure Open vSwitch bridges
and ports from /etc/network/interfaces. Please refer to the interfaces(5)
manpage for more details regarding /etc/network/interfaces.
The stanzas that configure the OVS bridges should begin with "allow-ovs"
followed by name of the bridge. Here is an example.
allow-ovs br0
The stanzas that configure the OVS ports should begin with
"allow-${bridge-name}" followed by name of the port. Here is an example.
allow-br0 eth0
The following OVS specific "command" options are supported:
- ovs_type: This can either be OVSBridge, OVSPort, OVSIntPort, OVSBond,
OVSPatchPort or OVSTunnel depending on whether you configure a bridge,
port, an internal port, a bond, a patch port or a tunnel. This is a
required option.
- ovs_ports: This option specifies all the ports that belong to a bridge.
- ovs_bridge: This options specifies a bridge to which a port belongs.
This is a required option for a port.
- ovs_bonds: This option specifies the list of physical interfaces to be
bonded together.
- ovs_patch_peer: For "OVSPatchPort" interfaces, this field specifies
the patch's peer on the other bridge.
- ovs_tunnel_type: For "OVSTunnel" interfaces, the type of the tunnel.
For example, "gre", "vxlan", etc.
- ovs_tunnel_options: For "OVSTunnel" interfaces, this field should be
used to specify the tunnel options like remote_ip, key, etc.
- ovs_options: This option lets you add extra arguments to a ovs-vsctl
command. See examples.
- ovs_extra: This option lets you run additional ovs-vsctl commands,
separated by "--" (double dash). Variables can be part of the "ovs_extra"
option. You can provide all the standard environmental variables
described in the interfaces(5) man page. You can also pass shell
commands.
More implementation specific details can be seen in the examples.
Examples:
--------
ex 1: A standalone bridge.
allow-ovs br0
iface br0 inet static
address 192.168.1.1
netmask 255.255.255.0
ovs_type OVSBridge
ex 2: A bridge with one port.
allow-ovs br0
iface br0 inet dhcp
ovs_type OVSBridge
ovs_ports eth0
allow-br0 eth0
iface eth0 inet manual
ovs_bridge br0
ovs_type OVSPort
ex 3: A bridge with multiple physical ports.
allow-ovs br0
iface br0 inet dhcp
ovs_type OVSBridge
ovs_ports eth0 eth1
allow-br0 eth0
iface eth0 inet manual
ovs_bridge br0
ovs_type OVSPort
allow-br0 eth1
iface eth1 inet manual
ovs_bridge br0
ovs_type OVSPort
ex 4: A bridge with an OVS internal port.
allow-ovs br1
iface br1 inet static
address 192.168.1.1
netmask 255.255.255.0
ovs_type OVSBridge
ovs_ports vlan100
allow-br1 vlan100
iface vlan100 inet manual
ovs_bridge br1
ovs_type OVSIntPort
ovs_options tag=100
ovs_extra set interface ${IFACE} external-ids:iface-id=$(hostname -s)
ex 5: Bonding.
allow-ovs br2
iface br2 inet static
address 192.170.1.1
netmask 255.255.255.0
ovs_type OVSBridge
ovs_ports bond0
allow-br2 bond0
iface bond0 inet manual
ovs_bridge br2
ovs_type OVSBond
ovs_bonds eth2 eth3
ovs_options bond_mode=balance-tcp lacp=active
ex 6: Patch ports.
allow-ovs br0
iface br0 inet manual
ovs_type OVSBridge
ovs_ports patch0
allow-br0 patch0
iface patch0 inet manual
ovs_bridge br0
ovs_type OVSPatchPort
ovs_patch_peer patch1
allow-ovs br1
iface br1 inet manual
ovs_type OVSBridge
ovs_ports patch1
allow-br1 patch1
iface patch1 inet manual
ovs_bridge br1
ovs_type OVSPatchPort
ovs_patch_peer patch0
ex 7: Tunnel.
allow-ovs br1
iface br1 inet static
address 192.168.1.1
netmask 255.255.255.0
ovs_type OVSBridge
ovs_ports gre1
allow-br1 gre1
iface gre1 inet manual
ovs_bridge br1
ovs_type OVSTunnel
ovs_tunnel_type gre
ovs_tunnel_options options:remote_ip=182.168.1.2 options:key=1
ex 8: Create and destroy bridges.
ifup --allow=ovs $list_of_bridges
ifdown --allow=ovs $list_of_bridges
Open vSwitch integration with systemd-networkd
-----------------------------------------------
There is no native integration of OVS with systemd-networkd. That is,
you cannot create OVS bridges, ports and bonds by simply writing configuration
files in /etc/systemd/network. But, you can create OVS devices using ovs-vsctl
and then write configuration files to provide them IP addresses.
As soon as a OVS device is visible, systemd-networkd will provide that device
an IP address. Since OVS database is persistent across reboots, the OVS
devices will get re-created after a reboot as soon as OVS startup script is
invoked. And systemd-networkd will immediately assign the configuration defined
in /etc/systemd/network.
Example:
If you have a physical ethernet device "ens160" which has been configured with
DHCP, your systemd-networkd's .network config file will look something like
this:
```
[Match]
Name=ens160
[Network]
DHCP=ipv4
[DHCP]
ClientIdentifier=mac
```
Please note how the DHCP ClientIdentifier above has been configured with the
mac address.
To create a OVS bridge "br-ens160" and add "ens160" as a port of that
bridge, you can change the .network configuration for "ens160" to look like:
```
[Match]
Name=ens160
```
Now create a new .network configuration file for "br-ens160". Something like:
```
[Match]
Name=br-ens160
[Network]
DHCP=ipv4
[DHCP]
ClientIdentifier=mac
```
Now, use ovs-vsctl to create br-ens160 and add ens160 as a port of it. You
will also have to flush the IP address of ens160 and restart systemd-networkd
in the same line. It is important to let br-ens160 have the same mac address as
ens160 to get the same IP address to br-ens160 from the DHCP server. In the
below command, "$mac_of_ens160" holds the mac address of ens160. For e.g:
```
mac_of_ens160='"00:0c:29:77:27:7a"'
ovs-vsctl --may-exist add-br br-ens160 -- \
--may-exist add-port br-ens160 ens160 -- \
set interface br-ens160 mac="$mac_of_ens160"; ip addr flush dev ens160; \
systemctl restart systemd-networkd
```
br-ens160 should now have the same DHCP IP. It should also have the correct
DNS resolution servers configured.
Notes on dependencies:
---------------------
openvswitch-switch depends on $network, $named $remote_fs and $syslog to start.
This creates some startup dependency issues.
* Since openvswitch utilities are placed in /usr and /usr can be mounted
through NFS, openvswitch has to start after it. But if a user uses openvswitch
for all his networking needs and hence to mount NFS, there will be a deadlock.
So, if /usr is mounted through NFS and openvswitch is used for all networking,
the administrator should figure out a way to mount NFS before starting OVS.
One way to do this is in initramfs.
* Since openvswitch starts after $network, $remote_fs and $syslog, any startup
script that depends on openvswitch but starts before it, needs to be changed
to depend on openvswitch-switch too.
* Ideally, an admin should not add openvswitch bridges in the 'auto'
section of the 'interfaces' file (i.e., if "br0" is a OVS bridge, you should
not have a line "auto br0"). This is because, when ifupdown starts
working on bridges listed in 'auto', openvswitch has not yet started.
But, if the admin wants to go down this route and adds openvswitch bridges
in the 'auto' section, openvswitch-switch will forcefully be started when
ifupdown kicks in. In a case like this, the admin needs to make sure that /usr
has already been mounted and that a remote $syslog (if used) is ready to
receive openvswitch logs.
* With systemd, adding openvswitch bridges in the 'auto' section of the
'interfaces' file can cause race conditions (i.e., if "br0" is a OVS bridge,
you should not have a line "auto br0"). Debian systems have added a
systemd ifup@.service file. This file will call ifdown and ifup on interfaces
in "auto" section automatically when the interfaces disappear and appear
respectively. This will cause race conditions if you delete and add the same
bridges using tools like "ovs-vsctl" or "ovs-dpctl". This is also a problem
when you upgrade your openvswitch kernel module using commands like
'force-reload-kmod'.
|
