X-Git-Url: https://pintos-os.org/cgi-bin/gitweb.cgi?a=blobdiff_plain;f=FAQ;h=bdd96ce91211f20a63c73bcf84d22053d929826b;hb=024c78b852ace6319dfd4b46cafc1b9fe4180d77;hp=4ad8c4390b58dfe22eab83cdd865ce29587f1f4e;hpb=c5b25863dc9033085bc6dfd64bedd7f143d5f4a4;p=openvswitch

diff --git a/FAQ b/FAQ
index 4ad8c439..bdd96ce9 100644
--- a/FAQ
+++ b/FAQ
@@ -143,12 +143,11 @@ A: The kernel module in upstream Linux 3.3 and later does not include
          kernel module from the Open vSwitch distribution instead of the
          upstream Linux kernel module.
 
-       - Tunnel and patch virtual ports, that is, interfaces with type
-         "gre", "ipsec_gre", "capwap", or "patch".  It is possible to
-         create tunnels in Linux and attach them to Open vSwitch as
-         system devices.  However, they cannot be dynamically created
-         through the OVSDB protocol or set the tunnel ids as a flow
-         action.
+       - Tunnel virtual ports, that is, interfaces with type "gre",
+         "ipsec_gre", "capwap".  It is possible to create tunnels in
+         Linux and attach them to Open vSwitch as system devices.
+         However, they cannot be dynamically created through the OVSDB
+         protocol or set the tunnel ids as a flow action.
 
          Work is in progress in adding these features to the upstream
          Linux version of the Open vSwitch kernel module.  For now, if
@@ -156,6 +155,11 @@ A: The kernel module in upstream Linux 3.3 and later does not include
          vSwitch distribution instead of the upstream Linux kernel
          module.
 
+       - Patch virtual ports, that is, interfaces with type "patch".
+         You can use Linux "veth" devices as a substitute.
+
+         We don't have any plans to add patch ports upstream.
+
 Q: What features are not available when using the userspace datapath?
 
 A: Tunnel and patch virtual ports are not supported, as described in the
@@ -404,6 +408,24 @@ A: The configuration for VLANs in the Open vSwitch database (e.g. via
    controller.  This will only be suitable for some situations,
    though.
 
+Q: I configured ports on a bridge as access ports with different VLAN
+   tags, like this:
+
+       ovs-vsctl add-br br0
+       ovs-vsctl set-controller br0 tcp:192.168.0.10:6633
+       ovs-vsctl add-port br0 eth0
+       ovs-vsctl add-port br0 tap0 tag=9
+       ovs-vsctl add-port br0 tap1 tag=10
+
+   but the VMs running behind tap0 and tap1 can still communicate,
+   that is, they are not isolated from each other even though they are
+   on different VLANs.
+
+A: Do you have a controller configured on br0 (as the commands above
+   do)?  If so, then this is a variant on the previous question, "My
+   OpenFlow controller doesn't see the VLANs that I expect," and you
+   can refer to the answer there for more information.
+
 
 Controllers
 -----------