Skip to content
This repository has been archived by the owner on Jun 20, 2024. It is now read-only.

Commit

Permalink
Update docs
Browse files Browse the repository at this point in the history
  • Loading branch information
awh committed Aug 5, 2015
1 parent 62c8f4e commit 54f182f
Show file tree
Hide file tree
Showing 3 changed files with 192 additions and 105 deletions.
55 changes: 41 additions & 14 deletions site/ipam.md
Original file line number Diff line number Diff line change
Expand Up @@ -199,22 +199,49 @@ reports on the current status of the weave router and IP allocator:
````
...
Allocator universe 10.2.0.0/16
Owned Ranges:
10.2.1.1 -> 96:e9:e2:2e:2d:bc (host1) (v3)
10.2.1.128 -> ea:84:25:9b:31:2e (host2) (v3)
10.2.1.192 -> ea:6c:21:09:cf:f0 (host3) (v9)
Allocator default subnet: 10.2.1.0/24
Service: ipam
Consensus: achieved
Range: [10.32.0.0-10.48.0.0)
DefaultSubnet: 10.32.0.0/12
...
````

The first section covers the router; see the [troubleshooting
guide](troubleshooting.html#status-report) for full details.

The 'Allocator' section, which is only present if weave has been
started with the `--ipalloc-range` option, summarises the overall
position and lists which address ranges have been assigned to which
peer. Each range begins at the address shown and ends just before the
next address, or wraps around at the end of the subnet. The 'v' number
denotes how many times that entry has been updated.
guide](troubleshooting.html#weave-status) for full details.

The 'Service: ipam' section, which is only present if weave has been
started with the `--ipalloc-range` option, displays the consensus

This comment has been minimized.

Copy link
@rade

rade Aug 5, 2015

Member

That "is only present if ..." bit is wrong. Needs fixing in latest_release_doc_updates.

This comment has been minimized.

Copy link
@awh

awh Aug 5, 2015

Author Contributor

It's not just this - I've found a bunch of stuff that didn't get updated in the -foobar -> --foo-bar transition...

This comment has been minimized.

Copy link
@awh

awh Aug 5, 2015

Author Contributor

(That's not relevant to latest_release_doc_updates though)

This comment has been minimized.

Copy link
@awh

awh Aug 5, 2015

Author Contributor
state as well as the total allocation range and default subnet.

This comment has been minimized.

Copy link
@rade

rade Aug 5, 2015

Member

"consensus state" - There is no mention of consensus anywhere in the IPAM docs. Should be introduced in the "Initialisation" section, ideally with the same terminology as used here ("deferred", "awaiting", "achieved", "quorum" ...).


Further information on the internal state of IPAM can be obtained from
`weave report`:

````
...
"IPAM": {
"Paxos": null,
"Range": "[10.32.0.0-10.48.0.0)",
"DefaultSubnet": "10.32.0.0/12",
"Entries": [
{
"Token": "10.32.0.0",
"Peer": "ce:31:e0:06:45:1a",
"Version": 5
},
{
"Token": "10.36.0.2",
"Peer": "ee:38:33:a7:d9:71",
"Version": 3
},
{
"Token": "10.40.0.0",
"Peer": "ea:2d:b2:e6:e4:f5",
"Version": 3
}
],
"PendingClaims": null,
"PendingAllocates": null
},
...
````

This comment has been minimized.

Copy link
@rade

rade Aug 5, 2015

Member

No need to mention any of that.

219 changes: 138 additions & 81 deletions site/troubleshooting.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,6 +5,14 @@ layout: default

# Troubleshooting Weave

* [Overall status](#weave-status)
* [List connections](#weave-status-connections)
* [List peers](#weave-status-peers)
* [List DNS entries](#weave-status-dns)
* [JSON report](#weave-report)
* [List attached containers](#list-attached-containers)
* [Snapshot releases](#snapshot-releases)

Check what version of weave you are running with

weave version
Expand All @@ -29,9 +37,6 @@ Another useful debugging technique is to attach standard packet
capture and analysis tools, such as tcpdump and wireshark, to the
`weave` network bridge on the host.

One can ask a weave router for a [status report](#status-report) or
for a [list of attached containers](#list-attached-containers).

To stop weave, run

weave stop
Expand All @@ -50,100 +55,152 @@ Any running application containers will permanently lose connectivity
with the weave network and have to be restarted in order to
re-connect.

### <a name="status-report"></a>Status report

The command

weave status

reports on the current status of the weave router and DNS.
### <a name="weave-status"></a>Overall status

This produces output like:
A status summary can be obtained with `weave status`:

````
weave router 0.7.0
Our name is 7a:f4:56:87:76:3b(weave01)
Encryption off
Peer discovery on
Sniffing traffic on &{39 65535 ethwe ae:e3:07:9c:8c:d4 up|broadcast|multicast}
MACs:
ba:8c:b9:dc:e1:c9 -> 7a:f4:56:87:76:3b(weave01) (2014-10-23 16:39:19.482338935 +0000 UTC)
ce:15:34:a9:b5:6d -> 7a:f4:56:87:76:3b(weave01) (2014-10-23 16:39:28.257103595 +0000 UTC)
7a:61:a2:49:4b:91 -> 7a:f4:56:87:76:3b(weave01) (2014-10-23 16:39:27.482970752 +0000 UTC)
9e:95:0c:54:8e:39 -> 7a:16:dd:5b:83:de(weave02) (2014-10-23 16:39:28.795601325 +0000 UTC)
72:5f:a4:60:e5:ce -> 7a:16:dd:5b:83:de(weave02) (2014-10-23 16:39:29.575995255 +0000 UTC)
Peers:
7a:16:dd:5b:83:de(weave02) (v31) (UID 13151318985609435078)
-> 7a:f4:56:87:76:3b(weave01) [37.157.33.76:7195]
7a:f4:56:87:76:3b(weave01) (v1) (UID 6913268221365110570)
-> 7a:16:dd:5b:83:de(weave02) [191.235.147.190:6783]
Routes:
unicast:
7a:f4:56:87:76:3b -> 00:00:00:00:00:00
7a:16:dd:5b:83:de -> 7a:16:dd:5b:83:de
broadcast:
7a:f4:56:87:76:3b -> [7a:16:dd:5b:83:de]
7a:16:dd:5b:83:de -> []
Direct Peers: 191.235.147.190 192.168.32.1
Reconnects:
->[192.168.32.1:6783] (dial tcp4 192.168.32.1:6783: connection timed out) next try at 2014-10-23 16:39:50.585932102 +0000 UTC
$ weave status
Service: router
Name: 4a:0f:f6:ec:1c:93
NickName: host1
Encryption: disabled
PeerDiscovery: enabled
Peers: 3
DirectPeers: 4
Connections: 6 established, 0 unestablished, 3 failed
Service: ipam
Consensus: achieved
Range: [10.32.0.0-10.48.0.0)
DefaultSubnet: 10.32.0.0/12
Service: dns
Domain: weave.local.
Address: 0.0.0.0:53
TTL: 1
Entries: 9
Service: proxy
Address: tcp://127.0.0.1:12375
````

The terms used here are explained further at
[how it works](how-it-works.html).

The 'Our name' line identifies the local weave router as a peer in the
weave network, displaying the peer name followed by the peer's nickname
in parenthesis. The nickname defaults to the name of the host on which
the weave container was launched; if desired it can be overriden by
supplying the `--nickname` argument to `weave launch`.

The 'Sniffing traffic' line shows details of the virtual ethernet
interface that weave is using to receive packets on the local
machine.
The 'Name' and 'NickName' lines identify the local weave router as a
peer in the weave network. The nickname defaults to the name of
the host on which the weave container was launched; if desired it can
be overriden by supplying the `--nickname` argument to `weave launch`.

The 'Encryption' line indicates whether
[encryption](features.html#security) is in use for communication
between peers.

The 'Peer discovery' line indicates whether
The 'PeerDiscovery' line indicates whether
[automatic peer discovery](features.html#dynamic-topologies) is
enabled (which is the default).

The 'MACs' section lists all MAC addresses known to this router. These
identify containers in the weave network, as well as points for
[host network integration](features.html#host-network-integration). For
each MAC the list shows the peer they reside on, and the time when the
router last saw some traffic from that MAC. The router forgets
addresses which are inactive for longer than 10 minutes.

The 'Peers' section lists all peers known to this router, including
itself. Each peer is shown with its name, nickname, version number
(incremented on each reconnect) and the UID. Then each line
beginning `->` shows another peer that it is connected to, with the
IP address and port number of the connection. In the above example,
the local router has connected to its peer using address
191.235.147.190:6783, and its peer sees the same connection as coming
from 37.157.33.76:7195.

The 'Routes' section summarised the information for deciding how to
route packets between peers, which is mostly of interest when the
weave network is not fully connected. See the
[architecture documentation](https://raw.githubusercontent.com/weaveworks/weave/master/docs/architecture.txt)
for a full explanation.

'Direct Peers' lists the hosts which weave was told to connect to in
`weave launch` and `weave connect`.

The 'Reconnects' section lists peers that this router is aware of, but is
not currently connected to. Each line contains some information about
what went wrong the last time; whether it is attempting to connect or
is waiting for a while before connecting again.

There may also be further sections for the
[IP address allocator](ipam.html#troubleshooting),
[weaveDNS](weavedns.html#troubleshooting), and
[Weave Docker API Proxy](proxy.html#troubleshooting).
'Peers' is the total number of peers in the network.

'DirectPeers' is the number of hosts specified to the local weave
router via `weave launch` or `weave connect`.

'Connections' shows how many connections are in the 'established',

This comment has been minimized.

Copy link
@rade

rade Aug 5, 2015

Member

"how many of the local weave router's connections"

This comment has been minimized.

Copy link
@awh

awh Aug 5, 2015

Author Contributor

That's not actually true - the established and unestablished counts are for all peers. The original individual 'Unestablished' line (before you suggested coalescing everything into one property) did this as a way to fix #908 - if you make it local connections only, then you'd have to run weave status on all peers to notice if anything was wrong...

This comment has been minimized.

Copy link
@rade

rade Aug 5, 2015

Member

ah, but then we really do need separate entries. One summarising what is in weave status peers and one what is in weave status connections.

This comment has been minimized.

Copy link
@rade

rade Aug 5, 2015

Member

If I was to read it out aloud, the summary of the peer information should say "There are 3 peers with a total of 6 connections between them, 4 of which are established, and 4 are unestablished". And the summary of the connection information should say "The local peer has 4 connections, 2 of which are established, 1 unestablished, and 1 failed".

We need to somehow find a way of distinguishing "connections between peers" and "connections to/from the local peer". I worry that users may get confused (just as I did!)

'unestablished' and 'failed' states respectively.

There are further sections for the [IP address
allocator](ipam.html#troubleshooting),
[weaveDNS](weavedns.html#troubleshooting), and [Weave Docker API
Proxy](proxy.html#troubleshooting).

### <a name="weave-status-connections"></a>List connections

Detailed information on connections can be obtained with `weave status

This comment has been minimized.

Copy link
@rade

rade Aug 5, 2015

Member

"local weave router's connections"

connections`:

````
$ weave status connections
<- 192.168.48.12:39634 ea:2d:b2:e6:e4:f5(host2) direct established
<- 192.168.48.13:49619 ee:38:33:a7:d9:71(host3) discovered established
-> 192.168.48.14:6783 direct failed(dial tcp4 192.168.48.14:6783: no route to host), retry: 2015-08-05 13:19:00.550203683 +0000 UTC
-> 192.168.48.15:6783 direct failed(dial tcp4 192.168.48.15:6783: no route to host), retry: 2015-08-05 13:19:04.912851748 +0000 UTC
-> 192.168.48.16:6783 direct failed(dial tcp4 192.168.48.16:6783: no route to host), retry: 2015-08-05 13:18:56.609145605 +0000 UTC
````

The columns are as follows:

* Connection origination direction (-> for outbound, <- for inbound)
* Remote TCP address
* Remote peer name and nickname (omitted for failed connections)
* Type - `direct` if specified via `weave launch` or `weave connect`,
`discovered` if learned via gossip
* Status - `established` if TCP connection and corresponding UDP path
are up, `unestablished` if waiting for confirmation of UDP
heartbeat or `failed` if TCP connection could not be made

### <a name="weave-status-peers"></a>List peers

Detailed information on peers can be obtained with `weave status
peers`:

````
$ weave status peers
ce:31:e0:06:45:1a(host1)
<- 192.168.48.12:39634 ea:2d:b2:e6:e4:f5(host2) established
<- 192.168.48.13:49619 ee:38:33:a7:d9:71(host3) established
ea:2d:b2:e6:e4:f5(host2)
-> 192.168.48.11:6783 ce:31:e0:06:45:1a(host1) established
<- 192.168.48.13:58181 ee:38:33:a7:d9:71(host3) established
ee:38:33:a7:d9:71(host3)
-> 192.168.48.12:6783 ea:2d:b2:e6:e4:f5(host2) established
-> 192.168.48.11:6783 ce:31:e0:06:45:1a(host1) established
````

This lists all peers known to this router, including itself. Each peer is
shown with its name and nickname, then each line thereafter shows another peer
that it is connected to, with the direction, IP address and port number of the
connection. In the above example, `host3` has connected to `host1` at
`192.168.48.11:6783`; `host1` sees the `host3` end of the same connection as
`192.168.48.13:49619`.

### <a name="weave-status-dns"></a>List DNS entries

Detailed information on DNS registrations can be obtained with `weave
status dns`:

````
$ weave status dns
one 10.32.0.1 eebd81120ee4 4a:0f:f6:ec:1c:93
one 10.43.255.255 4fcec78d2a9b 66:c4:47:c6:65:bf
one 10.40.0.0 bab69d305cba ba:98:d0:37:4f:1c
three 10.32.0.3 7615b6537f74 4a:0f:f6:ec:1c:93
three 10.44.0.1 c0b39dc52f8d 66:c4:47:c6:65:bf
three 10.40.0.2 8a9c2e2ef00f ba:98:d0:37:4f:1c
two 10.32.0.2 83689b8f34e0 4a:0f:f6:ec:1c:93
two 10.44.0.0 7edc306cb668 66:c4:47:c6:65:bf
two 10.40.0.1 68a5e9c2641b ba:98:d0:37:4f:1c
````

The columns are as follows:

* Unqualified hostname
* IPv4 address
* Registering entity identifier (typically a container ID)
* Name of peer from which the registration originates

### <a name="weave-report"></a>JSON report

$ weave report

Produces a comprehensive dump of the internal state of the router,
IPAM and DNS services in JSON format, including all the information
available from the `weave status` commands. You can also supply a
Golang text template to `weave report` in a similar fashion to `docker
inspect`:

$ weave report -f '{{{.DNS.Domain}}'
weave.local.

### <a name="list-attached-containers"></a>List attached containers

Expand Down
23 changes: 13 additions & 10 deletions site/weavedns.md
Original file line number Diff line number Diff line change
Expand Up @@ -239,25 +239,28 @@ DNS:
````
...
WeaveDNS (d6:1b:df:42:af:7d)
listening on port 53, for domain weave.local.
response ttl 30
1d836dea2c56: foo.weave.local. [10.2.2.1]
Service: dns
Domain: weave.local.
Address: 0.0.0.0:53
TTL: 1
Entries: 9
...
````

The first section covers the router; see the [troubleshooting
guide](troubleshooting.html#status-report) for more detail.
guide](troubleshooting.html#weave-status) for more detail.

The second section is pertinent to weaveDNS, and includes:
The 'Service: dns' section is pertinent to weaveDNS, and includes:

* Port on which the DNS server is listening
* The local domain suffix which is being served
* The listening address to which the DNS server is bound
* The response ttl
* The names known to the weaveDNS server. Each entry comprises
the container ID, IP address and its fully qualified domain name
* The total number of entries

You may also use `weave status dns` to obtain a complete dump of all

This comment has been minimized.

Copy link
@rade

rade Aug 5, 2015

Member

make that a link to the relevant section in the docs.

DNS registrations, including unqualified hostname, IPv4 address,
registering entity identifier and weave peer.

This comment has been minimized.

Copy link
@rade

rade Aug 5, 2015

Member

No need to list the columns here.


Information on the processing of queries, and the general operation of
weaveDNS, can be obtained from the container logs with
Expand Down

0 comments on commit 54f182f

Please sign in to comment.