Q: What virtualization platforms can use Open vSwitch?
A: Open vSwitch can currently run on any Linux-based virtualization
- platform (kernel 2.6.18 and newer), including: KVM, VirtualBox, Xen,
+ platform (kernel 2.6.32 and newer), including: KVM, VirtualBox, Xen,
Xen Cloud Platform, XenServer. As of Linux 3.3 it is part of the
mainline kernel. The bulk of the code is written in platform-
independent C and is easily ported to other environments. We welcome
1.9.x 2.6.18 to 3.8
1.10.x 2.6.18 to 3.8
1.11.x 2.6.18 to 3.8
- 1.12.x 2.6.18 to 3.10
+ 2.0.x 2.6.32 to 3.10
Open vSwitch userspace should also work with the Linux kernel module
built into Linux 3.3 and later.
Open vSwitch userspace is not sensitive to the Linux kernel version.
- It should build against almost any kernel, certainly against 2.6.18
+ It should build against almost any kernel, certainly against 2.6.32
and later.
Q: What Linux kernel versions does IPFIX flow monitoring work with?
ovs-vsctl clear bridge br0 mirrors
+Q: Does Open vSwitch support configuring a port in promiscuous mode?
+
+A: Yes. How you configure it depends on what you mean by "promiscuous
+ mode":
+
+ - Conventionally, "promiscuous mode" is a feature of a network
+ interface card. Ordinarily, a NIC passes to the CPU only the
+ packets actually destined to its host machine. It discards
+ the rest to avoid wasting memory and CPU cycles. When
+ promiscuous mode is enabled, however, it passes every packet
+ to the CPU. On an old-style shared-media or hub-based
+ network, this allows the host to spy on all packets on the
+ network. But in the switched networks that are almost
+ everywhere these days, promiscuous mode doesn't have much
+ effect, because few packets not destined to a host are
+ delivered to the host's NIC.
+
+ This form of promiscuous mode is configured in the guest OS of
+ the VMs on your bridge, e.g. with "ifconfig".
+
+ - The VMware vSwitch uses a different definition of "promiscuous
+ mode". When you configure promiscuous mode on a VMware vNIC,
+ the vSwitch sends a copy of every packet received by the
+ vSwitch to that vNIC. That has a much bigger effect than just
+ enabling promiscuous mode in a guest OS. Rather than getting
+ a few stray packets for which the switch does not yet know the
+ correct destination, the vNIC gets every packet. The effect
+ is similar to replacing the vSwitch by a virtual hub.
+
+ This "promiscuous mode" is what switches normally call "port
+ mirroring" or "SPAN". For information on how to configure
+ SPAN, see "How do I configure a port as a SPAN port, that is,
+ enable mirroring of all traffic to that port?"
+
Q: How do I configure a VLAN as an RSPAN VLAN, that is, enable
mirroring of all traffic to that VLAN?
ovs-ofctl add-flow br0 priority=65535,actions=drop
+Q: I added a flow to send packets out the ingress port, like this:
+
+ ovs-ofctl add-flow br0 in_port=2,actions=2
+
+ but OVS drops the packets instead.
+
+A: Yes, OpenFlow requires a switch to ignore attempts to send a packet
+ out its ingress port. The rationale is that dropping these packets
+ makes it harder to loop the network. Sometimes this behavior can
+ even be convenient, e.g. it is often the desired behavior in a flow
+ that forwards a packet to several ports ("floods" the packet).
+
+ Sometimes one really needs to send a packet out its ingress port.
+ In this case, output to OFPP_IN_PORT, which in ovs-ofctl syntax is
+ expressed as just "in_port", e.g.:
+
+ ovs-ofctl add-flow br0 in_port=2,actions=in_port
+
+ This also works in some circumstances where the flow doesn't match
+ on the input port. For example, if you know that your switch has
+ five ports numbered 2 through 6, then the following will send every
+ received packet out every port, even its ingress port:
+
+ ovs-ofctl add-flow br0 actions=2,3,4,5,6,in_port
+
+ or, equivalently:
+
+ ovs-ofctl add-flow br0 actions=all,in_port
+
+ Sometimes, in complicated flow tables with multiple levels of
+ "resubmit" actions, a flow needs to output to a particular port
+ that may or may not be the ingress port. It's difficult to take
+ advantage of OFPP_IN_PORT in this situation. To help, Open vSwitch
+ provides, as an OpenFlow extension, the ability to modify the
+ in_port field. Whatever value is currently in the in_port field is
+ the port to which outputs will be dropped, as well as the
+ destination for OFPP_IN_PORT. This means that the following will
+ reliably output to port 2 or to ports 2 through 6, respectively:
+
+ ovs-ofctl add-flow br0 in_port=2,actions=load:0->NXM_OF_IN_PORT[],2
+ ovs-ofctl add-flow br0 actions=load:0->NXM_OF_IN_PORT[],2,3,4,5,6
+
+ If the input port is important, then one may save and restore it on
+ the stack:
+
+ ovs-ofctl add-flow br0 actions=push:NXM_OF_IN_PORT[],\
+ load:0->NXM_OF_IN_PORT[],\
+ 2,3,4,5,6,\
+ pop:NXM_OF_IN_PORT[]
+
+Q: My bridge br0 has host 192.168.0.1 on port 1 and host 192.168.0.2
+ on port 2. I set up flows to forward only traffic destined to the
+ other host and drop other traffic, like this:
+
+ priority=5,in_port=1,ip,nw_dst=192.168.0.2,actions=2
+ priority=5,in_port=2,ip,nw_dst=192.168.0.1,actions=1
+ priority=0,actions=drop
+
+ But it doesn't work--I don't get any connectivity when I do this.
+ Why?
+
+A: These flows drop the ARP packets that IP hosts use to establish IP
+ connectivity over Ethernet. To solve the problem, add flows to
+ allow ARP to pass between the hosts:
+
+ priority=5,in_port=1,arp,actions=2
+ priority=5,in_port=2,arp,actions=1
+
+ This issue can manifest other ways, too. The following flows that
+ match on Ethernet addresses instead of IP addresses will also drop
+ ARP packets, because ARP requests are broadcast instead of being
+ directed to a specific host:
+
+ priority=5,in_port=1,dl_dst=54:00:00:00:00:02,actions=2
+ priority=5,in_port=2,dl_dst=54:00:00:00:00:01,actions=1
+ priority=0,actions=drop
+
+ The solution already described above will also work in this case.
+ It may be better to add flows to allow all multicast and broadcast
+ traffic:
+
+ priority=5,in_port=1,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00,actions=2
+ priority=5,in_port=2,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00,actions=1
Contact
-------
git://git.onelab.eu / sliver-openvswitch.git / blobdiff