Mailing-List: contact dev-help@brooklyn.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@brooklyn.incubator.apache.org
From: sjcorbett <git@git.apache.org>
To: dev@brooklyn.incubator.apache.org
Reply-To: dev@brooklyn.incubator.apache.org
References: <git-pr-741-incubator-brooklyn@git.apache.org>
In-Reply-To: <git-pr-741-incubator-brooklyn@git.apache.org>
Subject: [GitHub] incubator-brooklyn pull request: Ports @aledsage's
 Troubleshooting...
Content-Type: text/plain
Message-Id: <20150709143003.1FE4DE682A@git1-us-west.apache.org>
Date: Thu,  9 Jul 2015 14:30:03 +0000 (UTC)

Github user sjcorbett commented on a diff in the pull request:

    https://github.com/apache/incubator-brooklyn/pull/741#discussion_r34260794
  
    --- Diff: docs/guide/dev/tips/troubleshooting-connectivity.md ---
    @@ -0,0 +1,141 @@
    +---
    +layout: website-normal
    +title: Troubleshooting Server Connectivity Issues in the Cloud
    +toc: /guide/toc.json
    +---
    +
    +A common problem when setting up an application in the cloud is getting the basic connectivity right - how
    +do I get my service (e.g. a TCP host:port) publicly accessible over the internet.
    +
    +This varies a lot - e.g. is the VM public or in a private network, is the service only accessible through
    +a load balancer, should the service be globally reachable or only to a particular CIDR.
    +
    +This blog post gives some general tips for debugging connectivity issues, which are applicable to a 
    +range of different service types. Choose those that are appropriate for your use-case.
    +
    +## VM reachable
    +If the VM is supposed to be accessible directly (e.g. from the public internet, or if in a private network
    +then from a jump host)...
    +
    +### ping
    +Can you `ping` the VM from the machine you are trying to reach it from.
    +
    +However, ping is over ICMP. If the VM is unreachable, it could be that the firewall forbids ICMP but still
    +lets TCP traffic through).
    +
    +### telnet to TCP port
    +You can check if a given TCP port is reachable and listening using `telnet <host> <port>`, such as
    +`telnet www.google.com 80`, which gives output like:
    +
    +```
    +    Trying 31.55.163.219...
    +    Connected to www.google.com.
    +    Escape character is '^]'.
    +```
    +
    +If this is very slow to respond, it can be caused by a firewall blocking access. If it is fast, it could
    +be that the server is just not listening on that port.
    +
    +### DNS and routing
    +If using a hostname rather than IP, then is it resolving to a sensible IP?
    +
    +Is the route to the server sensible? (e.g. one can hit problems with proxy servers in a corporate
    +network, or ISPs returning a default result for unknown hosts).
    +
    +The following commands can be useful:
    +
    +* `host` is a DNS lookup utility. e.g. `host www.google.com`.
    +* `dig` stands for “domain information groper”. e.g. `dig www.google.com`.
    +* `traceroute` prints the route that packets take to a network host. e.g. `traceroute www.google.com`.
    +
    +## Service is listening
    +
    +### Service responds
    +Try connecting to the service from the VM iteslf. For example, `curl http://localhost:8080` for a
    +web-service.
    +
    +On dev/test VMs, don’t be afraid to install the utilities you need such as `curl`, `telnet`, `nc`,
    --- End diff --
    
    Weird apostrophe character.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---