From a8c3551040212bb7307ece6dacf0ec9bacb1412a Mon Sep 17 00:00:00 2001 From: Alex Chan Date: Thu, 28 May 2015 10:10:16 +0100 Subject: [PATCH 1/7] Minor spelling corrections in docs --- docs/architecture.txt | 10 +++++----- site/building.md | 2 +- site/weavedns.md | 2 +- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/architecture.txt b/docs/architecture.txt index 4dba5c45..daa56730 100644 --- a/docs/architecture.txt +++ b/docs/architecture.txt @@ -160,7 +160,7 @@ if a node receives a packet that is bigger than the next MTU, it is required to drop the packet and send back an ICMP 3,4 packet which informs the sending node of the next hop MTU (RFC 1191). In theory, these ICMP packets should have all the reverse NAT and so forth -applied, to make it all the way back to the sender. In practise this +applied, to make it all the way back to the sender. In practice, this does often work, but in some cases all ICMP are sometimes blocked, often by idiots who don't understand that ICMP is really the error channel of all network traffic. @@ -187,16 +187,16 @@ If weave determines that fragmentation is reliable then when weave sniffs large packets (i.e. packets larger than the MTU and thus don't have DF set) then weave will encapsulate these packets as necessary and similarly send them out as-is, without DF set, trusting to the -network to do all necessary fragementation and reassembly. +network to do all necessary fragmentation and reassembly. -However, if weave determines that fragementation is not reliable +However, if weave determines that fragmentation is not reliable between any two peers then it will manually fragment larger packets correctly according to the IP spec, and will then send them between weave peers with the DF flag set (i.e. the fragmentation will ensure -that the encapsulatated traffic will not be greater than the PMTU +that the encapsulated traffic will not be greater than the PMTU between weave peers). Because the fragmentation is done according to the IP spec, we don't need to do reassembly ourselves - on the -receiving weave, we jus inject all the fragments and rely on the +receiving weave, we just inject all the fragments and rely on the stack to do reassembly. Sometimes PMTU discovery doesn't work as ICMP packets sometimes get diff --git a/site/building.md b/site/building.md index 5b8eeede..5f344a21 100644 --- a/site/building.md +++ b/site/building.md @@ -170,7 +170,7 @@ $ vagrant ssh -c 'make -C src/github.com/weaveworks/weave' ``` you should then find container snapshot tarballs in the top-level -directory. You can use these snapshots with `docker load` agains a +directory. You can use these snapshots with `docker load` against a different host, e.g. ```bash diff --git a/site/weavedns.md b/site/weavedns.md index d3b55d4a..59c97948 100644 --- a/site/weavedns.md +++ b/site/weavedns.md @@ -163,7 +163,7 @@ $ weave launch-dns 10.2.254.1/24 --domain="mycompany.local." The local domain should end with `local.`, since these names are link-local as per [RFC6762](https://tools.ietf.org/html/rfc6762), -(though this is not strictly neccessary). +(though this is not strictly necessary). ## Using weaveDNS without `weave run` From adc5784fc9360be737ecbd4b6afd0cbee4cb5519 Mon Sep 17 00:00:00 2001 From: Matthias Radestock Date: Thu, 28 May 2015 13:36:32 +0100 Subject: [PATCH 2/7] expand weavedns example to cover multi-host --- site/weavedns.md | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/site/weavedns.md b/site/weavedns.md index 59c97948..b73d0180 100644 --- a/site/weavedns.md +++ b/site/weavedns.md @@ -52,9 +52,24 @@ not attempt to do load-balancing. Each weaveDNS container started with `launch-dns` needs to be given its own, unique, IP address, in a subnet that is a) common to all weaveDNS containers, b) disjoint from the application subnets, and c) -not in use on any of the hosts. In our example the weaveDNS address is -in subnet 10.2.254.0/24 and the application containers are in -subnet 10.2.1.0/24. +not in use on any of the hosts. + +In our example the weaveDNS address is in subnet 10.2.254.0/24 and the +application containers are in subnet 10.2.1.0/24. So, to launch and +use weaveDNS on a second host we would run: + +```bash +host2$ weave launch $HOST1 +host2$ weave launch-dns 10.2.254.2/24 +host2$ shell2=$(weave run --with-dns 10.2.1.36/24 -ti -h ubuntu2.weave.local ubuntu) +host2$ docker attach $shell2 + +# ping pingme +... +``` + +Notice the different IP address in the 10.2.254.0/24 subnet we gave to +`weave launch-dns`, compared to what we supplied on the first host. WeaveDNS containers can be stopped with `stop-dns`. From c983d9f39f8abc5c7c16828c287dda88e8030afd Mon Sep 17 00:00:00 2001 From: Matthias Radestock Date: Thu, 28 May 2015 14:48:08 +0100 Subject: [PATCH 3/7] cosmetic --- site/weavedns.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/site/weavedns.md b/site/weavedns.md index b73d0180..8905bc90 100644 --- a/site/weavedns.md +++ b/site/weavedns.md @@ -39,7 +39,7 @@ $ weave run 10.2.1.25/24 -ti -h pingme.weave.local ubuntu $ shell1=$(weave run --with-dns 10.2.1.26/24 -ti -h ubuntu.weave.local ubuntu) $ docker attach $shell1 -# ping pingme +root@ubuntu:/# ping pingme ... ``` @@ -64,7 +64,7 @@ host2$ weave launch-dns 10.2.254.2/24 host2$ shell2=$(weave run --with-dns 10.2.1.36/24 -ti -h ubuntu2.weave.local ubuntu) host2$ docker attach $shell2 -# ping pingme +root@ubuntu2:/# ping pingme ... ``` From 2e208b49211b5609a710ce04e082782d8baffef9 Mon Sep 17 00:00:00 2001 From: Matthias Radestock Date: Sun, 31 May 2015 09:03:45 +0100 Subject: [PATCH 4/7] cosmetic --- site/troubleshooting.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/site/troubleshooting.md b/site/troubleshooting.md index bca3fa28..2cbc0e07 100644 --- a/site/troubleshooting.md +++ b/site/troubleshooting.md @@ -126,7 +126,7 @@ 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 +There may also be further sections for [IP allocator](ipam.html#troubleshooting) and [weaveDNS](weavedns.html#troubleshooting). From 341d5ecbb606c53010643546aa81ae6968004033 Mon Sep 17 00:00:00 2001 From: Matthias Radestock Date: Mon, 1 Jun 2015 11:13:16 +0100 Subject: [PATCH 5/7] remove out-of-date info from ipam docs --- site/ipam.md | 14 ++------------ 1 file changed, 2 insertions(+), 12 deletions(-) diff --git a/site/ipam.md b/site/ipam.md index e1ca81b9..836e980f 100644 --- a/site/ipam.md +++ b/site/ipam.md @@ -103,18 +103,8 @@ host3 has caught fire, we can go to one of the other hosts and run: Weave will take all the IP address ranges owned by host3 and transfer them to be owned by host1. The name "host3" is resolved via the 'nickname' feature of weave, which defaults to the local host -name. You can see the full set of range assignments in the output from -`weave status`, which will show the internal hex ID and nickname in -brackets, like this: - - Ring [10.2.1.1, 10.2.1.255) - 10.2.1.1 -> 96:e9:e2:2e:2d:bc (host1) (version: 3, free: 126) - 10.2.1.128 -> ea:84:25:9b:31:2e (host2) (version: 2, free: 64) - 10.2.1.192 -> ea:6c:21:09:cf:f0 (host3) (version: 1, free: 62) - -So, in our example, we could equivalently do: - - host1$ weave rmpeer ea:6c:21:09:cf:f0 +name. Alternatively, one can supply a peer name as shown in `weave +status`. ## Troubleshooting From 71d6f9cdfbb43a60116962edc09876402dfedf90 Mon Sep 17 00:00:00 2001 From: Paul Bellamy Date: Mon, 1 Jun 2015 13:23:23 +0100 Subject: [PATCH 6/7] [docs] re-ordering proxy doc sections --- site/proxy.md | 30 +++++++++++++++--------------- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/site/proxy.md b/site/proxy.md index 27bca6c8..a7e06981 100644 --- a/site/proxy.md +++ b/site/proxy.md @@ -56,21 +56,6 @@ Multiple IP addresses and networks can be supplied in the `WEAVE_CIDR` variable by space-separating them, as in `WEAVE_CIDR="10.2.1.1/24 10.2.2.1/24"`. -## Usage with WeaveDNS - -Containers started via the proxy can be automatically configured to -use WeaveDNS for name resolution. To accomplish this we need to launch -the proxy with the `--with-dns` option - - host1$ weave launch - host1$ weave launch-dns 10.2.254.1/24 - host1$ weave launch-proxy --with-dns - -With this done, any containers launched through the proxy will use -weaveDNS for name resolution. WeaveDNS is used in addition to any dns -servers specified via the `--dns` option. More details on weaveDNS can -be found in the [weaveDNS documentation](weavedns.html). - ## Usage with IPAM To automatically assign a unique IP address to a container, weave must @@ -94,6 +79,21 @@ option. For example: More details on IPAM can be found in the [IPAM documentation](ipam.html). +## Usage with WeaveDNS + +Containers started via the proxy can be automatically configured to +use WeaveDNS for name resolution. To accomplish this we need to launch +the proxy with the `--with-dns` option + + host1$ weave launch + host1$ weave launch-dns 10.2.254.1/24 + host1$ weave launch-proxy --with-dns + +With this done, any containers launched through the proxy will use +weaveDNS for name resolution. WeaveDNS is used in addition to any dns +servers specified via the `--dns` option. More details on weaveDNS can +be found in the [weaveDNS documentation](weavedns.html). + ## Limitations * The proxy does not currently support TLS. From 6feaa72abde94721a7b490dfe05289124c338b26 Mon Sep 17 00:00:00 2001 From: Paul Bellamy Date: Mon, 1 Jun 2015 13:24:39 +0100 Subject: [PATCH 7/7] [docs] elaborating on proxy IPAM and DNS interaction --- site/proxy.md | 18 +++++++++++++----- 1 file changed, 13 insertions(+), 5 deletions(-) diff --git a/site/proxy.md b/site/proxy.md index a7e06981..57914dab 100644 --- a/site/proxy.md +++ b/site/proxy.md @@ -76,8 +76,15 @@ without a `WEAVE_CIDR`, we can launch the proxy with the `--with-ipam` option. For example: host1$ weave launch-proxy --with-ipam + host1$ export DOCKER_HOST=tcp://host1:12375 -More details on IPAM can be found in the [IPAM documentation](ipam.html). +Now, containers will always be automatically assigned an IP address +and attached to the weave network when we start them. For example: + + host1$ docker run -ti ubuntu /bin/sh + +More details on IPAM can be found in the [IPAM +documentation](ipam.html). ## Usage with WeaveDNS @@ -89,10 +96,11 @@ the proxy with the `--with-dns` option host1$ weave launch-dns 10.2.254.1/24 host1$ weave launch-proxy --with-dns -With this done, any containers launched through the proxy will use -weaveDNS for name resolution. WeaveDNS is used in addition to any dns -servers specified via the `--dns` option. More details on weaveDNS can -be found in the [weaveDNS documentation](weavedns.html). +With this done, any containers connected via IPAM or `WEAVE_CIDR=...`, +which are launched through the proxy will use weaveDNS for name +resolution. WeaveDNS is used in addition to any dns servers specified +via the `--dns` option. More details on weaveDNS can be found in the +[weaveDNS documentation](weavedns.html). ## Limitations