[ovs-dev] [PATCH] Add a FAQ.

Ben Pfaff blp at nicira.com
Tue Jun 12 16:39:09 UTC 2012


On Mon, Jun 11, 2012 at 10:47:14PM -0700, Justin Pettit wrote:
> This is great, Ben!  Thank you for doing it!
> 
> > +   and as soon as I ran the "add-port" command I lost all connectivity
> > +   through eth0.  Help!
> 
> I like the sense of urgency you've added.  Maybe you missed your
> calling in fiction.  "Fifty Shades of Overlay"?  Networking fabric
> explores new territory at the command of its new edge master.

I appreciate your approval.

> > +   This isn't specific to Open vSwitch, it's enforced by the access
> > +   point, so the same problems will show up with the Linux bridge or
> > +   any other way to do bridging.
> > +
> > +   (Based on a response by Jesse Gross:
> > +   http://openvswitch.org/pipermail/discuss/2011-January/004707.html)
> 
> I don't think that post contains any additional information, so I'm
> not sure it's worth providing a pointer.

I intended to give credit, not to recommend visiting the URL.

I moved the credit to the commit message.

> > +       - Use "VLAN splinters", a feature in Open vSwitch 1.4 and later
> > +         that works around bugs in kernel drivers.  To enable VLAN
> > +         splinters on interface eth0, use the command:
> > +
> > +             ovs-vsctl set int eth0 other-config:enable-vlan-splinters=true
> 
> You probably abbreviated this to fit on one line, but I think "int"
> might be confusing to new users.

OK, I wrote it out in full and just let the line get long.

> > +         For VLAN splinters to be effective, Open vSwitch must know
> > +         which VLANs that are in use.  See the "VLAN splinters"
> 
> I think you can drop the "that".

Thanks, done.

> > +Q: Can I configure an IP address on a VLAN?
> > +
> > +A: Yes.  Use an "internal port" configured as an access port.  For
> > +   example, the following configures IP address 192.168.0.7 on VLAN 9.
> > +   That is, OVS will forward packets from eth0 to 192.168.0.7 only if
> > +   they have an 802.1Q header with VLAN 9.  Conversely, traffic
> > +   forwarded from 192.168.0.7 to eth0 will be tagged with an 802.1Q
> > +   header with VLAN 9:
> > +
> > +       ovs-vsctl add-br br0
> > +       ovs-vsctl add-port br0 vlan9 tag=9 -- set interface vlan9 type=internal
> > +       ifconfig vlan9 192.168.0.7
> 
> Does eth0 need to be attached to the bridge?

Oops, yes, I added an "ovs-vsctl add-port br0 eth0."

> > +A: By default, Open vSwitch assumes that OpenFlow controllers are
> > +   connected "in-band", that is, that the controllers are actually
> > +   part of the network that is being controllers.  In in-band mode,
> 
> "controllers" -> "controlled".

Thanks, fixed.

> Do you think it's worth mentioning the "other-config :
> disable-in-band" option along with the ones you've listed?

Hmm.  Yes, it looks like it.  I added:

Q: I configured all my controllers for out-of-band control mode but
   "ovs-appctl bridge/dump-flows" still shows some hidden flows.

A: You probably have a remote manager configured (e.g. with "ovs-vsctl
   set-manager").  By default, Open vSwitch assumes that managers need
   in-band rules set up on every bridge.  You can disable these rules
   on bridge br0 with:

       ovs-vsctl set bridge br0 other-config:disable-in-band=true

   This actually disables in-band control entirely for the bridge, as
   if all the bridge's controllers were configured for out-of-band
   control.

as well as a description of hidden flows to the previous question.

> A few other possible FAQ entries (I'm happy to write them if you think they're worthwhile):
> 
> 	- OVS is not specific to Linux and is not limited to being a vswitch.  Maybe mention the PORTING guide.
> 	- OVS supports OpenFlow 1.0 and a number of vendor extensions.  Work on later versions is ongoing, and provide a pointer to the page if people want to contribute to that effort.
> 	- Stuff not supported in userspace.
> 	- Stuff not supported with upstream kernel module.
>
> The last two items we discussed putting next to man page sections that impact them, but I wonder if it would be good to just dump them all in a single location.

All of these sound worthwhile, please write them up when you get a
chance.

I'll push the FAQ soon.

Thanks,

Ben.



More information about the dev mailing list