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 <[email protected]> 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 > [email protected] > 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 > [email protected] > http://openvswitch.org/mailman/listinfo/discuss > -- Aaron O. Rosen Masters Student - Network Communication 306B Fluor Daniel
_______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
