[ovs-discuss] Best practice trouble-shooting

[Aaron Rosen]

*Display datapath controller connection information: *
ovs-vsctl list controller

On Wed, Mar 14, 2012 at 6:39 PM, Aaron Rosen <arosen at clemson.edu> wrote:

> Just to add to this list, I also find this command helpful in debugging
> openflow:
>
> *Print out all the openflow messages: *
> ovs-ofctl snoop <datapath>
> *
> *And these for setting up OVS with openflow
> *
> Set datapath id:*
> ovs-vsctl set bridge <data_path> other-config:datapath-id=<datapath_id>
>
> *Set controller: *
> ovs-vsctl set-controller <data_path> tcp:<ip>:<port>
>
> *Set fail datapath to fail closed:
> *ovs-vsctl set-fail-mode <datapath> secure*
>
> Disable in-band communication:
> *ovs-vsctl set bridge <datapath> other_config:disable-in-band=true*
>
>
> *Aaron
>
> *
> *
>
>
> On Wed, Mar 14, 2012 at 6:16 PM, Luiz Ozaki <luiz.ozaki at locaweb.com.br>
> wrote:
> > On 3/14/12 2:03 PM, Mike Bursell wrote:
> >
> > Hi -
> >
> > One useful piece of work that we're thinking of doing and then sharing
> with
> > the community is a trouble-shooting guide, aimed more at sysadmins and
> > support engineers than developers.  So, I thought I'd ask here to find
> out:
> >
> > 1) what behaviours do you look for that suggest there are problems with
> > normal operation?
> > 2) what documentation do you find most/least useful?
> > 3) how do you navigate the logs, and what's most/least useful there?
> > 4) what tests do you tend to try in order to trouble-shoot problems.
> >
> > Although I'm hoping I'll get replies from everyone's good friends at
> Nicira,
> > I'm particularly interested to hear from people using OVS in the field.
> >
> > TIA,
> >
> > -Mike.
> > _______________________________________________
> > discuss mailing list
> > discuss at openvswitch.org
> > http://openvswitch.org/mailman/listinfo/discuss
> >
> >
> > Show the bridge/vifs connections
> > brctl show
> >
> > vSwitch overhead diagnostic:
> > ovs-dpctl show
> > @lookups lines:
> >   - lost numbers should not increase, getting this counter up means high
> > latency/drop packets
> >   - missed packet went to userland - okayish
> >   - hit is the optimal, packet went only in kernelspace - Best case
> >
> > Inspect packets:
> > eth# ---- xapi# ---- vif##.0
> > tcpdump on each part of the schema to diagnose where the problem is. Eg.:
> > tcpdump on the eth shows if the packets is passing from/to physical
> network
> > tcpdump vif##.0 shows the packets from/to VM
> >
> > So, if the packet is passing throught eth and it's not getting into the
> VM
> > destination vif, probably the packet is being droped or not forwarded by
> the
> > OVS
> > Same goes for output packets from the VM. It's passing throught the vif,
> but
> > it's not getting into the eth.
> >
> > Shows current flows:
> > ovs-dpctl dump-flows <bridge>
> >
> > Show installed flows:
> > ovs-ofctl dump-flows <bridge>
> >
> > Trace openflow:
> > ovs-appctl ofproto/trace
> > (I simulated some packets looking at the
> > [openvswitch] / tests / ofproto-dpif.at in the OVS source code and
> changing
> > accordly to my needs)
> >
> > MAC table
> > ovs-appctl fdb/show <bridge>
> >
> > Show bond configuration
> > ovs-appctl bond/show <bond>
> >
> >
> > Some sort of quick reference that I had in mind to diagnose some OVS
> > problems. At least when implementing openflows using OVS.
> >
> > --
> > Luiz Henrique Ozaki
> >
> >
> > _______________________________________________
> > discuss mailing list
> > discuss at openvswitch.org
> > http://openvswitch.org/mailman/listinfo/discuss
> >
>
>
>
> --
> Aaron O. Rosen
> Masters Student - Network Communication
> 306B Fluor Daniel
>
>
>


-- 
Aaron O. Rosen
Masters Student - Network Communication
306B Fluor Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20120314/7b4910d2/attachment.html>