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

[Ethan Jackson]

One thing I noticed btw, The case where the user has looped the
network has often been reported as "my cpu usage is high".  It may be
worth calling that out explicitly.

Ethan

On Tue, Jun 12, 2012 at 9:39 AM, Ben Pfaff <blp at nicira.com> wrote:
> 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.
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev