cloudstack-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From seb...@apache.org
Subject git commit: remove troubleshooting and move to admin guide
Date Thu, 20 Mar 2014 09:36:05 GMT
Repository: cloudstack-docs
Updated Branches:
  refs/heads/master 1fda6f364 -> 42edbd950


remove troubleshooting and move to admin guide


Project: http://git-wip-us.apache.org/repos/asf/cloudstack-docs/repo
Commit: http://git-wip-us.apache.org/repos/asf/cloudstack-docs/commit/42edbd95
Tree: http://git-wip-us.apache.org/repos/asf/cloudstack-docs/tree/42edbd95
Diff: http://git-wip-us.apache.org/repos/asf/cloudstack-docs/diff/42edbd95

Branch: refs/heads/master
Commit: 42edbd950917c77100a0616b59512d52c8b953fb
Parents: 1fda6f3
Author: Sebastien Goasguen <runseb@gmail.com>
Authored: Thu Mar 20 05:35:54 2014 -0400
Committer: Sebastien Goasguen <runseb@gmail.com>
Committed: Thu Mar 20 05:35:54 2014 -0400

----------------------------------------------------------------------
 rtd/source/index.rst                            |   1 -
 .../troubleshoot_internet_traffic.rst           | 216 -------------------
 2 files changed, 217 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/42edbd95/rtd/source/index.rst
----------------------------------------------------------------------
diff --git a/rtd/source/index.rst b/rtd/source/index.rst
index 92680ca..c836f7a 100644
--- a/rtd/source/index.rst
+++ b/rtd/source/index.rst
@@ -55,7 +55,6 @@ Advanced Networking Guides
     networking/ovs-plugin
     networking/ipv6
     networking/autoscale_without_netscaler.rst
-    networking/troubleshoot_internet_traffic.rst
 
 .. _developer:
 

http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/42edbd95/rtd/source/networking/troubleshoot_internet_traffic.rst
----------------------------------------------------------------------
diff --git a/rtd/source/networking/troubleshoot_internet_traffic.rst b/rtd/source/networking/troubleshoot_internet_traffic.rst
deleted file mode 100644
index b118e38..0000000
--- a/rtd/source/networking/troubleshoot_internet_traffic.rst
+++ /dev/null
@@ -1,216 +0,0 @@
-Troubleshooting Internet Traffic
-================================
-
-Below are a few troubleshooting steps to check whats going wrong with your
-network...
-
-Trouble Shooting Steps
-----------------------
-
-#. The switches have to be configured correctly to pass VLAN traffic. You can
-   verify if VLAN traffic is working by bringing up a tagged interface on the
-   hosts and pinging between them as below...
-
-   On *host1 (kvm1)*
-
-   ::
-
-     kvm1 ~$ vconfig add eth0 64
-     kvm1 ~$ ifconfig eth0.64 1.2.3.4 netmask 255.255.255.0 up
-     kvm1 ~$ ping 1.2.3.5
-
-   On *host2 (kvm2)*
-
-   ::
-
-     kvm2 ~$ vconfig add eth0 64
-     kvm2 ~$ ifconfig eth0.64 1.2.3.5 netmask 255.255.255.0 up
-     kvm2 ~$ ping 1.2.3.4
-
-   If the pings dont work, run *tcpdump(8)* all over the place to check
-   who is gobbling up the packets. Ultimately, if the switches are not
-   configured correctly, CloudStack networking wont work so fix the
-   physical networking issues before you proceed to the next steps
-
-#. Ensure `Traffic Labels <http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.2.0/html/Installation_Guide/about-physical-networks.html>`_
are set for the Zone.
-
-   Traffic labels need to be set for all hypervisors including
-   XenServer, KVM and VMware types. You can configure traffic labels when
-   you creating a new zone from the *Add Zone Wizard*.
-
-   .. image:: ../_static/images/networking-zone-traffic-labels.png
-
-   On an existing zone, you can modify the traffic labels by going to
-   *Infrastructure, Zones, Physical Network* tab.
-
-   .. image:: ../_static/images/networking-infra-traffic-labels.png
-
-   List labels using *CloudMonkey* 
-
-   ::
-
-     acs-manager ~$ cloudmonkey list traffictypes physicalnetworkid=41cb7ff6-8eb2-4630-b577-1da25e0e1145
-     count = 4
-     traffictype:
-     id = cd0915fe-a660-4a82-9df7-34aebf90003e
-     kvmnetworklabel = cloudbr0
-     physicalnetworkid = 41cb7ff6-8eb2-4630-b577-1da25e0e1145
-     traffictype = Guest
-     xennetworklabel = MGMT
-     ========================================================
-     id = f5524b8f-6605-41e4-a982-81a356b2a196
-     kvmnetworklabel = cloudbr0
-     physicalnetworkid = 41cb7ff6-8eb2-4630-b577-1da25e0e1145
-     traffictype = Management
-     xennetworklabel = MGMT
-     ========================================================
-     id = 266bad0e-7b68-4242-b3ad-f59739346cfd
-     kvmnetworklabel = cloudbr0
-     physicalnetworkid = 41cb7ff6-8eb2-4630-b577-1da25e0e1145
-     traffictype = Public
-     xennetworklabel = MGMT
-     ========================================================
-     id = a2baad4f-7ce7-45a8-9caf-a0b9240adf04
-     kvmnetworklabel = cloudbr0
-     physicalnetworkid = 41cb7ff6-8eb2-4630-b577-1da25e0e1145
-     traffictype = Storage
-     xennetworklabel = MGMT
-     =========================================================
-  
-#. KVM traffic labels require to be named as *"cloudbr0"*, *"cloudbr2"*,
-   *"cloudbrN"* etc and the corresponding bridge must exist on the KVM
-   hosts. If you create labels/bridges with any other names, CloudStack
-   (atleast earlier versions did) seems to ignore them. CloudStack does not
-   create the physical bridges on the KVM hosts, you need to create them
-   **before** before adding the host to Cloudstack.
-
-   ::
-
-    kvm1 ~$ ifconfig cloudbr0
-    cloudbr0  Link encap:Ethernet  HWaddr 00:0C:29:EF:7D:78  
-          inet addr:192.168.44.22  Bcast:192.168.44.255  Mask:255.255.255.0
-          inet6 addr: fe80::20c:29ff:feef:7d78/64 Scope:Link
-          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
-          RX packets:92435 errors:0 dropped:0 overruns:0 frame:0
-          TX packets:50596 errors:0 dropped:0 overruns:0 carrier:0
-          collisions:0 txqueuelen:0 
-          RX bytes:94985932 (90.5 MiB)  TX bytes:61635793 (58.7 MiB)
-
-#. The Virtual Router, SSVM, CPVM *public* interface would be bridged to
-   a physical interface on the host. In the example below, *cloudbr0* is
-   the public interface and CloudStack has correctly created the virtual
-   interfaces bridge. This virtual interface to physical interface mapping
-   is done automatically by CloudStack using the traffic label settings for
-   the Zone. If you have provided correct settings and still dont have a
-   working working Internet, check the switching layer before you debug any
-   further. You can verify traffic using tcpdump on the virtual, physical
-   and bridge interfaces.
-
-   ::
-
-     kvm-host1 ~$ brctl show
-     bridge name  bridge id           STP enabled interfaces
-     breth0-64    8000.000c29ef7d78   no          eth0.64
-                                                  vnet2
-     cloud0       8000.fe00a9fe0219   no          vnet0
-     cloudbr0     8000.000c29ef7d78   no          eth0
-                                                  vnet1
-                                                  vnet3
-     virbr0       8000.5254008e321a   yes         virbr0-nic
-
-   ::
-
-     xenserver1 ~$ brctl show
-     bridge name  bridge id           STP enabled interfaces
-     xapi0    0000.e2b76d0a1149       no          vif1.0
-     xenbr0   0000.000c299b54dc       no          eth0
-                                                  xapi1
-                                                  vif1.1
-                                                  vif1.2
-
-#. Pre-create labels on the XenServer Hosts. Similar to KVM bridge
-   setup, traffic labels must also be pre-created on the XenServer hosts
-   before adding them to CloudStack.
-
-   ::
-
-     xenserver1 ~$ xe network-list 
-     uuid ( RO)                : aaa-bbb-ccc-ddd
-               name-label ( RW): MGMT
-         name-description ( RW): 
-                   bridge ( RO): xenbr0
-
-
-#. The Internet would be accessible from both the SSVM and CPVM
-   instances by default. Their public IPs will also be directly pingable
-   from the Internet. Please note that these test would work only if your
-   switches and traffic labels are configured correctly for your
-   environment. If your SSVM/CPVM cant reach the Internet, its very
-   unlikely that the Virtual Router (VR) can also the reach the Internet
-   suggesting that its either a switching issue or incorrectly assigned
-   traffic labels. Fix the SSVM/CPVM issues before you debug VR issues.
-
-   ::
-
-     root@s-1-VM:~# ping -c 3 google.com
-     PING google.com (74.125.236.164): 56 data bytes
-     64 bytes from 74.125.236.164: icmp_seq=0 ttl=55 time=26.932 ms
-     64 bytes from 74.125.236.164: icmp_seq=1 ttl=55 time=29.156 ms
-     64 bytes from 74.125.236.164: icmp_seq=2 ttl=55 time=25.000 ms
-     --- google.com ping statistics ---
-     3 packets transmitted, 3 packets received, 0% packet loss
-     round-trip min/avg/max/stddev = 25.000/27.029/29.156/1.698 ms
-
-   ::
-
-     root@v-2-VM:~# ping -c 3 google.com
-     PING google.com (74.125.236.164): 56 data bytes
-     64 bytes from 74.125.236.164: icmp_seq=0 ttl=55 time=32.125 ms
-     64 bytes from 74.125.236.164: icmp_seq=1 ttl=55 time=26.324 ms
-     64 bytes from 74.125.236.164: icmp_seq=2 ttl=55 time=37.001 ms
-     --- google.com ping statistics ---
-     3 packets transmitted, 3 packets received, 0% packet loss
-     round-trip min/avg/max/stddev = 26.324/31.817/37.001/4.364 ms
-
-
-#. The Virtual Router (VR) should also be able to reach the Internet
-   without having any Egress rules. The Egress rules only control forwarded
-   traffic and not traffic that originates on the VR itself.
-
-   ::
-
-     root@r-4-VM:~# ping -c 3 google.com
-     PING google.com (74.125.236.164): 56 data bytes
-     64 bytes from 74.125.236.164: icmp_seq=0 ttl=55 time=28.098 ms
-     64 bytes from 74.125.236.164: icmp_seq=1 ttl=55 time=34.785 ms
-     64 bytes from 74.125.236.164: icmp_seq=2 ttl=55 time=69.179 ms
-     --- google.com ping statistics ---
-     3 packets transmitted, 3 packets received, 0% packet loss
-     round-trip min/avg/max/stddev = 28.098/44.021/69.179/17.998 ms
-
-#. However, the Virtual Router's (VR) Source NAT Public IP address
-   **WONT** be reachable until appropriate Ingress rules are
-   in place. You can add *Ingress* rules under *Network, Guest Network, IP
-   Address, Firewall* setting page.
-
-   .. image:: ../_static/images/networking-ingress-rule.png
-
-#. The VM Instances by default wont be able to access the Internet. Add
-   Egress rules to permit traffic.
-
-   .. image:: ../_static/images/networking-egress-rule.png
-
-#. Some users have reported that flushing IPTables rules (or changing
-   routes) on the SSVM, CPVM or the Virtual Router makes the Internet work.
-   This is not expected behaviour and suggests that your networking
-   settings are incorrect. No IPtables/route changes are required on the
-   SSVM, CPVM or the VR. Go back and double check all your settings.
-
-
-In a vast majority of the cases, the problem has turned out to be at the
-switching layer where the L3 switches were configured incorrectly.
-
-This section was contibuted by Shanker Balan and was originally published
-at [here]_
-
-.. [here] http://shankerbalan.net/blog/internet-not-working-on-cloudstack-vms/


Mime
View raw message