*Display datapath controller connection information: * ovs-vsctl list controller
On Wed, Mar 14, 2012 at 6:39 PM, Aaron Rosen <[email protected]> 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 <[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 > > > -- Aaron O. Rosen Masters Student - Network Communication 306B Fluor Daniel
_______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
