Red Hat Bugzilla – Bug 993962
[Doc] Add network troubleshooting documentation.
Last modified: 2016-04-26 14:35:08 EDT
Document URL: https://access.redhat.com/site/documentation/en-US/Red_Hat_OpenStack/3/html/Installation_and_Configuration_Guide/index.html Section Number and Name: Chapter 9. Installing the OpenStack Networking Service Suggestions for improvement: Add network troubleshooting documentation covering the use of ovs-ofctl, ovs-vsctl, etc. Need to also gather equivalents/alternatives for non-OVS setups. Additional information: > > 5) The troubleshooting techniques mentioned in the guide only > > describe how to verify the services are running. Is it possible to > > include tooling commands for ovs-ofctl, ovs-vsctl to verify your > > network setup?
Hi Bob, As Steve said in the lists, we'll need some help with this info. Do you have any dev docs or info from which we can work (beyond man pages)? thanks, Summer
Joe Telerico provided the following page he's been working on: https://mojo.redhat.com/docs/DOC-16457#jive_content_id_Debugging_Network_issues
Brent has provided: Hi Summer, Some of the commands that helped me troubleshoot my environment were: quantum net-show <name> quantum subnet-show <id from name> quantum port-show <id> ovs-vsctl show ovs-ofctl dump-flows br-tun ovs-ofctl show br-tun | grep '^ [0-9]' ovs-ofctl dump-flows br-ex ovs-ofctl dump-flows br-int ovs-ofctl dump-ports br-tun ip -s link ip netns ip netns | grep dhcp ip netns | grep router ip netns exec qrouter-XXXX ping -c 5 <tenant instance ip address> ovs-benchmark
Hi Maru, Could you please review the bug fix using the link in comment 6? Thank you.
Tracking Networking Packets - Why is -w FILENAME included without documentation as to what it does? Plus, the more common use case is to write the output to stdout, not to a file, so consider making it clear the argument is optional. - Consider adding documentation for the -e flag, which ensures that the link-level header is dumped (in which the vlan tag will appear). Debugging Network Namespaces - Network namespaces are not related to VLANs specifically. They enable isolation between networks both at the L2 and L3 level, and VLANs are L2 only. - Spelling error in the 3rd bullet, namescpaces -> namespaces - Consider using the example of starting a bash shell in the namespace (ip netns exec [namespace id] bash) so that subsequent commands can be invoked without ip netns exec. Procedure 13.1. Troubleshooting Access and Routing Issues - It's going to be really hard to provide a useful guide here. The instructions provided are going to be too basic for a network engineer and not basic enough for a beginner. At the least, consider pointing someone without a networking background at some kind of intro tutorial. - Which host is the use going to be executing the commands in question on? A compute node? A network controller node? Or an all-in-one demo node? 2. The instructions provided are pretty vague. How is the user supposed to know whether the output of the route command indicates connectivity to the public network? 3. which bridge is configured? a. how does the user know which bridge the public network is configured on? b. how is the user supposed to know with the output of router-show the router is configured correctly with the public and private subnets? The external_gateway_info field will contain a reference to the public network id, but it is necessary to invoke router-port-list for the router to determine the private network association. c. a private ip can only be pinged from the namespace in which it is defined, but a floating ip can be pinged directly. that's why associating a floating ip to a private ip is useful - it makes the private ip directly accessible. d. Again, what is the user supposed to look for in the output of the specified command?
Hi Maru, Thank you for the quick response. I've worked through your comments for Tracking Networking Packets and Debugging Network Namespaces sections. For the procedure, you're right, we need to have two sorts: newbie and admin troubleshooting. Let's consider this the newbie type, since it's in the Install Guide. Can you possibly just give me the exact steps which belong to the newbie type? I've just raised BZ1035962 to add an admin procedure to the admin guide. Thanks, Deepti
Hi Deepti, In my previous message I was talking about providing a reference for the basics of networking concepts for 'newbie' users (something like http://docs.openstack.org/trunk/training-guides/content/module002-ch000-openstack-networking.html) so they could attain the background necessary to be able to troubleshoot Neutron. The need for 'admin' documentation is entirely different, and there is already an upstream admin guide (http://docs.openstack.org/admin-guide-cloud/content//ch_networking.html). I'm not sure of the value of duplicating material which is not RHOS specific. m.
Included some basic troubleshooting information for now. Will include more info in this section for async release.
This bug is being assigned to Don Domingo, who is now the designated docs specialist for the OpenStack Networking service.