]>
Commit | Line | Data |
---|---|---|
c483d489 BP |
1 | Open vSwitch <http://openvswitch.org> |
2 | ||
3 | Frequently Asked Questions | |
4 | ========================== | |
5 | ||
6 | Configuration Problems | |
7 | ---------------------- | |
8 | ||
9 | Q: I created a bridge and added my Ethernet port to it, using commands | |
10 | like these: | |
11 | ||
12 | ovs-vsctl add-br br0 | |
13 | ovs-vsctl add-port br0 eth0 | |
14 | ||
15 | and as soon as I ran the "add-port" command I lost all connectivity | |
16 | through eth0. Help! | |
17 | ||
18 | A: A physical Ethernet device that is part of an Open vSwitch bridge | |
19 | should not have an IP address. If one does, then that IP address | |
20 | will not be fully functional. | |
21 | ||
22 | You can restore functionality by moving the IP address to an Open | |
23 | vSwitch "internal" device, such as the network device named after | |
24 | the bridge itself. For example, assuming that eth0's IP address is | |
25 | 192.168.128.5, you could run the commands below to fix up the | |
26 | situation: | |
27 | ||
28 | ifconfig eth0 0.0.0.0 | |
29 | ifconfig br0 192.168.128.5 | |
30 | ||
31 | (If your only connection to the machine running OVS is through the | |
32 | IP address in question, then you would want to run all of these | |
33 | commands on a single command line, or put them into a script.) If | |
34 | there were any additional routes assigned to eth0, then you would | |
35 | also want to use commands to adjust these routes to go through br0. | |
36 | ||
37 | If you use DHCP to obtain an IP address, then you should kill the | |
38 | DHCP client that was listening on the physical Ethernet interface | |
39 | (e.g. eth0) and start one listening on the internal interface | |
40 | (e.g. br0). You might still need to manually clear the IP address | |
41 | from the physical interface (e.g. with "ifconfig eth0 0.0.0.0"). | |
42 | ||
43 | There is no compelling reason why Open vSwitch must work this way. | |
44 | However, this is the way that the Linux kernel bridge module has | |
45 | always worked, so it's a model that those accustomed to Linux | |
46 | bridging are already used to. Also, the model that most people | |
47 | expect is not implementable without kernel changes on all the | |
48 | versions of Linux that Open vSwitch supports. | |
49 | ||
50 | By the way, this issue is not specific to physical Ethernet | |
51 | devices. It applies to all network devices except Open vswitch | |
52 | "internal" devices. | |
53 | ||
54 | Q: I created a bridge and added a couple of Ethernet ports to it, | |
55 | using commands like these: | |
56 | ||
57 | ovs-vsctl add-br br0 | |
58 | ovs-vsctl add-port br0 eth0 | |
59 | ovs-vsctl add-port br0 eth1 | |
60 | ||
61 | and now my network seems to have melted: connectivity is unreliable | |
62 | (even connectivity that doesn't go through Open vSwitch), all the | |
63 | LEDs on my physical switches are blinking, and wireshark shows | |
64 | duplicated packets. | |
65 | ||
66 | A: More than likely, you've looped your network. Probably, eth0 and | |
67 | eth1 are connected to the same physical Ethernet switch. This | |
68 | yields a scenario where OVS receives a broadcast packet on eth0 and | |
69 | sends it out on eth1, then the physical switch connected to eth1 | |
70 | sends the packet back on eth0, and so on forever. More complicated | |
71 | scenarios, involving a loop through multiple switches, are possible | |
72 | too. | |
73 | ||
74 | The solution depends on what you are trying to do: | |
75 | ||
76 | - If you added eth0 and eth1 to get higher bandwidth or higher | |
77 | reliability between OVS and your physical Ethernet switch, | |
78 | use a bond. The following commands create br0 and then add | |
79 | eth0 and eth1 as a bond: | |
80 | ||
81 | ovs-vsctl add-br br0 | |
82 | ovs-vsctl add-bond br0 bond0 eth0 eth1 | |
83 | ||
84 | Bonds have tons of configuration options. Please read the | |
85 | documentation on the Port table in ovs-vswitchd.conf.db(5) | |
86 | for all the details. | |
87 | ||
88 | - Perhaps you don't actually need eth0 and eth1 to be on the | |
89 | same bridge. For example, if you simply want to be able to | |
90 | connect each of them to virtual machines, then you can put | |
91 | each of them on a bridge of its own: | |
92 | ||
93 | ovs-vsctl add-br br0 | |
94 | ovs-vsctl add-port br0 eth0 | |
95 | ||
96 | ovs-vsctl add-br br1 | |
97 | ovs-vsctl add-port br1 eth1 | |
98 | ||
99 | and then connect VMs to br0 and br1. (A potential | |
100 | disadvantage is that traffic cannot directly pass between br0 | |
101 | and br1. Instead, it will go out eth0 and come back in eth1, | |
102 | or vice versa.) | |
103 | ||
104 | - If you have a redundant or complex network topology and you | |
105 | want to prevent loops, turn on spanning tree protocol (STP). | |
106 | The following commands create br0, enable STP, and add eth0 | |
107 | and eth1 to the bridge. The order is important because you | |
108 | don't want have to have a loop in your network even | |
109 | transiently: | |
110 | ||
111 | ovs-vsctl add-br br0 | |
112 | ovs-vsctl set bridge br0 stp_enable=true | |
113 | ovs-vsctl add-port br0 eth0 | |
114 | ovs-vsctl add-port br0 eth1 | |
115 | ||
116 | The Open vSwitch implementation of STP is not well tested. | |
117 | Please report any bugs you observe, but if you'd rather avoid | |
118 | acting as a beta tester then another option might be your | |
119 | best shot. | |
120 | ||
121 | Q: I can't seem to use Open vSwitch in a wireless network. | |
122 | ||
123 | A: Wireless base stations generally only allow packets with the source | |
124 | MAC address of NIC that completed the initial handshake. | |
125 | Therefore, without MAC rewriting, only a single device can | |
126 | communicate over a single wireless link. | |
127 | ||
128 | This isn't specific to Open vSwitch, it's enforced by the access | |
129 | point, so the same problems will show up with the Linux bridge or | |
130 | any other way to do bridging. | |
131 | ||
132 | ||
133 | VLANs | |
134 | ----- | |
135 | ||
136 | Q: VLANs don't work. | |
137 | ||
138 | A: Many drivers in Linux kernels before version 3.3 had VLAN-related | |
139 | bugs. If you are having problems with VLANs that you suspect to be | |
140 | driver related, then you have several options: | |
141 | ||
142 | - Upgrade to Linux 3.3 or later. | |
143 | ||
144 | - Build and install a fixed version of the particular driver | |
145 | that is causing trouble, if one is available. | |
146 | ||
147 | - Use a NIC whose driver does not have VLAN problems. | |
148 | ||
149 | - Use "VLAN splinters", a feature in Open vSwitch 1.4 and later | |
150 | that works around bugs in kernel drivers. To enable VLAN | |
151 | splinters on interface eth0, use the command: | |
152 | ||
153 | ovs-vsctl set interface eth0 other-config:enable-vlan-splinters=true | |
154 | ||
155 | For VLAN splinters to be effective, Open vSwitch must know | |
156 | which VLANs are in use. See the "VLAN splinters" section in | |
157 | the Interface table in ovs-vswitchd.conf.db(5) for details on | |
158 | how Open vSwitch infers in-use VLANs. | |
159 | ||
160 | VLAN splinters increase memory use and reduce performance, so | |
161 | use them only if needed. | |
162 | ||
163 | - Apply the "vlan workaround" patch from the XenServer kernel | |
164 | patch queue, build Open vSwitch against this patched kernel, | |
165 | and then use ovs-vlan-bug-workaround(8) to enable the VLAN | |
166 | workaround for each interface whose driver is buggy. | |
167 | ||
168 | (This is a nontrivial exercise, so this option is included | |
169 | only for completeness.) | |
170 | ||
171 | It is not always easy to tell whether a Linux kernel driver has | |
172 | buggy VLAN support. The ovs-vlan-test(8) and ovs-test(8) utilities | |
173 | can help you test. See their manpages for details. Of the two | |
174 | utilities, ovs-test(8) is newer and more thorough, but | |
175 | ovs-vlan-test(8) may be easier to use. | |
176 | ||
177 | Q: VLANs still don't work. I've tested the driver so I know that it's OK. | |
178 | ||
179 | A: Do you have VLANs enabled on the physical switch that OVS is | |
180 | attached to? Make sure that the port is configured to trunk the | |
181 | VLAN or VLANs that you are using with OVS. | |
182 | ||
183 | Q: Outgoing VLAN-tagged traffic goes through OVS to my physical switch | |
184 | and to its destination host, but OVS seems to drop incoming return | |
185 | traffic. | |
186 | ||
187 | A: It's possible that you have the VLAN configured on your physical | |
188 | switch as the "native" VLAN. In this mode, the switch treats | |
189 | incoming packets either tagged with the native VLAN or untagged as | |
190 | part of the native VLAN. It may also send outgoing packets in the | |
191 | native VLAN without a VLAN tag. | |
192 | ||
193 | If this is the case, you have two choices: | |
194 | ||
195 | - Change the physical switch port configuration to tag packets | |
196 | it forwards to OVS with the native VLAN instead of forwarding | |
197 | them untagged. | |
198 | ||
199 | - Change the OVS configuration for the physical port to a | |
200 | native VLAN mode. For example, the following sets up a | |
201 | bridge with port eth0 in "native-tagged" mode in VLAN 9: | |
202 | ||
203 | ovs-vsctl add-br br0 | |
204 | ovs-vsctl add-port br0 eth0 tag=9 vlan_mode=native-tagged | |
205 | ||
206 | In this situation, "native-untagged" mode will probably work | |
207 | equally well. Refer to the documentation for the Port table | |
208 | in ovs-vswitchd.conf.db(5) for more information. | |
209 | ||
210 | Q: Can I configure an IP address on a VLAN? | |
211 | ||
212 | A: Yes. Use an "internal port" configured as an access port. For | |
213 | example, the following configures IP address 192.168.0.7 on VLAN 9. | |
214 | That is, OVS will forward packets from eth0 to 192.168.0.7 only if | |
215 | they have an 802.1Q header with VLAN 9. Conversely, traffic | |
216 | forwarded from 192.168.0.7 to eth0 will be tagged with an 802.1Q | |
217 | header with VLAN 9: | |
218 | ||
219 | ovs-vsctl add-br br0 | |
220 | ovs-vsctl add-port br0 eth0 | |
221 | ovs-vsctl add-port br0 vlan9 tag=9 -- set interface vlan9 type=internal | |
222 | ifconfig vlan9 192.168.0.7 | |
223 | ||
224 | Q: My OpenFlow controller doesn't see the VLANs that I expect. | |
225 | ||
226 | A: The configuration for VLANs in the Open vSwitch database (e.g. via | |
227 | ovs-vsctl) only affects traffic that goes through Open vSwitch's | |
228 | implementation of the OpenFlow "normal switching" action. By | |
229 | default, when Open vSwitch isn't connected to a controller and | |
230 | nothing has been manually configured in the flow table, all traffic | |
231 | goes through the "normal switching" action. But, if you set up | |
232 | OpenFlow flows on your own, through a controller or using ovs-ofctl | |
233 | or through other means, then you have to implement VLAN handling | |
234 | yourself. | |
235 | ||
236 | You can use "normal switching" as a component of your OpenFlow | |
237 | actions, e.g. by putting "normal" into the lists of actions on | |
238 | ovs-ofctl or by outputting to OFPP_NORMAL from an OpenFlow | |
239 | controller. This will only be suitable for some situations, | |
240 | though. | |
241 | ||
242 | ||
243 | Controllers | |
244 | ----------- | |
245 | ||
246 | Q: I'm getting "error type 45250 code 0". What's that? | |
247 | ||
248 | A: This is a Open vSwitch extension to OpenFlow error codes. Open | |
249 | vSwitch uses this extension when it must report an error to an | |
250 | OpenFlow controller but no standard OpenFlow error code is | |
251 | suitable. | |
252 | ||
253 | Open vSwitch logs the errors that it sends to controllers, so the | |
254 | easiest thing to do is probably to look at the ovs-vswitchd log to | |
255 | find out what the error was. | |
256 | ||
257 | If you want to dissect the extended error message yourself, the | |
258 | format is documented in include/openflow/nicira-ext.h in the Open | |
259 | vSwitch source distribution. The extended error codes are | |
260 | documented in lib/ofp-errors.h. | |
261 | ||
262 | Q1: Some of the traffic that I'd expect my OpenFlow controller to see | |
263 | doesn't actually appear through the OpenFlow connection, even | |
264 | though I know that it's going through. | |
265 | Q2: Some of the OpenFlow flows that my controller sets up don't seem | |
266 | to apply to certain traffic, especially traffic between OVS and | |
267 | the controller itself. | |
268 | ||
269 | A: By default, Open vSwitch assumes that OpenFlow controllers are | |
270 | connected "in-band", that is, that the controllers are actually | |
271 | part of the network that is being controlled. In in-band mode, | |
272 | Open vSwitch sets up special "hidden" flows to make sure that | |
273 | traffic can make it back and forth between OVS and the controllers. | |
274 | These hidden flows are higher priority than any flows that can be | |
275 | set up through OpenFlow, and they are not visible through normal | |
276 | OpenFlow flow table dumps. | |
277 | ||
278 | Usually, the hidden flows are desirable and helpful, but | |
279 | occasionally they can cause unexpected behavior. You can view the | |
280 | full OpenFlow flow table, including hidden flows, on bridge br0 | |
281 | with the command: | |
282 | ||
283 | ovs-appctl bridge/dump-flows br0 | |
284 | ||
285 | to help you debug. The hidden flows are those with priorities | |
286 | greater than 65535 (the maximum priority that can be set with | |
287 | OpenFlow). | |
288 | ||
289 | The DESIGN file at the top level of the Open vSwitch source | |
290 | distribution describes the in-band model in detail. | |
291 | ||
292 | If your controllers are not actually in-band (e.g. they are on | |
293 | localhost via 127.0.0.1, or on a separate network), then you should | |
294 | configure your controllers in "out-of-band" mode. If you have one | |
295 | controller on bridge br0, then you can configure out-of-band mode | |
296 | on it with: | |
297 | ||
298 | ovs-vsctl set controller br0 connection-mode=out-of-band | |
299 | ||
300 | Q: I configured all my controllers for out-of-band control mode but | |
301 | "ovs-appctl bridge/dump-flows" still shows some hidden flows. | |
302 | ||
303 | A: You probably have a remote manager configured (e.g. with "ovs-vsctl | |
304 | set-manager"). By default, Open vSwitch assumes that managers need | |
305 | in-band rules set up on every bridge. You can disable these rules | |
306 | on bridge br0 with: | |
307 | ||
308 | ovs-vsctl set bridge br0 other-config:disable-in-band=true | |
309 | ||
310 | This actually disables in-band control entirely for the bridge, as | |
311 | if all the bridge's controllers were configured for out-of-band | |
312 | control. | |
313 | ||
314 | Q: My OpenFlow controller doesn't see the VLANs that I expect. | |
315 | ||
316 | A: See answer under "VLANs", above. | |
317 | ||
318 | Contact | |
319 | ------- | |
320 | ||
321 | bugs@openvswitch.org | |
322 | http://openvswitch.org/ |